Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Protocol & Mining

Ordinals, and why the numbering is a convention

Ordinal theory assigns a number to every satoshi and lets data be attached to one. Neither the numbering nor the attachment is a rule of the Bitcoin protocol. Both are conventions that a particular piece of software chooses to follow, and that distinction explains almost everything about how the practice works.

What ordinal theory proposes

A bitcoin is not a single object sitting in a wallet. It is a set of unspent transaction outputs, each of which carries a quantity of satoshis, and each of which is spent whole and recreated as new outputs. The protocol tracks quantities, not identities: when an output of ten thousand satoshis is spent, the transaction creates new outputs whose values sum to ten thousand, and nothing in the consensus rules says which of the original satoshis ended up where. To the network, satoshis are fungible units of the same substance.

Ordinal theory is an attempt to impose an identity on them anyway. The idea, set out in the Ordinals documentation, is to number satoshis in the order they are mined and to track that numbering through every subsequent transaction. The first satoshi of the first block is number zero, the numbering proceeds through each block's subsidy in the order the outputs appear, and the scheme continues across the whole chain. The result is a total ordering over every satoshi that has ever been mined, from which the documentation derives the familiar categories: common, uncommon, rare and so on, based on where a satoshi sits relative to a block, a difficulty adjustment or a halving.

The important word is "proposes". The numbering is not in the protocol, and no node enforces it. It is computed by software that reads the chain and applies the same rules, and it is meaningful only to the extent that other people run software that agrees. Two indexers that implement the ordering differently would disagree about which satoshi is which, and the Bitcoin network itself would have no opinion on the dispute, because it never had an opinion in the first place.

How an inscription is written

An inscription is the second half of the idea: a way of attaching arbitrary data to a specific satoshi so that the data travels with it when it is spent. The mechanism uses the witness field that SegWit introduced and that taproot extended. A taproot spend can carry a witness script and its inputs, and the witness is not covered by the same block-weight accounting as the rest of the transaction, which is what makes it a practical place to put a payload.

The construction is a commit-and-reveal pair. The first transaction commits to a taproot output whose script tree contains the data, typically by embedding a hash of the payload in a script that the spender can later satisfy. The second transaction spends that output and reveals the payload in the witness, where an indexer can read it. The Ordinals documentation describes the envelope format used to mark the payload — a sequence of opcodes that delimits the content type and the body — and the reference implementation is what defines the exact rules for parsing it.

Because the payload lives in the witness, it is subject to the witness discount rather than the full block weight, and it is prunable in the sense that a node that does not need historical witness data is not required to keep it. That is a real property of the design and it is also the source of the argument about it: the data is cheap relative to its size, it is stored by nodes that keep the full chain, and it is not something the protocol was designed to carry. None of that makes it invalid. It makes it a use of the protocol's own rules that the protocol does not distinguish from any other spend.

Why the indexer is the whole story

Everything that makes ordinals useful — the numbering, the attachment, the notion that a particular satoshi carries a particular inscription — is produced by software reading the chain, not by the chain itself. A Bitcoin node validates the transactions and stores the blocks. It does not know that satoshi number 1,234,567 carries a text file, and it would not care if it did. The meaning is supplied by the indexer, and the indexer is a separate program with its own rules.

This has consequences that are easy to miss. The first is that the numbering depends on a consistent reading of the chain, including blocks that were later reorganised away: the ordering rules have to say what happens to satoshis whose first appearance was in a block that did not survive, and the answer is a convention rather than a fact. The second is that inscriptions are only as durable as the indexers that recognise them. A satoshi can be spent, merged into a larger output and split again, and the tracking rules decide where the inscription is deemed to have gone. The third is that the ecosystem's agreement is what gives the convention its value; a single indexer with different rules would produce a different, and equally unfalsifiable, history.

The comparison with the unspent output model is the clearest way to hold the distinction. The UTXO model is consensus: every node agrees on which outputs exist and what conditions spend them, and a transaction that violates those conditions is rejected everywhere. Ordinal numbering is not consensus: it is a layer of interpretation applied on top of a ledger that is deliberately indifferent to it.

What inscriptions cost, and who pays

An inscription occupies block space, and block space is the scarcest resource the protocol produces. The fee for an inscription is therefore set by the same market that prices every other transaction: the sender bids for inclusion, and the bid has to compete with payments, consolidations and every other spend waiting in the mempool. A large inscription is a large transaction, and a large transaction that wants prompt confirmation has to pay accordingly.

The cost is not only the fee. Every full node that keeps the chain stores the witness data, and every node that relays transactions carries it across the network. The witness discount means the marginal cost to the sender is lower than the marginal cost to the network in storage terms, and that gap is the substance of the long-running objection to the practice. It is a genuine trade-off rather than a technicality: the protocol's fee market allocates space efficiently among competing spends, but it does not price the long-term storage externality, and inscriptions are the clearest example of a use that exploits the difference.

The counter-argument is equally worth stating. The rules that make inscriptions cheap are the same rules that make taproot spends cheap, and those rules were adopted deliberately to improve privacy and reduce the cost of complex scripts. A protocol that permits arbitrary witness data cannot then complain when someone supplies it. The honest summary is that inscriptions are a legitimate use of the protocol's rules with a real cost that the fee market does not fully capture, and that reasonable people weigh those two facts differently.

Sources and references

The description of ordinal numbering, the inscription envelope and the taproot witness construction is taken from the reference implementation's documentation and from the BIPs that define the underlying script and witness rules. No claim about adoption, market prices or specific incidents is made here.

  • Ordinal theory, numbering and rarity categories. Ordinals, Ordinal Theory Handbook — Overview: satoshis are numbered in the order they are mined, the numbering is tracked through transactions, and rarity is defined relative to blocks, difficulty adjustments and halvings.
  • Inscription envelopes and the commit-reveal construction. Ordinals, Ordinal Theory Handbook — Inscriptions: inscription content is committed to a taproot output and revealed in the witness, with the envelope format defining how the payload is delimited.
  • Taproot and the witness structure inscriptions rely on. Bitcoin, BIP 341: Taproot — Segregated Witness v1: defines the taproot output type, the script tree and the witness program that a taproot spend reveals.
  • The witness discount and block weight accounting. Bitcoin, BIP 141: Segregated Witness: separates witness data from the transaction's base size and assigns it a lower weight, which is why witness bytes are cheaper than base bytes.