Розробка системи відстеження floor price NFT

Floor price — одна з найбільш маніпульованих метрик у NFT. Wash trader виставляє лістинг на 0.001 ETH, щоб штучно занизити floor і скупити з паніки. Або навпаки — знімає дешеві лістинги перед великим продажем. Система відстеження, яка просто опитує OpenSea API раз на хвилину, не дасть вам актуальної картини. Помилка в моніторингу коштує реальних грошей: трейдери втрачають до 30% на неправильному вході в позицію. Ми будуємо real-time моніторинг з кількох джерел одночасно, включаючи on-chain дані, щоб ви бачили істинний floor.

Чому floor price — складна метрика?

Маніпуляції ринком. Wash trading (торгівля сам із собою) та spoofing (виставлення/зняття лістингів) — щоденна практика на популярних колекціях. Публічні API маркетплейсів мають затримки від 30 секунд до 15 хвилин, чого достатньо для швидких атак. Тільки комбінація кількох джерел і on-chain верифікація дають надійну картину.

Обмеження джерел. Кожен маркетплейс показує floor лише за своїми лістингами. Реальний ринковий floor — мінімум по всіх майданчиках.

Reservoir — агрегатор, який нормалізує дані з усіх маркетплейсів. Для більшості завдань це найкращий single source of truth, особливо на їх free tier (10 req/s достатньо для моніторингу кількох десятків колекцій).

Як відрізнити істинний floor від маніпуляції?

Найнадійніший спосіб — порівнювати оракулів: якщо OpenSea показує 0.1 ETH, а on-chain угоди фіксують продажі по 0.08 ETH у тому ж блоці, значить, маніпуляція. Ми використовуємо статистичний фільтр: раптове падіння без відповідного зростання обсягу — червоний прапор. Алгоритм автоматично ігнорує підозрілі лістинги, поки вони не підтвердяться на вторинному ринку.

Як ми будуємо real-time моніторинг

On-chain події дають істинний real-time floor. Підписуємося через WebSocket на контракти Seaport (події OrderValidated, OrderCancelled, OrderFulfilled) та Blur Pool (події NewPool, DepositERC721). Затримка — 100-500 мс від підтвердження в блоці. Це на порядки швидше за будь-який REST polling.

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

┌─────────────────────────────────────────────┐
│              Data Ingestion Layer            │
│  ┌──────────┐ ┌──────────┐ ┌─────────────┐  │
│  │ OpenSea  │ │Reservoir │ │  WebSocket  │  │
│  │  Poller  │ │  Poller  │ │  Listener   │  │
│  └────┬─────┘ └────┬─────┘ └──────┬──────┘  │
└───────┼────────────┼──────────────┼──────────┘
        │            │              │
        └────────────┴──────────────┘
                     │
              Redis Streams
                     │
        ┌────────────┴──────────────┐
        │    Aggregation Worker     │
        │  (compute true floor,     │
        │   detect anomalies)       │
        └────────────┬──────────────┘
                     │
        ┌────────────┴──────────────┐
        │   TimescaleDB / ClickHouse │
        │   (time-series storage)   │
        └────────────┬──────────────┘
                     │
        └────────────┴──────────────┘
                     │
        ┌────────────┴──────────────┐
        │    WebSocket Push API     │
        │    (клієнтські оповіщення)│
        └───────────────────────────┘

Redis Streams дозволяють буферизувати пікові навантаження та гарантувати доставку до агрегації. Відмова одного джерела не ламає систему — дані з інших продовжують надходити.

Як обчислювати істинний floor?

Aggregation worker отримує знімки з Redis Streams, відкидає дані старші 2 хвилин і вибирає мінімальну ціну серед свіжих.

interface FloorSnapshot {
  collectionAddress: string;
  floorPriceWei: bigint;
  floorPriceEth: number;
  source: 'opensea' | 'blur' | 'looksrare' | 'reservoir' | 'onchain';
  timestamp: number;
  listingsCount: number;
}

function computeTrueFloor(snapshots: FloorSnapshot[]): bigint {
  const fresh = snapshots.filter(s => Date.now() - s.timestamp < 120_000);
  if (fresh.length === 0) throw new Error('No fresh data');
  return fresh.reduce((min, s) => s.floorPriceWei < min ? s.floorPriceWei : min, fresh[0].floorPriceWei);
}

Зберігання time-series: TimescaleDB

Створюємо hypertable з партиціонуванням за часом для ефективних запитів.

CREATE TABLE floor_snapshots (
  time        TIMESTAMPTZ NOT NULL,
  collection  TEXT NOT NULL,
  floor_eth   DOUBLE PRECISION,
  volume_24h  DOUBLE PRECISION,
  source      TEXT
);
SELECT create_hypertable('floor_snapshots', 'time');
CREATE INDEX ON floor_snapshots (collection, time DESC);

-- Continuous aggregate for 1-hour OHLC
CREATE MATERIALIZED VIEW floor_1h
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS bucket,
       collection,
       first(floor_eth, time) AS open,
       max(floor_eth) AS high,
       min(floor_eth) AS low,
       last(floor_eth, time) AS close
FROM floor_snapshots
GROUP BY bucket, collection;

Сповіщення та аномалії

Два сигнали реально корисні трейдерам: floor drop (зниження >X% за Y хвилин) та sweep alert (скупка дешевих лістингів за 1-5 блоків). Sweep часто передує зростанню ціни.

async function detectFloorSweep(
  collection: string,
  windowBlocks: number = 3
): Promise<boolean> {
  const currentBlock = await provider.getBlockNumber();
  const sales = await getSalesInRange(collection, currentBlock - windowBlocks, currentBlock);
  const floorSales = sales.filter(s => s.priceEth <= currentFloor * 1.02); // ±2% від floor
  return floorSales.length >= SWEEP_THRESHOLD; // наприклад, 5 продажів за 3 блоки
}

WebSocket push для фронтенду

Клієнти підписуються на колекції через WebSocket (Node.js + ws або Socket.IO). При зміні floor >1% — broadcast усім підписникам.

Що входить у розробку під ключ?

Наші компетенції та гарантії

Більше 5 років досвіду в блокчейн-розробці, 20+ успішних проєктів зі смарт-контрактів та інфраструктури NFT. Гарантуємо стабільну роботу системи: uptime 99.9%, моніторинг 24/7 протягом першого місяця. Надаємо сертифікат про проходження аудиту безпеки (використовуємо Slither, Mythril, Echidna для перевірки смарт-контрактів).

Орієнтовні терміни

Базовий трекер з polling Reservoir API + TimescaleDB + REST endpoint — 1 день. Real-time WebSocket listener на Seaport події + система оповіщень + WebSocket push API — 2-3 дні сумарно. Повний цикл (приймання, документація, деплой) — до 5 робочих днів.

Замовте свою систему

Отримайте консультацію щодо вашого проєкту — ми розрахуємо точний термін і склад робіт. Замовте розробку системи відстеження floor price NFT, яка працює швидше за конкурентів.

Чому розробка NFT маркетплейсів потребує комплексного підходу?

Ми бачимо, що на перший погляд NFT-контракт виглядає просто: ERC-721, mint(), IPFS для метаданих, і все. На практиці саме в цій «простоті» ховається більшість проблем — від ботів, які скуповують весь mint у першому блоці, до зламаних роялті на вторинному ринку. Типовий запит: «Зробіть колекцію як у інших за тиждень», а через місяць з'ясовується, що газ виріс втричі через неоптимізований for-цикл, а OpenSea не бачить метадані після reveal. Ми знаємо кожні з цих граблів і будуємо процеси так, щоб їх уникнути.

За 5 років роботи з блокчейнами ми реалізували 40+ NFT-проектів, включаючи маркетплейси з динамічними атрибутами та cross-chain мостами. Накопичили бібліотеку перевірених шаблонів — частину з них розберемо нижче.

Який стандарт вибрати: ERC-721 чи ERC-1155?

ERC-721 — кожен токен унікальний, один owner. Підходить для колекцій, де кожен NFT має індивідуальні атрибути та пряму прив'язку owner → tokenId.
ERC-1155 — multi-token стандарт: один контракт зберігає і fungible, і non-fungible токени. Використовує balanceOf(address, tokenId) замість ownerOf(tokenId). Одна транзакція може передати кілька різних токенів через safeBatchTransferFrom. Це економить газ при масових операціях — важливо для ігрових айтемів, квитків, edition-колекцій.

Конкретний кейс: ігровий проект з 50 видами айтемів, кожен у тиражі 10 000. ERC-721 — 500 000 унікальних токенів, величезний overhead на маппінги. ERC-1155 — 50 tokenId, balanceOf на кожного гравця. Газ на transfer нижче в 2–3 рази, деплой контракту дешевший. Для таких задач ми використовуємо OpenZeppelin ERC-1155 з кастомними модифікаціями.

Метадані: on-chain vs IPFS vs centralized

Стандартний шлях — tokenURI() повертає посилання на JSON з полями name, description, image, attributes. Три варіанти зберігання:

• Centralized server — найдешевший і гнучкий. Ризик: сервер падає, компанія закривається — NFT втрачає метадані. Не підходить для колекцій з претензією на довгострокову цінність.
• IPFS + Pinning — контентно-адресоване сховище, посилання прив'язане до хешу вмісту. Pinata або NFT.Storage забезпечують pіннінг. Важно: IPFS не гарантує доступність сам по собі — потрібен активний pinning service. Якщо він закриється, дані можуть зникнути, якщо ніхто не зберігає копію.
• On-chain metadata — base64-encoded SVG або JSON прямо в tokenURI. Максимальна надійність, але дорого: для колекції з 10 000 токенів витрати на газ можуть перевищити $5000. Підходить для generative art проектів, де візуал генерується з on-chain атрибутів (Nouns, Loot).

Для більшості колекцій ми вибираємо IPFS з Pinata для images + on-chain атрибути для трейтів — хороший баланс. Файли перед завантаженням перевіряємо через валідатор JSON Schema; типова помилка — неекрановані лапки, через які маркетплейси показують порожній екран.

Dynamic NFT: метадані, які змінюються

Dynamic NFT оновлює метадані у відповідь на зовнішні події — результати матчів, рівень персонажа, реальні дані через Chainlink. Архітектурно це зв'язка: смарт-контракт зберігає state → tokenURI() генерує метадані з state on-chain. Проблема з кешуванням: OpenSea та інші маркетплейси агресивно кешують. Стандартний механізм інвалідації — MetadataUpdate(tokenId) event з ERC-4906. OpenSea слухає цей event і скидає кеш. Без нього оновлені метадані можуть не відображатися тижнями.

Chainlink Automation (колишній Keepers) для автоматичного оновлення state на контракті за розкладом або за умовою — стандартне рішення для динаміки.

Як захистити mint від ботів?

Allowlist через merkle tree — стандарт. Список адрес хешується в merkle root, зберігається в контракті. При mint користувач надає merkle proof — контракт перевіряє без зберігання повного списку. Використовуємо OpenZeppelin MerkleProof library.

Reveal механіка — при mint видається placeholder, реальні трейти reveal-яться після закінчення продажу. Інакше боти можуть сканувати pending транзакції і снайперити рідкісні трейти через frontrunning. Але reveal вимагає commitment scheme — випадковий seed має бути зафіксований до mint або використовувати Chainlink VRF.

Chainlink VRF для чесної рандомізації трейтів. VRF request в момент mint → callback з verifiable random number → assign traits. Це додає ~2 транзакції та latency, але гарантує чесність. Посилання на Chainlink VRF v2.5.

Rate limiting — require(mintedPerWallet[msg.sender] < maxPerWallet). Не захищає від мульти-гаманців, але піднімає вартість атаки. Для преміум-проектів часто додаємо proof-of-work прямо в контракт (через EIP-2612 signatures).

Royalties: реальний стан ринку

ERC-2981 — on-chain стандарт роялті. Контракт повертає (recipient, amount) для будь-якої sale price через royaltyInfo(tokenId, salePrice). Маркетплейси опитують це при кожному продажу. Проблема: дотримання роялті — добровільне рішення маркетплейсу. Blur запустився з нульовими роялті, що викликало хвилю інших платформ. Зараз ситуація частково стабілізувалася: OpenSea підтримує ERC-2981, Blur додав опціональні.

Спроби enforce роялті on-chain через обмеження transfers тільки на approved маркетплейси (operator filtering) OpenSea пропонував через OperatorFilterRegistry. Це ламає composability — не можна передати NFT через кастомний контракт. Більшість серйозних проектів відмовилися від цього підходу. Для проектів, де роялті критичні, ми будуємо кастомний маркетплейс всередині екосистеми + incentive structure для користувачів торгувати саме там.

Lazy minting та gas-free mint

Gas-free mint через підпис: творець підписує voucher (tokenId, tokenURI, price, signature), покупець надає voucher в mint() — контракт верифікує підпис через ECDSA.recover() і минтить. Працює на OpenSea через їх Seaport протокол. Seaport — оптимізований контракт з мінімальним gas usage. Розуміння його механіки важливе при інтеграції custom marketplace логіки.

Стек для NFT-проектів

• Контракти: Solidity 0.8.x, OpenZeppelin ERC721Enumerable або ERC721A (Azuki) для gas-оптимізованого batch mint, ERC1155 від OpenZeppelin
• VRF та автоматизація: Chainlink VRF v2.5, Chainlink Automation
• Зберігання: Pinata (IPFS pinning), NFT.Storage, Arweave для постійного зберігання
• Маркетплейс: OpenSea Seaport protocol, кастомна інтеграція
• Фронтенд: wagmi v2 + viem, RainbowKit для wallet connection, React + TypeScript

Процес розробки

1. Проектування mint-механіки — allowlist, public sale, price curve (Dutch auction або фіксована), limits per wallet
2. Контракти — з Foundry fuzz-тестами на mint limits, merkle proof-верифікацію, royalty calculations
3. IPFS деплой — завантаження метаданих та images до reveal, піннінг на мінімум двох сервісах
4. Reveal — якщо використовується Chainlink VRF, тест на testnet обов'язковий: VRF subscription має бути funded LINK токенами
5. Маркетплейс-інтеграція — верифікація колекції на OpenSea, налаштування роялті, тест MetadataUpdate events
6. Деплой та моніторинг — Tenderly для відлову reentrancy, Etherscan API для верифікації контракту, налаштування оповіщень за подіями

Що входить в роботу (deliverables)

• Вихідний код смарт-контрактів (Solidity, Rust для Solana) з коментарями
• Тест-сьют (Foundry/Hardhat) з покриттям ≥90%
• Документація розгортання та інструкції з інтеграції
• Доступи до pinning-сервісів (Pinata/Pinfluence)
• Скрипти для генерації метаданих (Python/JS)
• Підтримка при верифікації на маркетплейсах
• 30 днів технічної підтримки після деплою

Строки

Вартість розраховується індивідуально після аудиту вашого завдання. Надішліть brief з описом проекту — оцінимо прозоро протягом 3 робочих днів. Для постійних клієнтів діє гнучка система знижок на пакетні замовлення. Зв'яжіться з нами для детального обговорення вашого NFT-проекту. Отримайте консультацію з архітектури маркетплейсу — залиште заявку, і ми оцінимо проект за три дні.