Разработка агрегатора 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 (купи что смог, верни деньги за остальное). Gem использовал второй подход как UX-оптимизацию — пользователь всё равно получает часть запрошенного.

Поддержка форматов ордеров

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

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

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

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

Indexing и data layer

Агрегатор без актуальных данных — бесполезен. 90% сложности — в infrastructure для сбора и обновления ордеров.

Источники данных

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

On-chain события: слушать OrderFulfilled, OrderCancelled события Seaport и аналоги на других маркетплейсах. WebSocket подписка через Alchemy/Infura для real-time updates. Задержка 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, specific категории как gaming NFTs, phygital).

Multichain — обязательно: Ethereum, Polygon, Base, Arbitrum, Blast. Для каждого чейна нужен отдельный indexer, но контракт агрегатора и frontend — унифицированные.

Ориентиры по срокам

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