Розробка системи моніторингу продажів NFT-колекцій

Floor price колекції впав на 30% за останні 6 годин, а ви дізналися про це з Twitter наступного дня. Або навпаки — whale купив 50 токенів поспіль, спровокував pump, а ваші алерти мовчали. Для трейдерів, фаундерів колекцій та аналітиків NFT-ринку потрібна система, яка бачить ці події протягом хвилин, а не годин. Ми спеціалізуємося на таких рішеннях — наша команда має значний досвід у блокчейн-розробці (5+ років на ринку, 30+ успішних проєктів) та реалізувала десятки проєктів з моніторингу DeFi та NFT.

Як вибрати джерело даних для моніторингу NFT-продажів?

Архітектурний вибір №1: брати дані з API маркетплейсів або напряму з blockchain events. У кожного підходу свої trade-offs.

API маркетплейсів (OpenSea, Blur, Reservoir) — простіший у реалізації, але залежність від uptime третьої сторони та затримки агрегації. Reservoir — найзручніший варіант: єдиний API, покриває Blur, OpenSea, X2Y2, LooksRare та інші, віддає нормалізовані дані.

On-chain події — вичерпні та не залежать від маркетплейсів, але вимагають розбору кожного протоколу окремо. Кожен маркетплейс має свій event signature:

Для надійної системи моніторингу — комбінація: Reservoir API для швидких даних + on-chain парсинг як резервне джерело та для верифікації. Reservoir Docs

Архітектура системи

Data pipeline

Blockchain events (WebSocket via Alchemy/QuickNode) │ ▼ Event Parser Service ◄── Reservoir API (polling / webhooks) │ ▼ Message Queue (Redis Streams / BullMQ) │ ┌────┴────┐ ▼ ▼ Metrics DB Alert Engine (TimescaleDB) (rules evaluation) │ │ ▼ ▼ Analytics API Notification Service (Telegram, Discord, Email) 

TimescaleDB — PostgreSQL розширення для time-series даних. Автоматичне партиціювання за часом, функції для агрегації по часових вікнах (time_bucket), компресія старих даних. Для NFT метрик це суттєво краще звичайного PostgreSQL: швидкість агрегаційних запитів вища в 10 разів.

CREATE TABLE nft_sales ( time TIMESTAMPTZ NOT NULL, collection VARCHAR(42) NOT NULL, token_id TEXT, price_eth DECIMAL(20, 8), price_usd DECIMAL(20, 4), marketplace VARCHAR(20), buyer VARCHAR(42), seller VARCHAR(42), tx_hash VARCHAR(66) ); SELECT create_hypertable('nft_sales', 'time'); -- Floor price за останні 24 години по годинах SELECT time_bucket('1 hour', time) AS bucket, MIN(price_eth) AS floor, COUNT(*) AS volume, SUM(price_eth) AS total_volume_eth FROM nft_sales WHERE collection = $1 AND time > NOW() - INTERVAL '24 hours' GROUP BY bucket ORDER BY bucket; 

Realtime floor price tracking

Floor price — не просто мінімальна ціна останнього продажу. Це мінімальна ціна активного лістингу. Для коректного розрахунку потрібен окремий трекер лістингів:

class FloorPriceTracker { private listings = new Map<string, { price: bigint; seller: string }>() onListing(tokenId: string, price: bigint, seller: string) { this.listings.set(tokenId, { price, seller }) this.updateFloor() } onDelisting(tokenId: string) { this.listings.delete(tokenId) this.updateFloor() } onSale(tokenId: string) { this.listings.delete(tokenId) // sold = delisted this.updateFloor() } getFloor(): bigint { return [...this.listings.values()] .reduce((min, l) => l.price < min ? l.price : min, BigInt(Infinity)) } } 

Стан лістингів ініціалізується при старті з Reservoir API, потім підтримується через event stream.

Система алертів

Типи алертів

• Floor price алерти: падіння/зростання floor більш ніж на X% за Y хвилин. Важно рахувати відсоткову зміну відносно rolling baseline, а не попереднього значення — інакше один wash trade з низькою ціною згенерує хибний алерт.
• Whale активність: один адрес купив N+ токенів за M годин. Whale у контексті колекції — відносне поняття, поріг залежить від supply.
• Volume spike: обсяг торгів за останню годину перевищує N-сигма від середнього значення (rolling mean + std deviation за 7 днів).
• Large single sale: продаж токена за ціною, що перевищує floor у K разів.
• Wash trading detection: однакові токени швидко перепродуються між пов'язаними адресами за зростаючими цінами. Проста евристика: if sale.buyer == previous sale.seller та інтервал < 10 хвилин — підозріло.

Конфігурація правил

Правила алертів зберігаються в БД, редагуються через UI без деплою:

{ "collection": "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D", "alert_type": "floor_change", "conditions": { "direction": "down", "threshold_percent": 15, "window_minutes": 30 }, "notifications": ["telegram:@bayc_holder", "discord:webhook_url"] } 

Які метрики необхідні для ефективного трейдингу NFT?

Ключові метрики для дашборду:

• Floor price (current, 24h change, 7d change)
• Total volume (24h, 7d, all time)
• Number of sales (24h)
• Unique buyers/sellers (24h)
• Average sale price vs. floor (spread)
• Holder distribution: top 10 holders % of supply, unique holders count
• Listing depth: кількість лістингів у діапазонах +5%, +10%, +20% від floor

Holder distribution оновлюється рідше — раз на годину достатньо. Потребує або on-chain трекінгу Transfer events, або запиту до Alchemy/Moralis NFT API.

Доставка сповіщень

• Telegram Bot: найбільш затребуваний у NFT-спільноті. telegraf або grammy бібліотека, групові чати для проєктних ком'юніті, особисті сповіщення для індивідуальних трейдерів.
• Discord Webhooks: стандарт для NFT-проєктів. Форматований embed з іконкою колекції, ціною, посиланням на токен на маркетплейсі.
• Email: через SendGrid/Resend для зведених дайджестів — щогодини або раз на день.

Throttling: не більше 1 алерту одного типу за N хвилин на колекцію, інакше при волатильному ринку система спамить. Черга з дедуплікацією в Redis.

Що входить у роботу

• Повний аудит вимог і вибір стеку
• Розробка data pipeline (Reservoir API + Alchemy WebSocket)
• Створення схеми TimescaleDB та написання агрегаційних запитів
• Реалізація двигуна алертів з кастомізованими правилами
• Інтеграція сповіщень (Telegram, Discord, Email)
• Розробка дашборду з ключовими метриками
• Документація з розгортання та підтримки
• Навчання команди роботі з системою

Строки розробки