How Bitcoin Ordinals Actually Work: Satoshi Indexing, Inscription Mechanics, and the Trade-offs Most Guides Ignore

The single most misunderstood aspect of Ordinals: Bitcoin Core knows nothing about them. Ordinal theory is an off-chain indexing convention proposed by Casey Rodarmor in January 2023 (the ord client, BIP pending) that assigns a serial number to every satoshi based on the order it was mined. The Bitcoin protocol does not enforce, validate, or even acknowledge these serial numbers. Consensus nodes treat all satoshis in a UTXO as fungible.

This means ordinal identity exists only insofar as indexers agree on it. If two indexers disagree on satoshi tracking across a complex transaction graph, there is no on-chain arbitrator. The ord reference client is the de facto canonical indexer, but its rules have changed — notably with the introduction of cursed inscriptions (negative inscription numbers assigned retroactively to inscriptions the original indexer skipped). Ordinal "ownership" is as strong as the indexing consensus, and no stronger.

Ordinal numbers are assigned sequentially to each satoshi as it enters circulation via the coinbase transaction of each block. The first satoshi of the genesis block is ordinal 0; the last satoshi ever mined will be ordinal 2,099,999,997,689,999.

Tracking individual satoshis through spends relies on a strict first-in-first-out (FIFO) rule applied to transaction inputs and outputs:

• ›Inputs are ordered as they appear in the transaction. Each input's satoshis are concatenated in sequence.
• ›Outputs are filled in order. The first output absorbs the first N satoshis (where N equals the output's value), the second output absorbs the next batch, and so on.
• ›Any satoshis not accounted for by outputs are assigned to the miner as fees — they flow into the coinbase transaction of the block, ordered after the block subsidy sats.
• ›Coinbase input ordering: subsidy sats come first (with fresh ordinal numbers), then fee sats in the order of their originating transactions within the block.

This deterministic mapping means any observer running the same FIFO logic over the full blockchain will arrive at the same assignment. But the computational cost is non-trivial: the ord indexer must track satoshi flow through every transaction in every block. A full reindex from genesis currently takes multiple days on commodity hardware and requires hundreds of gigabytes of index data beyond the raw blockchain.

Rarity and Naming

Rodarmor defined rarity tiers based on Bitcoin's periodic events: common (any sat), uncommon (first sat of a block), rare (first sat of a difficulty adjustment period), epic (first sat of a halving epoch), legendary (first sat of a conjunction of halving and difficulty adjustment — occurs roughly every 24 years), and mythic (the first sat of the genesis block, ordinal 0). These labels are purely conventional — the ord client enforces them, but nothing in Bitcoin script does.

Inscriptions embed arbitrary data into Bitcoin transactions by placing content inside the witness field of a Taproot (SegWit v1) spend. The mechanism uses a two-phase commit-reveal pattern:

• ›Commit transaction: Creates a Taproot output whose script tree includes a leaf containing the inscription data. No data is revealed on-chain yet — only a commitment to the Taproot output key.
• ›Reveal transaction: Spends the commit output via the script path, exposing the inscription content in the witness. The data sits inside an OP_FALSE OP_IF … OP_ENDIF envelope, which means it is never actually executed by Script. Nodes parse and relay it, but it has zero effect on validation logic.

The envelope structure uses specific tag bytes: the content type is pushed after a tag of 0x01 as a MIME string, and the body follows tag 0x00 in one or more data pushes (each ≤520 bytes, the script push limit). Multiple pushes are concatenated by the indexer.

Why witness? Because SegWit's witness discount means witness bytes cost 1 weight unit instead of 4. A 400 KB inscription costs roughly the same in fees as a 100 KB legacy transaction payload. The practical ceiling is the 4 MB block weight limit minus the overhead of the transaction itself — the largest possible single inscription is just under 4 MB, though real-world relay policies (standardness rules capping witness size at ~400 KB in default Bitcoin Core config) constrain what propagates through the mempool without direct miner coordination.

An inscription is bound to a specific satoshi — by default, the first satoshi of the first output of the reveal transaction. Transferring the inscription means transferring the UTXO containing that satoshi. Here's where it gets dangerous:

• ›Standard Bitcoin wallets are inscription-unaware. They select UTXOs for coin selection without regard to ordinal content. Sending Bitcoin from a wallet holding inscribed UTXOs can inadvertently send the inscription to an unintended recipient, or worse, assign it to miner fees.
• ›Partial spends of a UTXO containing an inscribed satoshi will, under FIFO rules, route that satoshi to whichever output absorbs the corresponding position. If the wallet splits the UTXO, the inscription lands wherever FIFO dictates — which may be a change output the user controls, or may not.
• ›Ordinal-aware wallets (Sparrow with frozen UTXOs, Xverse, the ord wallet) mitigate this by freezing inscribed UTXOs and constructing transactions that preserve satoshi positioning. But there is no protocol-level safety net.

The practical implication: inscriptions have been burned to fees many times. Once a satoshi enters a miner's coinbase output, recovery depends on miner cooperation.

The ord indexer originally tracked only inscriptions following a narrow set of rules: single inscription per transaction input, specific envelope formatting, Taproot spends only. Transactions that violated these expectations but still contained valid-looking envelope data were ignored.

In mid-2023, the concept of cursed inscriptions was introduced (sometimes called "negative-number inscriptions") to retroactively index previously skipped inscriptions. These include:

• ›Multiple inscriptions in a single input (batch inscriptions before the feature was officially supported)
• ›Inscriptions in non-Taproot witness fields (SegWit v0)
• ›Inscriptions with unrecognized or duplicate tags
• ›Inscriptions in inputs beyond the first

This retroactive reindexing created numbering instability — inscription numbers assigned before the cursed inscription update could shift depending on the indexer version. The community eventually adopted inscription IDs (the reveal transaction ID plus the input index, e.g., txid:i0) as the stable identifier, with ordinal numbers treated as a convenience label.

• ›Indexer divergence: If the ord reference client changes its FIFO interpretation or inscription parsing rules, the entire numbering scheme can shift. There is no on-chain anchor. Alternative indexers (e.g., Hiro's ordinals API, ord-rs) must exactly replicate ord's logic or produce incompatible state.
• ›Mempool sniping: Since the commit transaction reveals nothing about the inscription content, a commit can be sniped only if someone identifies the pattern. However, the reveal transaction, once broadcast, can theoretically be front-run by a miner who replaces it with their own spend of the commit output — though this requires the miner to control the block and have visibility into the reveal before mining.
• ›Dust limit interaction: Inscribed satoshis sit in UTXOs that often carry the minimum relay value (546 sats for P2TR by default policy). If fee rates spike, these UTXOs may become economically unspendable — the cost to move the inscription exceeds the UTXO's value. The inscription is not lost, but it is effectively frozen until fees drop.
• ›Pruned nodes: Pruned Bitcoin nodes discard old witness data. Since inscription content lives entirely in the witness, a pruned node cannot serve historical inscription data. Full archival nodes or dedicated indexers are required for content retrieval.
• ›Standardness vs. consensus: Bitcoin Core's relay policy limits witness stack element sizes and total transaction weight more aggressively than consensus rules. Inscriptions exceeding standardness limits (such as a single witness element >80 bytes in some interpretations, or transactions over 400 KB standard weight) won't propagate through default nodes but can be mined if submitted directly to a cooperating miner. This creates a two-tier system where large inscriptions depend on out-of-band miner relationships.

• ›Primary source: Casey Rodarmor's ordinal theory docs at docs.ordinals.com — the canonical specification for numbering and inscription rules
• ›On-chain explorer: ordinals.com for inscription lookup by ID; ord.io for rarity and sat-level tracking
• ›Indexer source code: github.com/ordinals/ord — the reference implementation; review the index module for FIFO logic and the inscription module for envelope parsing
• ›Block-level analysis: mempool.space shows witness sizes per transaction, useful for identifying inscription transactions by their outsized witness weight
• ›BIP discussion: Rodarmor's BIP proposal (BIP pending, discussed on the bitcoin-dev mailing list) for the formal specification attempt — note it has not been assigned a final BIP number as of mid-2024
• ›Cursed inscription history: The ord GitHub issue tracker (issue #2045 and related) documents the retroactive numbering changes