Розробка агрегатора NFT-маркетплейсів

Розробка агрегатора NFT-маркетплейсів

Проблема, яку розв'язує агрегатор, проста: один і той же NFT може бути виставлен на OpenSea, Blur, LooksRare та X2Y2 одночасно по різних цінах. Покупець, який шукає найкращу ціну, змушений відкривати 4 вкладки. Агрегатор, як 1inch для токенів, збирає ордери з усіх площадок, показує єдиний листинг та виконує угоду через оптимальний маршрут. Gem.xyz та Reservoir зробили це і стали стандартами індустрії — але можливості для спеціалізованих агрегаторів залишаються.

Архітектура на рівні смарт-контрактів

Виконання мультимаркетплейс-угод

Ключовий компонент — агрегатор-контракт, який в одній транзакції закупляє NFT з кількох площадок:

contract NFTAggregator {
    struct TradeData {
        address marketplace;
        bytes tradeData;      // calldata для конкретного маркетплейсу
        uint256 value;        // ETH для цієї частини угоди
        bool isERC721;
    }

    function batchBuy(TradeData[] calldata trades) external payable {
        for (uint256 i = 0; i < trades.length; i++) {
            (bool success, ) = trades[i].marketplace.call{value: trades[i].value}(
                trades[i].tradeData
            );
            if (!success) {
                // Partial fill або revert залежно від політики
                emit TradeFailed(i, trades[i].marketplace);
            }
        }
        // Повернути невитрачений ETH
        if (address(this).balance > 0) {
            payable(msg.sender).transfer(address(this).balance);
        }
    }
}

Критичний момент: атомарність. Якщо перші 3 NFT куплені, а 4-й вже проданий — що робити? Два режими: failOnRevert (revert все якщо щось не виконалося) та skipFailed (куп що зміг, верни грошi за решту). Gem використав другий підхід як UX-оптимізацію — користувач все одно отримує частину запрошеного.

Підтримка форматів ордерів

Кожен маркетплейс — свій стандарт:

Для кожного потрібен окремий adapter. Seaport — найскладніший: підтримує criteria-based ордери (можна купити будь-який токен з колекції з певними traits), advanced orders з partial fill, multiple recipients для royalties.

Sweeping та trait-based покупки

Sweep (масова закупка знизу цінового діапазону) — основна функція для колекціонерів та трейдерів. Trait-sweep: купити всі «легендарні» з доступних, незалежно від маркетплейсу. Потребує criteria-based matching у Seaport або off-chain фільтрації з on-chain виконанням.

Indexing та data layer

Агрегатор без актуальних даних — марний. 90% складності — в інфраструктурі для збору та оновлення ордерів.

Джерела даних

Marketplace API: OpenSea API v2, Blur API (частково закритий), Reservoir protocol як meta-aggregator з відкритим API. Reservoir індексує більшість маркетплейсів та надає unified API — розумно використовувати його як foundation, додаючи власне індексування для специфичних випадків.

On-chain подіїї: слухати OrderFulfilled, OrderCancelled подіїї Seaport та аналоги на інших маркетплейсах. WebSocket підписка через Alchemy/Infura для real-time оновлень. Затримка 1-2 блоки — прийнятна для більшості use cases.

Власний indexer: для production — власний indexer на базі The Graph subgraph або кастомного рішення на Go/TypeScript. Зберігання ордерів у PostgreSQL з індексами по (contract, tokenId, price). Redis для гарячих даних (floor price, recent sales).

Проблема staleness

Ордери застарівають. Найкращий листинг на OpenSea може бути вже виконаний, поки користувач натискає «Купити». Рішення:

• Перевірка on-chain статусу ордера перед відображенням (дорого за RPC calls)
• Optimistic UI з fallback на наступний кращий ордер при fail
• Кеш з TTL 30 секунд + real-time інвалідація через подіїї

Blur додатково ускладнює: bid pool дозволяє бачити «доступні» bid, які можуть бути заповнені конкурентами швидше, ніж прийде транзакція.

Frontend архітектура

Пошук та фільтрація

Полнотекстовий пошук по назві колекції + фільтри: trait-based, price range, marketplace source, verification status (verified/unverified collection). Elasticsearch або Meilisearch для швидкого пошуку по мільйонам токенів.

Віртуалізований список (react-virtual або tanstack-virtual) — колекції з 10k токенів не рендерюються в DOM цілком.

Корзина (cart)

Агрегатор без корзини — просто поисковик. Корзина: додати кілька NFT з різних маркетплейсів, показати суммарну вартість + gas estimate, виконати однією транзакцією. Технічно — формування TradeData[] масиву на frontend з подальшим викликом batchBuy().

Gas estimation для batch-транзакцій нетривіальна: кожен маркетплейс споживає різну кількість газу, плюс overhead агрегатора. Використовуємо eth_estimateGas з невеликим буфером (10-20%) або precomputed gas lookup table по типам маркетплейсів.

Royalty compliance

Після Blur, який ввів опціональні royalties та захопив долю ринку, тема стала політичною. Агрегатор повинен явно показувати, які royalties будуть виплачені при кожній покупці, та давати користувачу вибір — або застосовувати політику проекту автоматично (спираючись на onchain royalty registry EIP-2981 + Manifold Registry).

Monetization та конкурентне позиціонування

Стандартні моделі: 0.5-1% fee від обсягу угод, pro-підписка для аналітики, API access для інших проектів. Blur руйнував ринок листингових fees — конкурувати потрібно на UX, швидкості, аналітиці, спеціалізації (нішеві chains, специфічні категорії як gaming NFTs, phygital).

Multi-chain обов'язково: Ethereum, Polygon, Base, Arbitrum, Blast. Для кожного чейна потрібен окремий indexer, але контракт агрегатора та frontend — унічіфіковані.

Орієнтири по строкам

MVP (Ethereum + OpenSea + Blur, базова корзина): 2-3 тижні. Повний продукт (мультичейн, 5+ маркетплейсів, аналітика, trait-based пошук): 2-3 місяці.