Розробка NFT-маркетплейса
OpenSea обробляє мільярди доларів торгів, але це не означає, що "зробити маркетплейс" — проста задача. Більшість кастомних маркетплейсів умирають від однієї з трьох проблем: уразливість в логіці листингу (дозволяє купити NFT по старій ціні після передачі), відсутність royalty enforcement, або неможливість масштабювати оферти без on-chain транзакції за кожну. Ці проблеми технічно вирішені в сучасних протоколах — потрібно тільки правильно їх застосувати.
Протоколи листингу: не винаходь велосипед
Seaport — стандарт де-факто
Seaport Protocol від OpenSea (v1.5, аудит Spearbit + Trail of Bits) — найбільш перевірена основа для маркетплейса. Ключова перевага: ордери існують off-chain як підписані EIP-712 структури. Листинг не коштує газу. Тільки виконання ордера (fulfillment) — on-chain транзакція.
Архітектура Seaport: offerer підписує Order з offer[] (що пропоную) й consideration[] (що хочу отримати взамін). Це узагальнена swap-примітива: NFT за ETH, NFT за ERC-20, NFT за NFT, batch ордери. conduit — авторизований контракт, який може переводити токени від імені offerer при умові approve. Це убирає необхідність approve до маркетплейса напрямки — approve видається Conduit Controller, який маркетплейс реєструє.
Чому важливо: якщо маркетплейс реалізує власний листинг з зберіганням ордерів on-chain — кожен листинг коштує ~50–80k газу. При 10,000 листингів на день це $50k/день тільки на листинги (при gas 20 gwei, ETH $2500). Off-chain підписи — єдиний масштабуємий підхід.
Критична уразливість: 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 механізм — маркетплейс може його ігнорувати. Більшість агрегаторів у 2022–2023 році робили саме це, обходячи royalty творців.
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.
Аукціони: технічні складності
English auction та bid snipping
Класичний 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 для мінтингу
Ціна стартує високо й падає кожні N хвилин/блоків. Математика:
currentPrice = startPrice - (startPrice - endPrice) * elapsed / duration
Небезпека: якщо використовувати block.number замість block.timestamp на L2 (Optimism, Arbitrum) — block time нестабільний, ціна падає неравномерно. Завжди block.timestamp для time-based logic на L2.
Refund механізм в dutch auction — якщо користувач мінтив по ціні $100, а фінальна ціна $60, різниця має бути повернена. Це settlementPrice refund pattern: записуємо кожну транзакцію, після закінчення аукціону користувачі claim рефанд.
Архітектура та стек
| Шар | Технологія | Комментар |
|---|---|---|
| Order protocol | Seaport v1.5 | Off-chain підписи, audited |
| NFT standard | ERC-721 + ERC-2981 | Royalty інформація |
| Batch transfers | ERC-1155 | Для gaming/edition NFT |
| Metadata | IPFS (Pinata/NFT.Storage) | Децентралізоване зберігання |
| Indexing | The Graph (subgraph) | Історія сделок, листинги |
| Frontend | wagmi + viem | WalletConnect v2, MetaMask |
| Search/filter | PostgreSQL + Elasticsearch | Off-chain індекс для швидкості |
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.
Процес роботи
Аналітика (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.
Кошторис по часу
MVP маркетплейс з fixed-price листингами на базі Seaport — 3–4 тижні. Повноцінна платформа з аукціонами, offers, royalty enforcement та subgraph — 2–3 місяці.
Вартість розраховується після аналізу вимог.