Розробка агрегатора 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, включаючи агрегатори маркетплейсів. Ми гарантуємо дотримання сучасних стандартів безпеки та оптимізацію газу.

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