BA-12 · LESSON 03

Runes

KEY DEFINITIONS

Terms used in this lesson

Runes: A Bitcoin metaprotocol that assigns fungible-token meaning to transaction outputs through off-chain interpretation.
Runestone: Transaction data interpreted by the Runes protocol to describe token creation or allocation.
Cenotaph: A malformed or intentionally unrecognized Runes message whose affected token balances are burned under the protocol’s rules.
OP_RETURN: A Bitcoin Script operation commonly used to create an unspendable output carrying a small amount of data.
OP_13: A Bitcoin Script operation that pushes the small integer 13 onto the stack; Runes uses it as part of a runestone marker.
LEB128: Little Endian Base 128: a variable-length integer encoding used for integers inside a Runes message.
Identifier: Identifier: a value used to distinguish one request, object, or participant from another.

Runestones encode fungible token operations whose meaning is reconstructed by compatible indexers; cenotaph behavior supports upgrade semantics through burns.

55 min Difficulty 3/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · data commitmentExternal meaning is anchored to exact Bitcoin bytesSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered validation pipeline

01
PAYLOADTyped external meaning
An application defines a payload, event, inscription, or token instruction.
02
ENCODECanonical bytes
Ordering, lengths, tags, and version rules must be unambiguous.
03
COMMITRunes
The Runes mechanism places or commits those bytes in a Bitcoin transaction.
04
BITCOINValid transaction
Bitcoin nodes enforce only Bitcoin consensus rules for the carrier transaction.
05
INDEXReconstructed state
Application software scans the chain and applies its own versioned state-transition rules.

Rule shown: Bitcoin validates transaction bytes and Script; indexers apply additional protocol meaning deterministically.

STAGE 1 OF 5PAYLOAD: Typed external meaning

An application defines a payload, event, inscription, or token instruction.

Governing relationship: Bitcoin validates transaction bytes and Script; indexers apply additional protocol meaning deterministically. Complete path: 1. PAYLOAD, Typed external meaning. An application defines a payload, event, inscription, or token instruction. 2. ENCODE, Canonical bytes. Ordering, lengths, tags, and version rules must be unambiguous. 3. COMMIT, Runes. The Runes mechanism places or commits those bytes in a Bitcoin transaction. 4. BITCOIN, Valid transaction. Bitcoin nodes enforce only Bitcoin consensus rules for the carrier transaction. 5. INDEX, Reconstructed state. Application software scans the chain and applies its own versioned state-transition rules.

1. State transitionWhat exists, what changes, and what results

BEFORE

Inputs carry 1,000 units of rune R. A production-grammar runestone assigns 600 R to output 1 and 300 R to output 2, with output 3 as the remainder pointer.

MECHANISM

An indexer looks up rune allocations assigned to each spent input under its current chain state.

AFTER

Rune issuance, conservation, allocation, and burns are versioned metaprotocol rules reconstructed from Bitcoin order, not native Bitcoin asset accounting.

Text equivalent: Starting from Inputs carry 1,000 units of rune R. A production-grammar runestone assigns 600 R to output 1 and 300 R to output 2, with output 3 as the remainder pointer. The mechanism begins when An indexer looks up rune allocations assigned to each spent input under its current chain state. The resulting lesson is Rune issuance, conservation, allocation, and burns are versioned metaprotocol rules reconstructed from Bitcoin order, not native Bitcoin asset accounting.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Collect input rune balances

An indexer looks up rune allocations assigned to each spent input under its current chain state.

Complete path: 1. Collect input rune balances: An indexer looks up rune allocations assigned to each spent input under its current chain state. 2. Decode the runestone: Locate OP_RETURN OP_13, concatenate only data pushes, decode safe unsigned LEB128 integers, split tag/value fields from the body, and reconstruct delta-encoded Rune IDs in edicts. 3. Apply issuance operations: Etching flags, premine, name commitments and unlocking rules govern a new rune. An open Mint field references a Rune ID; an ineligible or capped mint adds no units but does not by itself turn an otherwise valid runestone into a cenotaph. 4. Allocate through edicts: Edicts distribute available rune amounts to transaction outputs. Unallocated amounts follow the protocol's pointer or default allocation rules. 5. Handle cenotaphs deterministically: A cenotaph does not make the Bitcoin transaction invalid. The Runes indexer applies burn behavior so newer meanings can remain safely unrecognized by older parsers.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

The parser consumes exact OP_RETURN OP_13 pushes and unsigned LEB128 fields, then applies Rune ID, issuance eligibility, edicts, pointer, output selector, conservation, burn, and odd/even tag rules.

CHANGED CONDITION

An unrecognized even field or out-of-range selector creates a cenotaph burn, while an ineligible capped mint adds no units; neither result makes the Bitcoin transaction consensus-invalid.

Important distinction: A cenotaph makes the entire Bitcoin transaction consensus-invalid. The transaction can be valid Bitcoin. Runes-aware indexers interpret the malformed or unrecognized message as a burn outcome under their rules.

Text equivalent: The accepted path is enforced by The parser consumes exact OP_RETURN OP_13 pushes and unsigned LEB128 fields, then applies Rune ID, issuance eligibility, edicts, pointer, output selector, conservation, burn, and odd/even tag rules. If the required condition changes, An unrecognized even field or out-of-range selector creates a cenotaph burn, while an ineligible capped mint adds no units; neither result makes the Bitcoin transaction consensus-invalid.

Loading lesson visuals...

Learn the idea

Runes is a fungible-token metaprotocol interpreted from Bitcoin transactions. A production runestone begins OP_RETURN OP_13, concatenates data pushes, and decodes unsigned Little Endian Base 128 integers, abbreviated LEB128, before interpreting fields and delta-encoded edicts. An edict assigns amounts of a Rune ID to output numbers. Etching defines a rune, while a Mint field names an existing Rune ID: its terms specify units per eligible mint and a cap on the number of mints. Unrecognized odd fields are ignored for forward compatibility; unrecognized even fields and other defined flaws create a cenotaph that burns input runes under the active rules.

GUIDED EXPLANATION1/5 ideas inspected

Collect input rune balances

An indexer looks up rune allocations assigned to each spent input under its current chain state.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A cenotaph makes the entire Bitcoin transaction consensus-invalid.”

The transaction can be valid Bitcoin. Runes-aware indexers interpret the malformed or unrecognized message as a burn outcome under their rules.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.