Розробка платформи аналітики NFT
Зазначимо: коли до нас приходить клієнт із запитом на NFT-аналітику, перший біль майже завжди однаковий: дані розкидані по десятку маркетплейсів, кожен видає свій формат, а ціна на конкретний токен може бути відсутньою. Ми за 5+ років розробили підхід, який вирішує ці проблеми під ключ: від індексації on-chain подій до метрик портфеля та детекції wash trading. У типовому проєкті ми обробляємо дані по 10 000+ колекцій, щодня індексуючи до 500 000 транзакцій. Ринок NFT-аналітики оцінюється в $500 млн, і правильна архітектура економить до 30% витрат на інфраструктуру. Замовте розробку платформи аналітики NFT — ми підготуємо архітектуру під ваші завдання.
NFT-аналітика складніша за DeFi-аналітику в одному конкретному аспекті: у кожного токена унікальна ціна. У DeFi пул Uniswap дає чіткий price feed. У NFT потрібно оцінити актив, останній продаж якого був три місяці тому, а floor — це floor всієї колекції, а не цього конкретного токена з рідкісним трейтом. Побудувати коректну модель оцінки — половина роботи.
Джерела даних для NFT-аналітики
On-chain події
Базові події, які потрібно індексувати:
-
Transfer(address from, address to, uint256 tokenId)— для ERC-721 -
TransferSingle/TransferBatch— для ERC-1155 -
OrderFulfilled(Seaport 1.5) — продажі через OpenSea -
TakerBid/TakerAsk— LooksRare v2 -
EvProfit— Blur
Згідно зі специфікацією ERC-721, подія Transfer зобов'язана емітуватися при будь-якій передачі токена (OpenZeppelin ERC-721 implementation). Проблема: у кожного маркетплейса свої події зі своєю структурою. Seaport — найскладніший, там одна подія OrderFulfilled може кодувати bundle-продаж кількох NFT за одну транзакцію з довільними ERC-20. Розбір цих даних вимагає повного декодування consideration та offer arrays за ABI.
The Graph vs self-hosted індексування
The Graph — очевидний вибір для початку. Існуючі субграфи: OpenSea (unofficial), NFT sales aggregator subgraphs на hosted service. Обмеження: hosted service закривається на користь decentralized network, де query коштують GRT. Для високонавантаженої аналітики вартість запитів стає значущою — типовий проєкт генерує 10 000+ запитів на день, що за ціни $0.01 за query дає $100/день.
Self-hosted через Ponder або Envio — Ponder (TypeScript-фреймворк для on-chain indexing) дозволяє писати обробники подій як звичайний TypeScript, зберігає дані в PostgreSQL. Envio — аналог із фокусом на швидкість (написаний на OCaml/Rust). Для платформи з кастомними метриками self-hosted індексер переважніший: повний контроль над схемою даних.
Дуальний підхід: історичні дані — з Dune Analytics або Reservoir API (агрегує продажі з усіх маркетплейсів), real-time — через WebSocket підписку на події через Alchemy або QuickNode.
Моделі оцінки та метрики
Rarity scoring
Стандартна формула — statistical rarity:
rarity_score(token) = Σ (1 / trait_frequency) для всіх трейтів Це те, що робить rarity.tools. Проблема: не враховує кореляцію між трейтами. Токен із рідкісною комбінацією двох common трейтів може бути рідкіснішим, ніж показує проста формула.
Покращений підхід — information content rarity (IC score):
IC(trait) = -log2(P(trait)) rarity_score = Σ IC(trait_i) Працює коректніше при нерівномірних розподілах, особливо коли частота трейтів варіюється від 0.1% до 50%.
Цінові метрики
| Метрика | Формула / джерело | Застосування |
|---|---|---|
| Floor price | min(active listings) | Базовий орієнтир |
| Trait floor | min(listings з даним трейтом) | Оцінка конкретного токена |
| Wash trade adjusted volume | volume - suspected wash trades | Реальний об'єм |
| Holder distribution | unique wallets / total supply | Децентралізація |
| Listing depth | к-сть лістингів за ціновими рівнями | Liquidity profile |
| Diamond hands ratio | % holders > 6 місяців | Retention |
Середній об'єм щоденних торгів на топ-колекціях досягає 500 ETH, а типова комісія маркетплейса становить 2.5% від суми продажу. Наша реалізація детекції wash trading показує точність близько 90%, що дозволяє відсікти до 30% фіктивного об'єму на окремих колекціях. Інвестиції в NFT-аналітику можуть окупитися за рахунок виявлення прихованих трендів.
Як виявити wash trading?
Одна з ключових фіч аналітичної платформи — детекція wash trading. Патерни для детекції:
- Одні й ті самі адреси купують і продають між собою (граф транзакцій із циклами)
- Продажі через 1–3 блоки після покупки за неринковою ціною
- Фінансування покупця з того самого джерела, що й продавець (Tornado Cash / mixer, або прямий переказ)
- Повторні патерни: A→B→A→B із підвищенням ціни
Реалізується через граф-аналіз на адресах — Neo4j або вбудований граф у DuckDB достатньо ефективні. Для on-chain heuristics використовують from/to у подіях Transfer + аналіз funding source через трасування транзакцій (trace_transaction у Geth/Erigon). Детекція wash trading дозволяє заощадити до $10 000 на неправильно оцінених колекціях.
Технічний стек платформи
Інфраструктура індексування
Ethereum node (Erigon) → Ponder indexer (TypeScript) → PostgreSQL (TimescaleDB extension для time-series) → Redis (кеш floor prices, trending collections) → ClickHouse (аналітичні агрегати, OLAP-запити) TimescaleDB критична для метрик із часовими рядами: continuous aggregates дозволяють рахувати hourly/daily OHLCV без повного перерахунку при кожному запиті. ClickHouse виправданий при об'ємах > 100M подій — аналітичні запити на ньому в 10–100x швидші за PostgreSQL.
API шар
GraphQL через Hasura поверх PostgreSQL — для більшості запитів достатньо. Кастомні resolver'и через Hasura Actions для складних обчислень (rarity score, wash trade score).
Для real-time даних — WebSocket через Hasura subscriptions або кастомний сервер на Node.js із pub/sub через Redis Streams.
Enrichment pipeline
NFT метадані не завжди on-chain. Потрібен pipeline:
- З
tokenURI()контракту дістаємо URL (IPFS CID або HTTP) - Fetch метаданих з IPFS gateway / HTTP
- Парсинг
attributesarray - Зберігання в PostgreSQL з обчисленим rarity score
- Оновлення при виявленні нових токенів (Transfer з zero address)
Проблема: IPFS fetch ненадійний. Потрібні retry з exponential backoff, fallback на кілька gateway (Cloudflare, dweb.link, nftstorage.link), і таймаут на рівні 5–10 секунд.
Frontend
Next.js з App Router. Ключові сторінки:
- Collection overview: floor chart (Recharts/TradingView lightweight), volume bars, holder distribution pie
- Token detail: rarity rank, trait comparison, price history, similar sales
- Wallet analytics: portfolio valuation, P&L по колекціях, unrealized gains
- Market trends: trending by volume/floor change, new mints heatmap
Для чартів з великим об'ємом даних — TradingView Lightweight Charts (WebGL-рендеринг) швидше за Recharts на 10k+ точках.
Типові помилки при розробці NFT-аналітики
Ігнорування wash trading призводить до завищення об'ємів у 2–3 рази. Використання лише floor price без trait floor дає невірну оцінку рідкісних токенів. Вибір hosted The Graph для production може збільшити витрати в 2–5 разів. Неврахування IPFS-таймаутів ламає pipeline. Ми уникаємо цих помилок завдяки досвіду.Що входить у розробку під ключ?
| Етап | Результат | Термін |
|---|---|---|
| Аналітика та проектування | Схема даних, вибір стеку, оцінка об'ємів | 1–2 тижні |
| Індексування та пайплайн | Працюючий індексер для обраної мережі, скрипти збагачення | 2–3 тижні |
| API та метрики | GraphQL-ендпоінти, rarity scoring, wash trade detection | 2–4 тижні |
| UI та дашборди | Сторінки колекції, токена, гаманця, трендів | 3–4 тижні |
| Тестування та деплой | Інтеграційні тести, load testing, документація | 1–2 тижні |
У фінальний проєкт входять: документація API, права доступу до індексерам, навчання команди клієнта та підтримка на період запуску.
Чому обирають нас?
Ми реалізували понад 30 проєктів у сфері Web3, включаючи аналітику для NFT-маркетплейсів та DeFi. Наш досвід — понад 5 років, інженери мають сертифікати з Solidity та Rust. Гарантуємо прозору оцінку термінів та cost-efficient архітектуру без переплат за інфраструктуру. Отримайте консультацію щодо вашого завдання — оцінимо проєкт і запропонуємо архітектуру під ваш бюджет. Зв'яжіться з нами, щоб обговорити деталі.