Bitcoin Ordinals NFT inscriptions development

Bitcoin Ordinals NFT Inscriptions Development

The Ordinals protocol appeared in January 2023 and changed the perception of Bitcoin as a "boring" asset without smart contracts. Each satoshi has a unique ordinal number, and arbitrary data can be attached to it — an image, HTML, JavaScript, even a working 3D engine. This is an inscription. No smart contracts, no second layer — data is stored directly in Bitcoin witness (SegWit v1, Taproot).

Developing an Ordinals collection differs fundamentally from EVM development: no Solidity, no ABI, no events. There's a UTXO model, witness size limits, and the specifics of working with Bitcoin transaction builders.

How the Ordinals Protocol Works

Satoshi Numbering

The Ordinals protocol (Casey Rodarmor, BIP-300) introduces deterministic numbering: the first satoshi of the first block gets number 0, the last satoshi of the last block in the halving epoch gets the maximum number. The numbering is stable and independently verifiable.

Satoshi "rarity" is determined by its position: a satoshi from the first block of each halving epoch is "legendary," from the first block of each difficulty adjustment is "rare," etc. Trading rare sats is a separate market within the Ordinals ecosystem.

Inscription as Envelope in Tapscript

An inscription is created through Tapscript in a SegWit v1 transaction. Data is packed in an OP_FALSE OP_IF ... OP_ENDIF envelope, which Bitcoin nodes ignore during execution but store in the witness. Content type is specified with an ord tag plus MIME type:

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_1
  OP_PUSH "image/png"
  OP_0
  OP_PUSH <image_data_chunk_1>
  OP_PUSH <image_data_chunk_2>
  ...
OP_ENDIF

The limit for one inscription is 520 bytes per push operation, but there can be many pushes. Practical limit is the witness data size in a block (about 4MB with witness discount). Images 400KB+ fit without problems.

Sat-to-Inscription Binding

An inscription is tied to the first satoshi of the first output in the commit (precisely, reveal) transaction. When this UTXO is transferred — the inscription goes to the new owner. Marketplaces (Magic Eden Bitcoin, Gamma.io, Unisat) track UTXO movement and show the new owner.

This differs fundamentally from EVM: there's no ownerOf call, no revert on unauthorized transfer. Ownership is determined through Bitcoin's UTXO model — whoever has the UTXO with this sat is the owner.

Recursive Inscriptions

Technically the most interesting part: an inscription can reference another inscription via a special path /content/{inscription_id}. A browser (Ordinals explorer or marketplace) resolves these references and renders the composite.

Application: a 10,000-element collection where each trait (background, head, body) is a separate inscription of 2–5KB. The final image is an HTML inscription that references trait inscriptions and assembles them through <img> tags or canvas. Instead of 10K × 50KB images — 20 trait inscriptions × 3KB + 10K × 1KB HTML. Fee savings are substantial.

Recursion invariant: referenced inscriptions must exist before the referencing inscription is created. You can't create an HTML inscription referencing trait inscriptions that don't exist yet.

Development Tools

ord CLI

Official tool by Casey Rodarmor. Requires a full Bitcoin node (Bitcoin Core) or can be used via RPC with --bitcoin-rpc-url. Main commands:

# Creating an inscription from a file
ord wallet inscribe --fee-rate 15 --file image.png

# Getting information about an inscription
ord index info --inscription <inscription_id>

For production batch inscribing — custom scripts via bitcoinlib (Python) or bitcoin-ts (TypeScript) with direct work on PSBT (Partially Signed Bitcoin Transactions).

Working with PSBT for Collections

Batch minting 10K inscriptions via CLI is slow and unreliable. Use a programmatic approach:

1. Generate trait inscriptions in batches of 100
2. For each pair (commit tx, reveal tx) build a PSBT
3. Sign via HD wallet (BIP-32 derivation)
4. Broadcast through Bitcoin RPC or Mempool API

Fee rate management is critical: during congestion, mempool fee per byte can increase 10–20x. The script should check current fee market via mempool.space/api/v1/fees/recommended and select the optimal level.

Collection Verifier

Analogue to rarity checker for EVM: a script that retrieves metadata by inscription ID (via Ordinals explorer API or own node), parses traits from JSON inscription, builds a rarity table. Published as open source — users can verify rarity independently.

Ethereum vs. Bitcoin Ordinals

The lack of royalties at protocol level is a key disadvantage for team monetization. Marketplaces (Magic Eden Bitcoin) implement "soft royalties" through UI, but technical enforcement is absent.

Development Process

Content Preparation (project-dependent). For recursive collections: generate trait inscriptions, check HTML template correctness, test rendering in Ordinals explorer.

Testnet Deploy (1–2 days). Bitcoin signet or testnet to verify the entire pipeline. Ordinals works on testnet — you can fully test minting and display.

Batch Inscribing (depends on size). 10K inscriptions at 15 sat/vbyte fee rate — approximately 1–2 BTC in fees for medium-sized images. For recursive — significantly less.

Marketplace Listing. Magic Eden Bitcoin, Gamma.io — collection verification via form or API.

Timeline Estimates

Simple collection without recursion (static images) — 3–5 days including tools. Recursive collection with HTML generator — 1–1.5 weeks. Bitcoin fee costs for minting are discussed separately — depends on current fee market.