Розробка маркетплейсу Ordinals/BRC-20 під ключ

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка маркетплейсу Ordinals/BRC-20 під ключ
Складний
від 2 тижнів до 3 місяців
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1189
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    930

Розробка маркетплейсу Ordinals/BRC-20 під ключ

Відзначимо: коли Bitcoin Ordinals увірвалися в індустрію, розробники зіткнулися із завданням торгівлі активами без смарт-контрактів. Ми вирішили її через атомарні PSBT-угоди. На початковому етапі обсяг торгівлі Ordinals перевищив $1.5 мільярда, мережа Bitcoin кілька разів перевантажувалася через inscription-транзакції. Magic Eden, Ordinals Wallet, Gamma.io — маркетплейси прийшли швидко, але стек розробки принципово інший порівняно з EVM: немає смарт-контрактів, немає native escrow, угоди атомарні через PSBT-механіку. Якщо вам потрібен bitcoin nft маркетплейс, зв’яжіться з нами для консультації.

Протоколи: Ordinals, BRC-20 і Runes

Ordinals — інскрипції в Bitcoin

Ordinals protocol вводить концепцію порядкових номерів для сатоші. Кожен satoshi пронумеровано в порядку майнінгу. Inscription прикріплює дані до конкретного satoshi через Bitcoin Script witness data. Дані зберігаються on-chain в Bitcoin — це відрізняє Ordinals від NFT на Ethereum, де метадані зазвичай в IPFS.

Технічно: inscription створюється через commit-reveal транзакцію. Commit транзакція створює P2TR output з Tapscript, що містить дані. Reveal транзакція тратить цей output, публікуючи дані в witness. Після цього цей satoshi несе inscription і може передаватися як NFT.

Для маркетплейсу критично важливо: парсинг inscription метаданих (JSON, image/png, image/webp, text/plain), визначення Ordinal sat range в UTXO, трекінг ownership через Bitcoin адреси.

BRC-20 — токени поверх Ordinals

BRC-20 — експериментальний стандарт токенів на основі Ordinals. Операції кодуються в JSON-інскрипціях:

{ "p": "brc-20", "op": "deploy", "tick": "ordi", "max": "21000000", "lim": "1000" }
{ "p": "brc-20", "op": "mint", "tick": "ordi", "amt": "1000" }
{ "p": "brc-20", "op": "transfer", "tick": "ordi", "amt": "500" }

Важливо зрозуміти: BRC-20 баланси не зберігаються на адресі як ERC-20. Баланс — це сума unspent transfer-інскрипцій, прив’язаних до адреси. Для торгівлі на маркетплейсі потрібен індексатор — сервіс, який читає всю історію Bitcoin і будує актуальні баланси по кожному адресу. При розробці BRC-20 маркетплейсу ключовим є індексатор.

Runes — наступне покоління

Runes protocol — більш ефективна альтернатива BRC-20. Використовують OP_RETURN output замість witness data, що дешевше. Balances зберігаються в UTXO моделі, ближче до native Bitcoin. Runes вже підтримують кілька маркетплейсів, але екосистема молодша за BRC-20. Якщо розглядати маркетплейс рунів, ми також можемо запропонувати інтеграцію цього протоколу.

Порівняння протоколів

Протокол Тип даних Механізм Перевага Недолік
Ordinals NFT (довільні дані) Witness data Повністю on-chain Велика вага транзакції
BRC-20 Токени (JSON-операції) Witness data Децентралізований Потрібен важкий індексатор
Runes Токени (UTXO модель) OP_RETURN Низькі комісії Менше ліквідності

Як працюють атомарні угоди без смарт-контрактів?

Головна відмінність від EVM маркетплейсів: немає смарт-контракту як escrow. Bitcoin не підтримує довільний код. Угоди робляться через PSBT (Partially Signed Bitcoin Transaction). Детальніше про PSBT можна прочитати в Wikipedia.

Схема лістингу та покупки:

  1. Seller створює PSBT: Input — UTXO з Ordinal, Output — адреса seller + запитана ціна в BTC. Seller підписує тільки свій input з флагом SIGHASH_SINGLE | SIGHASH_ANYONECANPAY.
  2. PSBT публікується на маркетплейс. Маркетплейс зберігає це як лістинг.
  3. Buyer доповнює PSBT: додає свої inputs (BTC для оплати) і output на свою адресу (отримання Ordinal). Підписує своїми ключами.
  4. Транзакція broadcast: атомарна — або seller отримує BTC і buyer отримує Ordinal, або нічого.

SIGHASH_ANYONECANPAY дозволяє seller підписати часткову транзакцію, до якої будь-хто може додати inputs. Це і є atomicity без смарт-контракту. Такий механізм лежить в основі атомарного свопу біткоін.

Для реалізації використовуються бібліотеки: bitcoinjs-lib (JavaScript), rust-bitcoin (Rust). PSBT побудова та валідація — критична частина, помилка тут означає втрату NFT або BTC.

Чому індексатор критичний для ліквідності?

Індексатор — найскладніший компонент. Він повинен:

  1. Читати весь Bitcoin blockchain від genesis (або від блоку появи Ordinals).
  2. Парсити всі inscription транзакції, будувати mapping satoshi → inscription data.
  3. Трекати ownership: з яким Bitcoin адресом пов’язаний кожен Ordinal прямо зараз.
  4. Для BRC-20: парсити JSON операції, рахувати баланси по адресах.
  5. Залишатися синхронізованим з новими блоками в реальному часі (затримка не більше 10 секунд).

Відкриті рішення:

  • ord (оригінальний індексатор Casey Rodarmor, Rust) — reference реалізація.
  • hiro-systems/ordhook — більш продуктивний, підтримує webhooks.
  • unisat/ord-utils — JavaScript бібліотека поверх ord індексатора.

Для маркетплейсу з нуля: запускаємо ord ноду + Bitcoin full node, поверх будуємо власний API з кешуванням в PostgreSQL або Redis. Синхронізація з нуля займає до 5 діб.

Тип індексатора Швидкість синхронізації Підтримка BRC-20 Комерційна ліцензія
ord (reference) 5-7 днів Так MIT
ordhook 2-3 дні Ні (тільки Ordinals) Apache 2.0
Unisat API Миттєво (віддалений) Так Вендорський ключ

При використанні готового індексатора ординалів можна скоротити час розробки.

Інтеграція гаманців

Bitcoin гаманці, що підтримують Ordinals:

  • Unisat Wallet — найпопулярніший, browser extension, підтримує PSBT signing.
  • Xverse — мобільний + extension, підтримує BRC-20 і Ordinals.
  • Leather (hiro.so) — стек від Hiro Systems, хороша документація.
  • OKX Wallet — найбільший за кількістю користувачів в Азії.

Стандарт взаємодії з гаманцем: Unisat провайдер API (де-факто стандарт для Ordinals). Аналог window.ethereum, але window.unisat. Методи: requestAccounts(), signPsbt(), pushPsbt().

const accounts = await window.unisat.requestAccounts()
const signedPsbt = await window.unisat.signPsbt(psbtHex, {
  autoFinalized: false,
  toSignInputs: [{ index: 0, address: sellerAddress }]
})

Для multi-wallet підтримки — sats-connect бібліотека, аналог WalletConnect для Bitcoin. Ми забезпечуємо unisat wallet інтеграцію та підтримку інших популярних гаманців.

Типові проблеми реалізації

Розкрити список типових проблем
  • UTXO splitting. Якщо Ordinal знаходиться в UTXO разом з dust BTC (наприклад, 546 satoshi + Ordinal), при spend потрібно правильно розділити outputs, щоб Ordinal пішов на потрібну адресу, а пил — на іншу. Помилка в split = Ordinal знищений (відправлений як fee майнеру).
  • Mempool congestion. При високому навантаженні мережа Bitcoin fee за транзакцію може різко зростати. Лістинг із заниженим fee може чекати включення в блок годинами — Ordinal «зависає». Потрібна логіка RBF (Replace-By-Fee) для прискорення транзакцій.
  • Fake inscription. Верифікація, що inscription реальна, а не підроблена копія — через перевірку sat number в офіційному індексаторі. Сат з inscription ID повинен збігатися з записом в ord індексаторі.

Що входить в роботу

  • Розгорнута документація: схема PSBT-транзакцій, опис індексатора, OAuth-схеми гаманців.
  • Вихідний код на GitHub з CI/CD та тестами (покриття 90%+).
  • Доступ до адмін-панелі з моніторингом транзакцій.
  • Інструкція з розгортання на власні сервери.
  • Консультаційна підтримка на 30 днів після запуску.

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

Інфраструктура (1 тиждень). Bitcoin full node + ord індексатор, синхронізація blockchain, база даних лістингів.

Backend API (2 тижні). REST API: колекції, лістинги, search, активність. PSBT сервіс для генерації та валідації угод. WebSocket для realtime оновлень.

Frontend (2-3 тижні). Next.js + TypeScript, multi-wallet support (Unisat, Xverse, Leather), галерея інскрипцій, trading interface, BRC-20 баланси.

Тестування (1 тиждень). Testnet (signet) + regtest середовище, тестування PSBT угод від початку до кінця.

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

MVP маркетплейс для Ordinals з базовим лістингом та PSBT-угодами — від 4 до 6 тижнів. Повний маркетплейс з BRC-20, Runes, індексатором та multi-wallet — 2-3 місяці. Вартість розраховується після обговорення набору підтримуваних протоколів та вимог до індексатора. Наш досвід у блокчейн-розробці перевищує 7 років, ми реалізували більше 70 проектів, включаючи створення NFT платформ на різних мережах. Гарантуємо прозорість вихідного коду та підтримку після запуску. Зв'яжіться з нами, щоб замовити маркетплейс біткоін під ключ. Отримайте консультацію з архітектури та оцінку термінів.

Чому розробка 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-колекцій.

Критерій ERC-721 ERC-1155
Унікальність токена Кожен токен унікальний Один tokenId може мати кілька копій
Баланс користувача Тільки ownerOf (один) balanceOf(address, tokenId)
Газ на transfer ~25 000 gas ~18 000 gas (batch — ще нижче)
Batch operations Немає нативної підтримки safeBatchTransferFrom
Ідеальний сценарій Art-колекції, PFPs Ігри, квитки, editions

Конкретний кейс: ігровий проект з 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 limitingrequire(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 днів технічної підтримки після деплою

Строки

Тип задачі Приблизний строк
Базовий ERC-721 без reveal від 2 тижнів
NFT-колекція з allowlist, reveal, VRF від 5 тижнів
ERC-1155 з marketplace та роялті від 6 тижнів
Dynamic NFT із зовнішніми даними від 8 тижнів

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