Розробка NFT-маркетплейсу: Seaport, аукціони, роялті під ключ

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

OpenSea обробляє мільярди доларів торгів, але більшість кастомних маркетплейсів помирають від однієї з трьох проблем: вразливість у логіці лістингу (дозволяє купити NFT за старою ціною після його передачі), відсутність royalty enforcement або неможливість масштабувати оферти без on-chain транзакції за кожну. Ми вирішуємо ці проблеми технічно — застосовуємо перевірені протоколи та сучасні практики.

Протоколи лістингу: не винаходь велосипед

Seaport — стандарт де-факто

OpenSea's Seaport Protocol (v1.5, аудит Spearbit + Trail of Bits) — найвивіреніша основа для маркетплейсу. Ключова перевага: ордери існують off-chain як підписані EIP-712 структури. Лістинг не коштує газу. Тільки виконання ордера (fulfilment) — on-chain транзакція.

Архітектура Seaport: offerer підписує Order з offer[] (що пропоную) та consideration[] (що хочу отримати натомість). Це узагальнена swap-примітива: NFT за ETH, NFT за ERC-20, NFT за NFT, batch orders. conduit — авторизований контракт, який може переводити токени від імені offerer за умови approve. Це прибирає необхідність approve до маркетплейсу напряму — approve видається Conduit Controller, який маркетплейс реєструє.

Чому важливо: якщо маркетплейс реалізує власний лістинг зі зберіганням ордерів on-chain — кожен лістинг коштує ~50-80k gas. При 10,000 лістингів на день це суттєві витрати. Off-chain підписи — єдиний масштабований підхід. Економія газу на лістингах досягає 80% за рахунок off-chain підписів.

Як протокол Seaport захищає від replay атак?

Класична атака на кастомні маркетплейси: користувач лістить NFT за 1 ETH, потім передає його на інший гаманець. Лістинг формально не скасовано (немає on-chain cancel). Новий власник лістить за 100 ETH. Атакуючий виконує старий лістинг (якщо підпис валідний) — купує за 1 ETH, NFT йде зі старого лістингу, але власник уже змінився.

Seaport вирішує це через offererConduitKey + counter. incrementCounter() — одна транзакція, інвалідизує всі раніше підписані ордери цього адреса. Також кожен ордер може мати startTime / endTime — автоматичне завершення без скасування.

Royalty enforcement: чому EIP-2981 недостатньо?

EIP-2981 визначає royaltyInfo(uint256 tokenId, uint256 salePrice) — стандарт для зберігання інформації про роялті в контракті NFT. Але це advisory механізм — маркетплейс може ігнорувати його. Саме це робили більшість агрегаторів кілька років тому, обходячи royalty creator'ів.

Enforced royalty можливе через кілька підходів:

• Operator Filter Registry (підхід OpenSea) — NFT-контракт у setApprovalForAll та transferFrom перевіряє, що operator знаходиться в whitelist Operator Filter Registry. Маркетплейси без royalty enforcement блокуються. Мінус: creator повинен підтримати, користувачі втрачають transferability при відмові маркетплейсу.
• ERC-721C (LimitBreak) — модифікований transfer з built-in policy engine. Більш гнучко: різні політики для різних колекцій. Але нестандартний контракт.
• Soulbound + secondary market через власний контракт — NFT з обмеженим transfer, всі вторинні продажі тільки через протокол з royalty enforcement. Радикально, але працює для gaming assets.

Для нашого маркетплейсу: реалізуємо EIP-2981 як мінімум, пропонуємо опціональний Operator Filter для колекцій, які хочуть enforced royalty.

Як впровадити enforced royalty в маркетплейс?

1. Визначте політику роялті — відсоток та отримувач для кожного токена.
2. Додайте EIP-2981 в контракт NFT.
3. Інтегруйте Operator Filter — зареєструйте маркетплейс у реєстрі, якщо потрібно примусове виконання.
4. Налаштуйте контракт маркетплейсу — перевіряйте royaltyInfo при кожній угоді та переводьте комісію творцю.
5. Протестуйте на тестнеті — переконайтеся, що роялті виплачуються коректно навіть при bulk transfers.

Аукціони: технічні складнощі

Як захиститися від bid snipping в English auction?

Класичний English auction: кожен bid продовжує аукціон на N хвилин. Це стандартний захист від bid snipping (останньосекундні ставки). У Solidity: if (block.timestamp > endTime - extensionWindow) endTime += extensionWindow.

Критичний момент: зберігати всі біди on-chain дорого. Краще зберігати тільки highestBid та highestBidder. Попередній highest bidder отримує рефанд автоматично при кожному новому біді через pull payment pattern.

Чому Dutch auction потребує обережності на L2?

Ціна стартує високо і падає кожні N хвилин/блоків. Математика:

currentPrice = startPrice - (startPrice - endPrice) * elapsed / duration 

Небезпека: якщо використовуєш block.number замість block.timestamp на L2 (Optimism, Arbitrum) — block time нестабільний, ціна падає нерівномірно. Завжди block.timestamp для time-based logic на L2. Зниження вартості деплою на 40% при використанні Optimism — один із плюсів L2.

Refund mechanism в dutch auction — якщо користувач мінтил за ціною $100, а фінальна ціна виявилася $60, різниця має бути повернута. Це settlementPrice refund pattern: записуємо кожну транзакцію, після закінчення аукціону користувачі claim рефанд.

Що входить у розробку NFT-маркетплейсу?

Архітектура та стек

Subgraph як основа даних

Маркетплейс без subgraph — це маркетплейс без історії. The Graph індексує події контрактів: OrderFulfilled, OrderCancelled, Transfer, RoyaltyPaid. Схема entities: Token, Collection, Order, Sale, Account. GraphQL запити дають history, trending, floor price — все без on-chain RPC викликів.

Floor price розраховується off-chain за активними лістингами, зберігається в PostgreSQL, оновлюється при кожному новому лістингу/скасуванні через webhook від subgraph.

Приклад розрахунку ціни голландського аукціону:

function getCurrentPrice(uint256 _saleStart, uint256 _saleEnd) public view returns (uint256) { uint256 elapsed = block.timestamp - _saleStart; uint256 duration = _saleEnd - _saleStart; if (elapsed >= duration) return endPrice; return startPrice - ((startPrice - endPrice) * elapsed / duration); } 

Процес роботи

Аналітика (3-5 днів). Визначаємо: типи активів (ERC-721 / ERC-1155 / змішано), чи потрібен primary mint через маркетплейс, вимоги до royalty enforcement, target chains.

Проектування (1 тиждень). Архітектура контрактів, схема subgraph, database schema, API endpoints.

Розробка (4-8 тижнів). Smart contracts + subgraph + backend API + frontend. Паралельні треки зі стикуванням на етапі інтеграції.

Тестування. Fork-тести з реальними Seaport ордерами. E2E тести на Sepolia.

Аудит та деплой. Акцент аудиту: replay attacks, royalty bypass, bid manipulation в аукціонах. Деплой з multisig owner.

Spearbit Audit Report

Орієнтири за термінами

MVP маркетплейс з fixed-price лістингами на базі Seaport — 3-4 тижні. Повноцінна платформа з аукціонами, offers, royalty enforcement та subgraph — 2-3 місяці.

Вартість розраховується після аналізу вимог.

З нашою командою, яка має 5+ років досвіду в блокчейн-розробці та 15+ реалізованих проектів, ви отримуєте гарантію якості та безпеку контрактів. Отримайте консультацію по вашому проекту — зв'яжіться з нами. Замовте розробку — ми оцінимо ваш проект і запропонуємо оптимальне рішення.