Ordinals/BRC-20 Marketplace Development
When Bitcoin Ordinals burst onto the scene, developers faced the challenge of trading assets without smart contracts. We solved it through atomic PSBT swaps. Initially, the trading volume of Ordinals exceeded $1.5 billion, and the Bitcoin network was several times congested due to inscription transactions. Magic Eden, Ordinals Wallet, Gamma.io — marketplaces arrived quickly, but the development stack is fundamentally different compared to EVM: no smart contracts, no native escrow, transactions are atomic via PSBT mechanics. If you need a Bitcoin NFT marketplace, contact us for a consultation.
Protocols: Ordinals, BRC-20, and Runes
Ordinals — Inscriptions on Bitcoin
The Ordinals protocol introduces the concept of ordinal numbers for satoshis. Each satoshi is numbered in mining order. An inscription attaches data to a specific satoshi through Bitcoin Script witness data. The data is stored on-chain in Bitcoin — this distinguishes Ordinals from NFTs on Ethereum, where metadata is typically on IPFS.
Technically: an inscription is created via a commit-reveal transaction. The commit transaction creates a P2TR output with Tapscript containing the data. The reveal transaction spends this output, publishing the data in the witness. After that, this satoshi carries the inscription and can be transferred like an NFT.
For a marketplace, critical aspects include: parsing inscription metadata (JSON, image/png, image/webp, text/plain), determining the Ordinal sat range in a UTXO, and tracking ownership through Bitcoin addresses.
BRC-20 — Tokens on Top of Ordinals
BRC-20 is an 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" } It's important to understand: BRC-20 balances are not stored on an address like ERC-20. A balance is the sum of unspent transfer inscriptions associated with an address. For trading on a marketplace, an indexer — a service that reads the entire Bitcoin history and builds current balances for each address — is required. When developing a BRC-20 marketplace, the indexer is key.
Runes — The Next Generation
The Runes protocol is a more efficient alternative to BRC-20. It uses OP_RETURN output instead of witness data, which is cheaper. Balances are stored in the UTXO model, closer to native Bitcoin. Runes already have several marketplaces, but the ecosystem is younger than BRC-20. If you are considering a Runes marketplace, we can also offer integration of this protocol.
Protocol Comparison
| Protocol | Data Type | Mechanism | Advantage | Disadvantage |
|---|---|---|---|---|
| Ordinals | NFT (arbitrary data) | Witness data | Fully on-chain | High transaction weight |
| BRC-20 | Tokens (JSON operations) | Witness data | Decentralized | Requires heavy indexer |
| Runes | Tokens (UTXO model) | OP_RETURN | Low fees | Less liquidity |
How Atomic Swaps Work Without Smart Contracts?
The main difference from EVM marketplaces: there is no smart contract as escrow. Bitcoin does not support arbitrary code. Swaps are done via PSBT (Partially Signed Bitcoin Transaction). Learn more about PSBT in Wikipedia.
Listing and purchase scheme:
- Seller creates PSBT: Input — UTXO with Ordinal, Output — seller's address + requested price in BTC. Seller only signs their input with the
SIGHASH_SINGLE | SIGHASH_ANYONECANPAYflag. - PSBT is published to the marketplace. The marketplace stores this as a listing.
- Buyer supplements the PSBT: adds their inputs (BTC for payment) and an output to their address (receiving the Ordinal). Signs with their keys.
- Transaction broadcast: atomic — either seller gets BTC and buyer gets the Ordinal, or nothing.
SIGHASH_ANYONECANPAY allows the seller to sign a partial transaction that anyone can add inputs to. This is atomicity without a smart contract. This mechanism underlies the atomic Bitcoin swap.
Implementation uses libraries: bitcoinjs-lib (JavaScript), rust-bitcoin (Rust). PSBT construction and validation are critical; an error here means loss of NFT or BTC.
Why Is the Indexer Critical for Liquidity?
The indexer is the most complex component. It must:
- Read the entire Bitcoin blockchain from genesis (or from the block of Ordinals appearance).
- Parse all inscription transactions, build a mapping satoshi → inscription data.
- Track ownership: which Bitcoin address is associated with each Ordinal right now.
- For BRC-20: parse JSON operations, calculate balances for addresses.
- Stay synchronized with new blocks in real-time (latency no more than 10 seconds).
Open-source solutions:
- ord (original indexer by Casey Rodarmor, Rust) — reference implementation.
- hiro-systems/ordhook — more performant, supports webhooks.
- unisat/ord-utils — JavaScript library on top of the ord indexer.
For a marketplace from scratch: we run an ord node + Bitcoin full node, and build our own API with caching in PostgreSQL or Redis. Synchronization from zero takes up to 5 days.
| Indexer Type | Sync Speed | BRC-20 Support | Commercial License |
|---|---|---|---|
| ord (reference) | 5–7 days | Yes | MIT |
| ordhook | 2–3 days | No (Ordinals only) | Apache 2.0 |
| Unisat API | Instant (remote) | Yes | Vendor key |
Using a ready-made ordinal indexer reduces development time.
Wallet Integration
Bitcoin wallets supporting Ordinals:
- Unisat Wallet — the most popular, browser extension, supports PSBT signing.
- Xverse — mobile + extension, supports BRC-20 and Ordinals.
- Leather (hiro.so) — stack from Hiro Systems, good documentation.
- OKX Wallet — largest by user count in Asia.
Standard for wallet interaction: Unisat provider API (de facto standard for Ordinals). Analogous to 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, analogous to WalletConnect for Bitcoin. We provide Unisat wallet integration and support for other popular wallets.
Typical Implementation Problems
Expand the list of typical problems
- UTXO splitting. If the Ordinal is in a UTXO together with dust BTC (e.g., 546 satoshi + Ordinal), when spending you need to correctly split outputs so the Ordinal goes to the right address and the dust to another. A split error = the Ordinal is destroyed (sent as fee to miner).
- Mempool congestion. Under high load, Bitcoin network fees can spike. A listing with a low fee can wait hours for inclusion — the Ordinal is "stuck". RBF (Replace-By-Fee) logic is needed to accelerate transactions.
- Fake inscription. Verifying that an inscription is real and not a counterfeit copy — by checking the sat number in the official indexer. The sat with the inscription ID must match the record in the ord indexer.
What's Included in the Work
- Detailed documentation: PSBT transaction scheme, indexer description, wallet OAuth schemes.
- Source code on GitHub with CI/CD and tests (90%+ coverage).
- Access to admin panel with transaction monitoring.
- Deployment instructions for your own servers.
- Consulting support for 30 days after launch.
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 generating and validating swaps. 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 testing of PSBT swaps.
Timeline Estimates
MVP marketplace for Ordinals with basic listing and PSBT swaps — from 4 to 6 weeks. Full marketplace with BRC-20, Runes, indexer, and multi-wallet — 2–3 months. The cost is determined after discussing the set of supported protocols and indexer requirements. Our blockchain development experience exceeds 7 years, and we have delivered over 70 projects, including NFT platforms on various networks. We guarantee source code transparency and post-launch support. Contact us to order a turnkey Bitcoin marketplace and get a consultation on architecture and timeline estimates.