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

Архітектура white-label NFT-маркетплейсу

Уявіть: ви запускаєте NFT-маркетплейс, але кастомна розробка торгової логіки займає 3-6 місяців і потребує дорогого аудиту. White-label рішення на базі Seaport скорочує цей час на 60% і знижує ризики безпеки. Seaport — протокол, який пройшов аудит і обробляє мільярди доларів. Ми розробляємо white-label NFT-маркетплейси на його основі, підтримуючи всі актуальні стандарти: ERC-721, ERC-1155, ERC-20 як платіжний засіб. Замість того щоб писати торгову логіку з нуля, ми використовуємо Seaport як ядро, зосереджуючись на бізнес-логіці, брендингу та UX. Завдання white-label маркетплейсу — кастомізувати інтерфейс, додати унікальні функції (наприклад, token-gated торгівлю) та забезпечити мультичейн підтримку. White-label рішення на основі Seaport в 3 рази швидше виходить на ринок порівняно з кастомним контрактом. Наша компанія займається блокчейн-розробкою понад 5 років і реалізувала більше 15 маркетплейсів.

Seaport підтримує гнучку систему ордерів через OrderComponents. Базові кейси для маркетплейсу включають fixed price listing, auction, bundle trading та collection offers. Всі ці функції вже реалізовані в протоколі — залишається налаштувати frontend та додати кастомні комісії. Ми також налаштовуємо протокольні комісії та роялті відповідно до вашої бізнес-моделі. Платформа стягує комісію 1-2.5% з кожної угоди, яка закладається в ордер як consideration item. При цьому Seaport не стягує власну комісію — всі збори залишаються у вас. Ви отримуєте готовий до запуску продукт з мінімальними витратами на розробку та аудит.

Які контракти ми кастомізуємо?

Zone контракти — Seaport підтримує zones: додаткова валідація ордера при виконанні. Використовуємо для:

• Токен-gated торгівлі (тільки holders певної колекції)
• Географічних обмежень (off-chain верифікація через signature)
• Кастомних умов (ордер дійсний лише до певного блоку)

ConduitController — управління approved transfer operators. Conduit дозволяє користувачам дати схвалення (approve) один раз, і всі маркетплейси, що використовують цей conduit, можуть виконувати трансфери. Знижує кількість approve-транзакцій.

Кастомний ERC-721 для колекцій платформи — якщо маркетплейс також дозволяє мінтити колекції (creator marketplace), потрібен factory контракт для деплою колекцій та royalty management система.

Чому white-label на Seaport вигідніше кастомної розробки?

Кастомна розробка торгової логіки займає 3-6 місяців і потребує дорогого аудиту. Seaport вже пройшов аудит і використовується тисячами проєктів. Ми налаштовуємо zone контракти для унікальних правил торгівлі, що дає гнучкість без втрати безпеки. Seaport підтримує в 2 рази більше типів ордерів, ніж типовий кастомний маркетплейс. Підсумкова економія на розробці та аудиті може бути суттєвою, і ви отримуєте перевірене рішення. Зв'яжіться з нами, щоб обговорити деталі вашого проєкту.

Фронтенд та індексація

Відображення NFT та стану ордерів потребує off-chain індексації — запитувати блокчейн при кожному page load неприйнятно через latency.

The Graph — subgraph для Seaport подій (OrderFulfilled, OrderCancelled, OrderValidated) та колекцій (Transfer, Mint). GraphQL API для frontend.

Alchemy NFT API / Reservoir Protocol — готові API для NFT даних: медіа, метадані, ownership, ринкові дані. Reservoir додатково агрегує ордери з інших маркетплейсів — корисно для price discovery.

Orderbook — оффчейн сховище підписаних ордерів. PostgreSQL з індексацією за колекцією, ціною, expiration. REST API для frontend. При відміні ордера — м'яке видалення з бази + on-chain cancel через Seaport для гарантії.

Frontend стек — Next.js + wagmi + viem + RainbowKit (або кастомний wallet modal). NFT-галерея на віртуалізованому списку (react-window) для продуктивності з тисячами токенів.

Панель адміністратора

Управління колекціями: верифікація (galactic badge), приховування/блокування токенів, налаштування featured. Моніторинг транзакцій, volume по колекціях. Управління fee параметрами. Тонкий SPA на React з тим же wagmi stack.

Чейни та мультичейн

Seaport задеплоєно на Ethereum, Polygon, Arbitrum, Optimism, Base, Avalanche та інших. Мультичейн маркетплейс — не переписування контрактів, а мультичейн frontend з правильним chain switching та окремими subgraph для кожного чейну.

Типи ордерів та газові витрати

Процес розробки

1. Проєктування (1-2 тижні): бізнес-модель, підтримувані чейни, feature set, UI wireframes, API схема.
2. Smart contract рівень (1-2 тижні): Zone контракти, fee configuration, factory для колекцій (якщо потрібен). Тести в Foundry з fork-тестами Seaport.
3. Індексація (1-2 тижні): Subgraph деплой, orderbook backend, NFT data pipeline через Alchemy.
4. Frontend (3-5 тижнів): Галерея, сторінки токенів, listing flow, checkout, профіль користувача, колекції. Адаптивний дизайн.
5. Admin панель (1-2 тижні): Модерація, аналітика, налаштування.
6. QA та деплой: Тестнет прогін з реальними користувачами, навантажувальне тестування API.

Замовте розробку прямо сьогодні — наші інженери проконсультують щодо вибору чейнів та архітектури.

Як ми гарантуємо якість?

Кожен контракт проходить перевірку на вразливості за допомогою Slither та Mythril, а також фаззінг-тестування через Echidna. Для кастомних zone контрактів проводиться додатковий аудит. Аудит смарт-контракту сторонньою командою може коштувати дорого, але ми включаємо базову перевірку в кожен проєкт. Отримайте консультацію, щоб дізнатися більше.

Що входить в результат

• Повний код смарт-контрактів (Zone контракти, fee management)
• Subgraph для індексації даних
• Frontend-додаток на Next.js з кастомним брендингом
• Панель адміністратора
• Документація з розгортання та налаштування
• Доступ до репозиторію та підтримка на етапі запуску

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

MVP маркетплейс (fixed price, одна колекція, один чейн) — 6-8 тижнів. Повнофункціональний white-label (аукціони, мультичейн, mint factory, admin) — 12-20 тижнів. Аудит смарт-контрактів (якщо кастомні zone/conduit) — 2-4 тижні поверх розробки.

Для оцінки вашого проєкту та розрахунку термінів зв'яжіться з нами. White-label рішення економить суттєві кошти на розробці та аудиті порівняно зі створенням з нуля. Детальніше про протокол Seaport можна дізнатися на GitHub.

Чому розробка NFT маркетплейсів потребує комплексного підходу?

Ми бачимо, що на перший погляд NFT-контракт виглядає просто: ERC-721, mint(), IPFS для метаданих, і все. На практиці саме в цій «простоті» ховається більшість проблем — від ботів, які скуповують весь mint у першому блоці, до зламаних роялті на вторинному ринку. Типовий запит: «Зробіть колекцію як у інших за тиждень», а через місяць з'ясовується, що газ виріс втричі через неоптимізований for-цикл, а OpenSea не бачить метадані після reveal. Ми знаємо кожні з цих граблів і будуємо процеси так, щоб їх уникнути.

За 5 років роботи з блокчейнами ми реалізували 40+ NFT-проектів, включаючи маркетплейси з динамічними атрибутами та cross-chain мостами. Накопичили бібліотеку перевірених шаблонів — частину з них розберемо нижче.

Який стандарт вибрати: ERC-721 чи ERC-1155?

ERC-721 — кожен токен унікальний, один owner. Підходить для колекцій, де кожен NFT має індивідуальні атрибути та пряму прив'язку owner → tokenId.
ERC-1155 — multi-token стандарт: один контракт зберігає і fungible, і non-fungible токени. Використовує balanceOf(address, tokenId) замість ownerOf(tokenId). Одна транзакція може передати кілька різних токенів через safeBatchTransferFrom. Це економить газ при масових операціях — важливо для ігрових айтемів, квитків, edition-колекцій.

Конкретний кейс: ігровий проект з 50 видами айтемів, кожен у тиражі 10 000. ERC-721 — 500 000 унікальних токенів, величезний overhead на маппінги. ERC-1155 — 50 tokenId, balanceOf на кожного гравця. Газ на transfer нижче в 2–3 рази, деплой контракту дешевший. Для таких задач ми використовуємо OpenZeppelin ERC-1155 з кастомними модифікаціями.

Метадані: on-chain vs IPFS vs centralized

Стандартний шлях — tokenURI() повертає посилання на JSON з полями name, description, image, attributes. Три варіанти зберігання:

• Centralized server — найдешевший і гнучкий. Ризик: сервер падає, компанія закривається — NFT втрачає метадані. Не підходить для колекцій з претензією на довгострокову цінність.
• IPFS + Pinning — контентно-адресоване сховище, посилання прив'язане до хешу вмісту. Pinata або NFT.Storage забезпечують pіннінг. Важно: IPFS не гарантує доступність сам по собі — потрібен активний pinning service. Якщо він закриється, дані можуть зникнути, якщо ніхто не зберігає копію.
• On-chain metadata — base64-encoded SVG або JSON прямо в tokenURI. Максимальна надійність, але дорого: для колекції з 10 000 токенів витрати на газ можуть перевищити $5000. Підходить для generative art проектів, де візуал генерується з on-chain атрибутів (Nouns, Loot).

Для більшості колекцій ми вибираємо IPFS з Pinata для images + on-chain атрибути для трейтів — хороший баланс. Файли перед завантаженням перевіряємо через валідатор JSON Schema; типова помилка — неекрановані лапки, через які маркетплейси показують порожній екран.

Dynamic NFT: метадані, які змінюються

Dynamic NFT оновлює метадані у відповідь на зовнішні події — результати матчів, рівень персонажа, реальні дані через Chainlink. Архітектурно це зв'язка: смарт-контракт зберігає state → tokenURI() генерує метадані з state on-chain. Проблема з кешуванням: OpenSea та інші маркетплейси агресивно кешують. Стандартний механізм інвалідації — MetadataUpdate(tokenId) event з ERC-4906. OpenSea слухає цей event і скидає кеш. Без нього оновлені метадані можуть не відображатися тижнями.

Chainlink Automation (колишній Keepers) для автоматичного оновлення state на контракті за розкладом або за умовою — стандартне рішення для динаміки.

Як захистити mint від ботів?

Allowlist через merkle tree — стандарт. Список адрес хешується в merkle root, зберігається в контракті. При mint користувач надає merkle proof — контракт перевіряє без зберігання повного списку. Використовуємо OpenZeppelin MerkleProof library.

Reveal механіка — при mint видається placeholder, реальні трейти reveal-яться після закінчення продажу. Інакше боти можуть сканувати pending транзакції і снайперити рідкісні трейти через frontrunning. Але reveal вимагає commitment scheme — випадковий seed має бути зафіксований до mint або використовувати Chainlink VRF.

Chainlink VRF для чесної рандомізації трейтів. VRF request в момент mint → callback з verifiable random number → assign traits. Це додає ~2 транзакції та latency, але гарантує чесність. Посилання на Chainlink VRF v2.5.

Rate limiting — require(mintedPerWallet[msg.sender] < maxPerWallet). Не захищає від мульти-гаманців, але піднімає вартість атаки. Для преміум-проектів часто додаємо proof-of-work прямо в контракт (через EIP-2612 signatures).

Royalties: реальний стан ринку

ERC-2981 — on-chain стандарт роялті. Контракт повертає (recipient, amount) для будь-якої sale price через royaltyInfo(tokenId, salePrice). Маркетплейси опитують це при кожному продажу. Проблема: дотримання роялті — добровільне рішення маркетплейсу. Blur запустився з нульовими роялті, що викликало хвилю інших платформ. Зараз ситуація частково стабілізувалася: OpenSea підтримує ERC-2981, Blur додав опціональні.

Спроби enforce роялті on-chain через обмеження transfers тільки на approved маркетплейси (operator filtering) OpenSea пропонував через OperatorFilterRegistry. Це ламає composability — не можна передати NFT через кастомний контракт. Більшість серйозних проектів відмовилися від цього підходу. Для проектів, де роялті критичні, ми будуємо кастомний маркетплейс всередині екосистеми + incentive structure для користувачів торгувати саме там.

Lazy minting та gas-free mint

Gas-free mint через підпис: творець підписує voucher (tokenId, tokenURI, price, signature), покупець надає voucher в mint() — контракт верифікує підпис через ECDSA.recover() і минтить. Працює на OpenSea через їх Seaport протокол. Seaport — оптимізований контракт з мінімальним gas usage. Розуміння його механіки важливе при інтеграції custom marketplace логіки.

Стек для NFT-проектів

• Контракти: Solidity 0.8.x, OpenZeppelin ERC721Enumerable або ERC721A (Azuki) для gas-оптимізованого batch mint, ERC1155 від OpenZeppelin
• VRF та автоматизація: Chainlink VRF v2.5, Chainlink Automation
• Зберігання: Pinata (IPFS pinning), NFT.Storage, Arweave для постійного зберігання
• Маркетплейс: OpenSea Seaport protocol, кастомна інтеграція
• Фронтенд: wagmi v2 + viem, RainbowKit для wallet connection, React + TypeScript

Процес розробки

1. Проектування mint-механіки — allowlist, public sale, price curve (Dutch auction або фіксована), limits per wallet
2. Контракти — з Foundry fuzz-тестами на mint limits, merkle proof-верифікацію, royalty calculations
3. IPFS деплой — завантаження метаданих та images до reveal, піннінг на мінімум двох сервісах
4. Reveal — якщо використовується Chainlink VRF, тест на testnet обов'язковий: VRF subscription має бути funded LINK токенами
5. Маркетплейс-інтеграція — верифікація колекції на OpenSea, налаштування роялті, тест MetadataUpdate events
6. Деплой та моніторинг — Tenderly для відлову reentrancy, Etherscan API для верифікації контракту, налаштування оповіщень за подіями

Що входить в роботу (deliverables)

• Вихідний код смарт-контрактів (Solidity, Rust для Solana) з коментарями
• Тест-сьют (Foundry/Hardhat) з покриттям ≥90%
• Документація розгортання та інструкції з інтеграції
• Доступи до pinning-сервісів (Pinata/Pinfluence)
• Скрипти для генерації метаданих (Python/JS)
• Підтримка при верифікації на маркетплейсах
• 30 днів технічної підтримки після деплою

Строки

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