Ви запускаєте колекцію з 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 схема:
- Commit — P2TR output з tapscript, що містить дані.
- 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 хвилин.
Приклад архітектури
Backend — Node.js, @scure/btc-signer для збірки транзакцій. Своя Bitcoin Core нода з txindex=1 для незалежності.
| Компонент | Технологія |
|---|---|
| Transaction builder | bitcoinjs-lib v6 / @scure/btc-signer |
| UTXO management | PostgreSQL (tracked UTXOs) |
| Bitcoin node | Bitcoin Core RPC |
| Fee estimation | mempool.space API (real-time sat/vbyte) |
| Job queue | BullMQ (commit/reveal pipeline) |
| Payment processing | BIP-21 URI + on-chain detection |
Fee priority
| Priority | Multiplier | Приклад очікування |
|---|---|---|
| Economy | 1.0× | 3–6 блоків |
| Standard | 1.5× | 1–2 блоки |
| Fast | 2.0× | наступний блок |
Користувацький інтерфейс
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–2 дні). Цільова аудиторія, підтримка BRC-20 або plain Ordinals, обсяг навантаження.
- Розробка (1–2 тижні). Transaction builder + job queue + payment detection + frontend.
- Тестування. Повний цикл на testnet.
- Деплой. Docker-контейнери, Bitcoin Core нода (~600 ГБ SSD), моніторинг pending jobs.
Терміни: базовий сервіс одиничних інскрипцій — 1–1,5 тижня. Bulk minting з dashboard та API — 2–3 тижні. Вартість розраховується після аналізу вимог.
Отримайте демо архітектури під ваші завдання. Оцініть можливості сервісу — зв'яжіться для консультації. Замовте аудит вашого проєкту або прототип архітектури.