Разработка агрегатора 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, где транзакция может включать десятки ордеров.
Поддержка форматов ордеров
Каждый маркетплейс — свой стандарт:
| Маркетплейс | Стандарт | Особенности |
|---|---|---|
| OpenSea (Seaport) | Seaport 1.5 | EIP-712, zone/conduit архитектура |
| Blur | Blur Exchange | Собственный, bid pool |
| LooksRare | LooksRare v2 | ERC-2981 royalties обязательны |
| X2Y2 | X2Y2 v1 | Нужен backend для получения callable calldata |
| Rarible | ExchangeV2 | Поддержка ERC-1155 + bundles |
| Foundation | Foundation Market | Только primary, собственный формат |
Для каждого нужен отдельный 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
- Анализ требований: определяем целевую аудиторию, функциональность (sweep, traits, cross-chain), список маркетплейсов.
- Проектирование смарт-контрактов: разработка архитектуры batchBuy, адаптеров для каждого маркетплейса, тестирование на fork-сетях.
- Разработка indexing layer: настройка индексеров, интеграция с API и on-chain слушателями, кэширование.
- Frontend: UI/UX дизайн, реализация поиска, корзины, интеграция с кошельками (MetaMask, WalletConnect).
- Тестирование: unit-тесты контрактов (Foundry), fuzzing (Echidna), интеграционные тесты на testnet.
- Аудит безопасности: проверка контрактов через Slither/Mythril, внешний аудит.
- Деплой и мониторинг: развертывание на mainnet, настройка Tenderly, Grafana.
Что входит в работу
- Разработка смарт-контрактов агрегатора и адаптеров под 5+ маркетплейсов
- Backend-индексация ордеров (собственный indexer или на базе Reservoir)
- Фронтенд с поиском, фильтрацией, корзиной и интеграцией кошельков
- Интеграция с мультичейном (Ethereum, Polygon, Arbitrum, Base)
- Аудит безопасности и оптимизация газа
- Документация API и смарт-контрактов
- Поддержка после запуска (3 месяца)
Сроки ориентировочно
| Этап | Срок |
|---|---|
| MVP (1 цепь, 2 маркетплейса) | 2-3 недели |
| Полный продукт (5+ маркетплейсов, мультичейн, аналитика) | 2-3 месяца |
| Аудит и оптимизация | +2-4 недели |
Стоимость рассчитывается индивидуально в зависимости от сложности и количества интеграций.
Наша команда имеет 5+ лет опыта в блокчейн-разработке и реализовала более 20 проектов в сфере DeFi и NFT, включая агрегаторы маркетплейсов. Мы гарантируем соблюдение современных стандартов безопасности и оптимизацию газа.
Оценим ваш проект бесплатно — пишите нам для консультации.