Runes, and the runestone that carries them

A rune begins with an etch. The etching transaction carries a runestone that names the rune, sets its divisibility and supply parameters, and commits to the terms under which it may be minted. The protocol documentation describes the fields an etch can set and the constraints the reference implementation enforces on them. Once the etch is confirmed, the rune exists as far as indexers are concerned, and the parameters recorded in that transaction govern everything that follows.

Minting is the process by which new units of the rune are created. An etch can define an open mint, in which case anyone may send a minting transaction that satisfies the recorded terms, or it can define a closed or capped mint. The terms are fixed at etch time and cannot be revised afterwards, which is the mechanism that gives a rune its supply discipline: the rules are public, they are committed in a confirmed transaction, and every indexer reads them from the same place.

Transfers move existing units between outputs. A transfer runestone assigns balances to specific outputs of the transaction, and the indexer updates its ledger accordingly. The units themselves are not a distinct asset on the Bitcoin ledger — there is no output type that holds runes — so the transfer is a claim recorded in the runestone and interpreted by software. Spending the output that the runestone assigned a balance to is what makes the transfer effective, and the protocol's rules define how balances are carried when outputs are combined or split.

Bitcoin's own rules are specified in BIPs, and a BIP is a document that describes a change precisely enough that independent implementations can agree. Runes are not specified that way. The protocol's normative definition is the reference implementation itself: the code that parses runestones, applies the etching and minting rules and maintains the ledger of balances. Where the prose documentation and the code disagree, the code is what indexers follow, because agreement between indexers is the only thing that makes a rune balance meaningful.

That arrangement has a real consequence. A protocol defined by an implementation can evolve through that implementation, and a change to parsing or to an edge case is a change to the protocol whether or not anyone wrote it down. It also means the ecosystem's coherence depends on indexers running compatible software. Two indexers that diverge on how a particular runestone is parsed will report different balances for the same rune, and the Bitcoin network will not arbitrate, because it never interpreted the bytes in the first place.

The honest framing is that this is a trade-off rather than a defect. A specification-in-code can move faster than a BIP process and can settle ambiguous cases by fiat, which is useful for a convention that has no consensus role. The cost is that the source of truth is a codebase rather than a document, and anyone building on runes has to treat that codebase as the authority. The protocol documentation is a description of the implementation, not a substitute for it.

Runes do not give the Bitcoin network any new capability. A node validates a runestone transaction exactly as it validates any other transaction: signatures, amounts, fees and script conditions. The runestone is an unspendable output, and the node's only interest in it is that it consumes block space and contributes to the fee. There is no consensus rule that a rune balance must be conserved, no rule that an etch must be unique, and no rule that a mint must respect its terms. Those constraints exist in the indexer and nowhere else.

Runes also do not inherit Bitcoin's security model in the way a reader might assume. The transactions are as final as any Bitcoin transaction, and the data is as durable as the chain. But the interpretation of that data depends on software that a user chooses to run or trust, and a wallet that reports a rune balance is reporting an indexer's conclusion. The distinction between the ledger's guarantees and the convention's guarantees is the same one that applies to bitcoin-native applications generally, and it is worth stating plainly rather than leaving it implicit.