Розробка сервісу мінтингу Ordinals під ключ

Ви запускаєте колекцію з 10 000 Bitcoin NFT і стикаєтесь із тим, що стандартні Ethereum-інструменти не працюють? Ordinals потребують глибокого розуміння UTXO-моделі та ручного управління транзакціями. Ми розробляємо сервіси для масового мінтингу Ordinals на Bitcoin: від batch-інскрипцій до повноцінного API. Понад 5 років роботи з Bitcoin-інфраструктурою та 10+ проєктів з інскрипціями — гарантія стабільності під навантаженням. Замовте консультацію, щоб обговорити архітектуру під ваше завдання.

В основі сервісу — протокол Ordinals, що дозволяє вписувати довільні дані в witness-секцію транзакції. Кожен сатоші нумерується в порядку майнінгу, дані упаковуються через OP_FALSE OP_IF <data> OP_ENDIF. Це не смарт-контракти — data on-chain безпосередньо в Bitcoin. Розробка mass-minting потребує розуміння UTXO-моделі, яка принципово відрізняється від Ethereum account model. На відміну від ERC-721, де мінтинг — виклик контракту, Ordinals потребує фізичного управління UTXO та розрахунку комісій. Solana NFT minting обробляє 10 000 транзакцій за секунду, Ordinals же потребує очікування 1–2 блоків, що робить масовий мінтинг у десятки разів повільнішим, але забезпечує безпеку L1. Batch-інскрипції Bitcoin через один reveal знижують комісію в 2–3 рази — при тиражі в 10 000 інскрипцій економія становить близько 0.2 BTC. Це повністю керований inscription service з API для масового мінтингу, а наш Ordinals API надає endpoints для batch-завантаження. Сервіс під ключ включає повну підтримку Bitcoin Core та управління mempool fee. Всі інскрипції використовують Taproot з P2TR.

Як працює UTXO модель в Ordinals?

В Ethereum — address → balance. В Bitcoin — набір UTXO, кожен потрібно явно використовувати як input. Інскрипція прив'язана до конкретного UTXO (до першого satoshi — «cardinal» sat).

Перша помилка при mass minting: UTXO consolidation без урахування інскрипцій. Стандартний Bitcoin гаманець об'єднує дрібні UTXO для оптимізації комісій — якщо consolidation захоплює UTXO з інскрипцією, вона втрачається. Ordinals wallet зобов'язаний розрізняти cardinal UTXO та plain UTXO. Для batch-завантаження ми використовуємо власне UTXO управління з PostgreSQL.

Dust limit обов'язковий: output reveal транзакції має бути >= 546 satoshi (P2WPKH) або 330 satoshi (P2TR). При batch-мінтингу кожен inscribed output = 546–1000 satoshi. На 1000 інскрипцій тільки на dust витрачається мінімум 0.000546 BTC. Для масштабування застосовуємо чергу BullMQ — кожне завдання проходить через стани: PENDING_COMMIT, COMMITTED, PENDING_REVEAL, INSCRIBED.

Commit-reveal схема:

1. Commit — P2TR output з tapscript, що містить дані.
2. Reveal — витрачає commit, розкриває tapscript.

Після commit (мінімум 1 блок) публікується reveal. При blocktime ~10 хвилин та congested mempool процес розтягується на години. Потрібна черга зі станами.

Які складнощі виникають при batch-мінтингу?

Fee calculation

Bitcoin fee = fee_rate (sat/vByte) × transaction_size (vBytes). Інскрипція 100 КБ в witness дає ~25 000 vBytes. При fee rate 50 sat/vByte одна інскрипція може коштувати до 0.01 BTC тільки за комісію.

Сервіс зобов'язаний:

• Отримувати актуальний fee rate з mempool.space.
• Розраховувати точний розмір транзакції до збірки.
• Показувати користувачеві total cost = inscription fee + miner fee + service fee.
• Пропонувати feeRate multiplier: 1.0x economy, 1.5x standard, 2.0x fast.

Batch-стратегія

Один reveal може містити кілька інскрипцій через concatenation в tapscript. Це знижує overhead, але якщо reveal застряє — всі інскрипції чекають. Для комерційного сервісу ми рекомендуємо окремі транзакції з незалежним статусом.

Для production використовуємо PostgreSQL для трекінгу UTXO, окремо позначаючи cardinal та plain output. Кожен commit UTXO відстежується до підтвердження reveal. Reconciliation-процес перевіряє статус по блокчейну кожні 30 хвилин.

Користувацький інтерфейс

Drag-and-drop файлів (WebP, PNG, GIF, MP4, HTML). Попередній перегляд та розрахунок fee до оплати. BTC-адреса з QR. Real-time статус через WebSocket: detecting payment → commit sent → commit confirmed → reveal sent → inscribed. Посилання на ordinals.com або ord.io.

Як забезпечується безпека при масовому мінтингу?

• RBF — чекаємо мінімум 1 підтвердження оплати перед commit.
• Orphaned commits — рідкісні, але потрібен reconciliation.
• Content filtering — hash-based блеклист нелегального контенту на етапі завантаження.

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

• Аналіз вимог та проектування архітектури
• Розробка Bitcoin transaction builder з підтримкою batch
• Інтеграція payment detection (BIP-21, on-chain)
• UI для завантаження, статусу та історії
• Тестування на Testnet4 (повний end-to-end pipeline)
• Деплой на VPS з Bitcoin Core, моніторинг
• Документація API та інструкція для користувачів
• Підтримка протягом 1 місяця після запуску

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

1. Аналітика (1–2 дні). Цільова аудиторія, підтримка BRC-20 або plain Ordinals, обсяг навантаження.
2. Розробка (1–2 тижні). Transaction builder + job queue + payment detection + frontend.
3. Тестування. Повний цикл на testnet.
4. Деплой. Docker-контейнери, Bitcoin Core нода (~600 ГБ SSD), моніторинг pending jobs.

Терміни: базовий сервіс одиничних інскрипцій — 1–1,5 тижня. Bulk minting з dashboard та API — 2–3 тижні. Вартість розраховується після аналізу вимог.

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

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