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