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

Разработка маркетплейса 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. Если рассматривать маркетплейс рунов, мы также можем предложить интеграцию этого протокола.

Сравнение протоколов

Как работают атомарные сделки без смарт-контрактов?

Главное отличие от 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 дней.

При использовании готового индексатора ординалов можно сократить время разработки.

Интеграция кошельков

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 интеграцию и поддержку других популярных кошельков.

Типичные проблемы реализации

Что входит в работу

• Развёрнутая документация: схема 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 в первый блок, до сломанных royalties на вторичном рынке. Типовой запрос: «Сделайте коллекцию как у других за неделю», а через месяц выясняется, что газ вырос втрое из-за неоптимизированного 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 обеспечивают pinning. Важно: 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 стандарт royalties. Контракт возвращает (recipient, amount) для любой sale price через royaltyInfo(tokenId, salePrice). Маркетплейсы опрашивают это при каждой продаже. Проблема: соблюдение royalties — добровольное решение маркетплейса. Blur запустился с нулевыми royalties, что вызвало волну других платформ. Сейчас ситуация частично стабилизировалась: OpenSea поддерживает ERC-2981, Blur добавил опциональные.

Попытки enforce royalties on-chain через ограничение transfers только на approved маркетплейсы (operator filtering) OpenSea предлагал через OperatorFilterRegistry. Это ломает composability — нельзя передать NFT через кастомный контракт. Большинство серьёзных проектов отказались от этого подхода. Для проектов, где royalties критичны, мы строим кастомный маркетплейс внутри экосистемы + 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, pinning на минимум двух сервисах
4. Reveal — если используется Chainlink VRF, тест на testnet обязателен: VRF subscription должен быть funded LINK токенами
5. Маркетплейс-интеграция — верификация коллекции на OpenSea, настройка royalties, тест MetadataUpdate events
6. Деплой и мониторинг — Tenderly для отлова reentrancy, Etherscan API для верификации контракта, настройка оповещений по событиям

Что входит в работу (deliverables)

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

Сроки

Стоимость рассчитывается индивидуально после аудита вашей задачи. Пришлите brief с описанием проекта — оценим прозрачно в течение 3 рабочих дней. Для постоянных клиентов действует гибкая система скидок на пакетные заказы. Свяжитесь с нами для детального обсуждения вашего NFT-проекта. Получите консультацию по архитектуре маркетплейса — оставьте заявку, и мы оценим проект за три дня.