Вы запускаете коллекцию из 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 недели. Стоимость рассчитывается после анализа требований.
Получите демо архитектуры под ваши задачи. Оцените возможности сервиса — свяжитесь для консультации. Закажите аудит вашего проекта или прототип архитектуры.