706 / 736RUNE

Runes

Fungible tokens tracked over Bitcoin UTXOs

Runes is an application protocol for creating, minting, and transferring fungible units over Bitcoin; it stores instructions in OP_RETURN runestones and reconstructs state with an indexer following the ord reference code.

Bitcoin consensus validates the ordinary transaction and scripts but knows no Rune balances; software compatible with normative ord behavior interprets etchings, mint terms, edicts, allocations, burns, and cenotaphs.

Runes tracks fungible units over Bitcoin UTXOs as application state. The protocol activated at block 840 000 and ignores earlier runestones; it is neither a new Bitcoin asset type nor a consensus change. [4]

The first transaction output beginning OP_RETURN OP_13 carries the runestone payload. An indexer joins later data pushes, decodes 128-bit LEB128 integers, and parses etching, mint, pointer, and edicts; after the first match it does not try later outputs. [1]

An etching creates a BLOCK:TX Rune ID and may set name, divisibility, symbol, premine, and open mint terms with amount, cap, and height or offset window. A displayed name or symbol proves no limited supply; the full etching transaction and terms decide. [1]

Input runes plus any mint and premine begin unallocated. Edicts assign them to outputs; the remainder goes to the pointer output or the first non-OP_RETURN output. A wrongly built transaction can misdirect or burn units. [1]

The ord code is Runes' normative specification, and its documentation says code behavior wins on disagreement. Bitcoin full nodes validate the transaction, not Rune names, supply, mint cap, or balances; indexers must converge on that application state. [2]

A malformed runestone is a cenotaph. Unknown even tags or flags, bad varints, invalid output indices or pointers, and other parse failures can burn every input rune; an etching becomes unmintable with zero supply and a failed mint may consume cap while burning units. [1]

Names unlock after activation in periods of 17 500 blocks. A non-reserved name needs a commitment in an input witness tapscript spending an output with at least six confirmations; Turbo explicitly accepts future protocol changes that may raise light-client validation cost. [1]

Verification requires the Rune ID, etching transaction, exact ord version, premine, divisibility, mint terms, completed mint count, edicts, pointer, cenotaph status, and current UTXO allocations. An exchange ticker or one wallet balance is not proof of supply or ownership. [3]

For the clearest picture, read this entry together with Ordinals Inscriptions, OP_RETURN, UTXO, Bitcoin Script, Fee Rate, RGB Protocol. The reverse links also lead from BRC-20.

01Do Bitcoin full nodes validate Runes?

No. Full nodes validate the Bitcoin transaction and its OP_RETURN data, but do not calculate Rune balances or apply etching, mint, and edict rules. ord or a compatible indexer does that.

02Is a Rune the same as an inscription or BRC-20 token?

No. Runes uses binary runestone messages and UTXO allocations. Inscriptions attach content to a sat, while BRC-20 is a separate metaprotocol with different indexing rules.

DOC · 001Ordinal Theory Handbook — Runes SpecificationSpecification DOC · 002ord — Runes reference implementationPrimary DOC · 003Ordinal Theory Handbook — Wallet GuideDocumentation DOC · 004ord — READMEPrimary
Revised: Source-first · No investment advice