Разработка агрегатора NFT-маркетплейсов: лучшие цены и массовый выкуп

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

Мы разрабатываем агрегаторы NFT-маркетплейсов, которые решают проблему разброса ликвидности. Зачем открывать четыре вкладки, если можно купить NFT по лучшей цене в один клик? Наши агрегаторы объединяют OpenSea, Blur, LooksRare, X2Y2 и другие площадки, собирая все ордера в единый листинг и исполняя сделку через оптимальный маршрут. Такие проекты, как Gem.xyz и Reservoir, стали стандартами индустрии, но для специализированных ниш (gaming, phygital, traits) остаётся огромный потенциал.

Оценим ваш проект бесплатно — свяжитесь с нами.

Как работает агрегатор NFT?

Агрегатор — это связка смарт-контрактов и backend-инфраструктуры. Смарт-контракты обеспечивают атомарную покупку нескольких NFT за одну транзакцию, а backend индексирует ордера со всех площадок и предоставляет API для фронтенда. Фронтенд отображает единый список, позволяет фильтровать по трейтам, цене и источнику, а также формировать корзину для массового выкупа.

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

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

Ключевой компонент — агрегатор-контракт, который в одной транзакции закупает 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-оптимизацию — пользователь всё равно получает часть запрошенного. Атомарность критична для sweep, где транзакция может включать десятки ордеров.

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

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

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

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

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

Indexing и data layer

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

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

• Маrкетплейс 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 — унифицированные.

Этапы разработки агрегатора NFT

1. Анализ требований: определяем целевую аудиторию, функциональность (sweep, traits, cross-chain), список маркетплейсов.
2. Проектирование смарт-контрактов: разработка архитектуры batchBuy, адаптеров для каждого маркетплейса, тестирование на fork-сетях.
3. Разработка indexing layer: настройка индексеров, интеграция с API и on-chain слушателями, кэширование.
4. Frontend: UI/UX дизайн, реализация поиска, корзины, интеграция с кошельками (MetaMask, WalletConnect).
5. Тестирование: unit-тесты контрактов (Foundry), fuzzing (Echidna), интеграционные тесты на testnet.
6. Аудит безопасности: проверка контрактов через Slither/Mythril, внешний аудит.
7. Деплой и мониторинг: развертывание на mainnet, настройка Tenderly, Grafana.

Что входит в работу

• Разработка смарт-контрактов агрегатора и адаптеров под 5+ маркетплейсов
• Backend-индексация ордеров (собственный indexer или на базе Reservoir)
• Фронтенд с поиском, фильтрацией, корзиной и интеграцией кошельков
• Интеграция с мультичейном (Ethereum, Polygon, Arbitrum, Base)
• Аудит безопасности и оптимизация газа
• Документация API и смарт-контрактов
• Поддержка после запуска (3 месяца)

Сроки ориентировочно

Стоимость рассчитывается индивидуально в зависимости от сложности и количества интеграций.

Наша команда имеет 5+ лет опыта в блокчейн-разработке и реализовала более 20 проектов в сфере DeFi и NFT, включая агрегаторы маркетплейсов. Мы гарантируем соблюдение современных стандартов безопасности и оптимизацию газа.

Оценим ваш проект бесплатно — пишите нам для консультации.