Ordinals and BRC-20 marketplace development

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1 servicesAll 1306 services
Ordinals and BRC-20 marketplace development
Complex
from 2 weeks to 3 months
FAQ
Blockchain Development Services
Blockchain Development Stages
Latest works
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1161
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1051
  • image_logo-advance_0.png
    B2B Advance company logo design
    561
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    827
  • image_logo-aider_0.jpg
    AIDER company logo development
    762
  • image_crm_chasseurs_493_0.webp
    CRM development for Chasseurs
    850

Ordinals/BRC-20 Marketplace Development

Bitcoin Ordinals appeared in early 2023 and shattered the established notion of Bitcoin as "just money." In the first year, Ordinals trading volume exceeded $1.5 billion, the Bitcoin network experienced several overload episodes due to inscription transactions. Magic Eden, Ordinals Wallet, Gamma.io — marketplaces came quickly. But the development stack is fundamentally different from EVM: no smart contracts, no native escrow, deals are atomic through PSBT mechanics.

Protocols: Ordinals, BRC-20, and Runes

Ordinals — Inscriptions in Bitcoin

Ordinals protocol (Casey Rodarmor, 2023) introduces the concept of ordinal numbers for satoshis. Each satoshi is numbered in mining order. Inscription attaches data to a specific satoshi through Bitcoin Script witness data. Data is stored on-chain in Bitcoin — this distinguishes Ordinals from Ethereum NFTs where metadata is typically in IPFS.

Technically: inscription is created through commit-reveal transaction. Commit transaction creates a P2TR output with Tapscript containing data. Reveal transaction spends this output, publishing data in witness. After that, this satoshi carries the inscription and can be transferred as NFT.

For marketplace critical: parsing inscription metadata (JSON, image/png, image/webp, text/plain), determining Ordinal sat range in UTXO, tracking ownership through Bitcoin addresses.

BRC-20 — Tokens on Top of Ordinals

BRC-20 (March 2023, @domodata) — experimental token standard based on Ordinals. Operations are encoded in JSON inscriptions:

{ "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" }

Important to understand: BRC-20 balances aren't stored on address like ERC-20. Balance is the sum of unspent transfer inscriptions attached to an address. For trading on marketplace you need an indexer — a service that reads all Bitcoin history and builds current balances for each address.

Runes — Next Generation

Runes protocol (April 2024, Casey Rodarmor) — more efficient BRC-20 alternative. Use OP_RETURN output instead of witness data, which is cheaper. Balances stored in UTXO model, closer to native Bitcoin. Runes already supported by several marketplaces, but ecosystem younger than BRC-20.

Atomic Deals Through PSBT

Key difference from EVM marketplaces: no smart contract as escrow. Bitcoin doesn't support arbitrary code. Deals are made through PSBT (Partially Signed Bitcoin Transaction).

Listing and purchase scheme:

  1. Seller creates PSBT: Input — UTXO with Ordinal, Output — seller address + requested price in BTC. Seller signs only their input (SIGHASH_SINGLE | SIGHASH_ANYONECANPAY).
  2. PSBT published to marketplace. Marketplace stores this as listing.
  3. Buyer completes PSBT: adds their inputs (BTC for payment) and output for their address (receiving Ordinal). Signs with their keys.
  4. Transaction broadcast: atomic — either seller gets BTC and buyer gets Ordinal, or nothing.

SIGHASH_ANYONECANPAY allows seller to sign partial transaction, which anyone can add inputs to. This provides atomicity without smart contract.

Implementation uses libraries: bitcoinjs-lib (JavaScript), rust-bitcoin (Rust). PSBT construction and validation — critical part, error here = loss of NFT or BTC.

Indexer Architecture

Indexer — most complex component. It must:

  1. Read entire Bitcoin blockchain from genesis (or from Ordinals block ~767430)
  2. Parse all inscription transactions, build mapping satoshi → inscription data
  3. Track ownership: which Bitcoin address is associated with each Ordinal right now
  4. For BRC-20: parse JSON operations, calculate balances per address
  5. Stay synchronized with new blocks in real-time

Open solutions:

  • ord (Casey Rodarmor's original indexer, Rust) — reference implementation
  • hiro-systems/ordhook — more performant, supports webhooks
  • unisat/ord-utils — JavaScript library on top of ord indexer

For marketplace from scratch: run ord node + Bitcoin full node, build custom API on top with caching in PostgreSQL or Redis. Full synchronization takes several days.

Wallet Integration

Bitcoin wallets supporting Ordinals:

  • Unisat Wallet — most popular, browser extension, supports PSBT signing
  • Xverse — mobile + extension, supports BRC-20 and Ordinals
  • Leather (hiro.so) — Hiro Systems stack, good documentation
  • OKX Wallet — largest by user count in Asia

Standard wallet interaction: Unisat provider API (de facto standard for Ordinals). Like window.ethereum, but window.unisat. Methods: requestAccounts(), signPsbt(), pushPsbt().

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

For multi-wallet support — sats-connect library, analogue to WalletConnect for Bitcoin.

Typical Implementation Problems

UTXO splitting. If Ordinal is in UTXO with dust BTC (e.g., 546 satoshi + Ordinal), spending requires properly splitting outputs so Ordinal goes to right address and dust to another. Error in split = Ordinal destroyed (sent as fee to miner).

Mempool congestion. Under high Bitcoin network load, transaction fee spikes dramatically. Listing with underestimated fee may wait for block inclusion for hours — Ordinal "hangs". Need RBF (Replace-By-Fee) logic to accelerate transactions.

Fake inscription. Verification that inscription is real, not fake copy — through checking sat number in official indexer. Sat with inscription ID must match ord indexer record.

Development Process

Infrastructure (1 week). Bitcoin full node + ord indexer, blockchain synchronization, listing database.

Backend API (2 weeks). REST API: collections, listings, search, activity. PSBT service for deal generation and validation. WebSocket for real-time updates.

Frontend (2–3 weeks). Next.js + TypeScript, multi-wallet support (Unisat, Xverse, Leather), inscription gallery, trading interface, BRC-20 balances.

Testing (1 week). Testnet (signet) + regtest environment, end-to-end PSBT deal testing.

Timeline Estimates

MVP marketplace for Ordinals with basic listing and PSBT deals — 4–6 weeks. Full marketplace with BRC-20, Runes, indexer and multi-wallet — 2–3 months.

Cost calculated after discussing supported protocols and indexer requirements.