Chapter 18 showed how inscriptions create non-fungible digital artifacts—one inscription per sat, each unique. Runes take the opposite approach: they create fungible tokens on Bitcoin, where every unit of a given rune is identical and interchangeable.†
Where inscriptions live in the witness (Taproot script-path envelopes), runes live in OP_RETURN outputs. Where inscriptions exploit the witness discount for cheap storage, runes exploit OP_RETURN's compactness for efficient protocol messages. The two protocols coexist cleanly: a single transaction can contain both an inscription (in the witness) and a runestone (in an OP_RETURN output) without conflict.
The Runes protocol activated at block 840,000—the same block as Bitcoin's fourth halving (April 20, 2024).
A rune protocol message is called a runestone. It is stored in a transaction output whose scriptPubKey begins with:
OP_RETURN OP_13
The OP_13 opcode (0x5d) identifies the output as a runestone, distinguishing it from other OP_RETURN protocols. The remaining data pushes in the scriptPubKey are concatenated into a payload buffer, which is decoded as a sequence of 128-bit LEB128 integers and parsed into the runestone's fields.
Unlike inscriptions (which use the witness discount via Taproot script-path spends), runestones are OP_RETURN outputs—non-witness data at 4 WU/byte. This is acceptable because runestone payloads are small (typically \(<\)80 bytes), so the absolute weight cost is modest. The OP_RETURN approach has a key advantage: the runestone is visible in the transaction's output list without parsing witness data.
The payload is a sequence of LEB128 (Little-Endian Base 128) variable-length integers, each up to 128 bits. Each byte uses bit 7 as a continuation flag: if set, more bytes follow.
| Value | LEB128 Encoding |
|---|---|
| 7 | 07 |
| 127 | 7f |
| 128 | 80 01 |
| 300 | ac 02 |
The decoded integers are interpreted as a sequence of tag/value pairs. Each tag identifies a field:
| Tag | Field | Parity |
|---|---|---|
| 0 | Body (edicts follow) | even |
| 1 | Divisibility | odd |
| 2 | Flags | even |
| 3 | Spacers | odd |
| 4 | Rune (name) | even |
| 5 | Symbol | odd |
| 6 | Premine | even |
| 8 | Cap | even |
| 10 | Amount | even |
| 12 | HeightStart | even |
| 14 | HeightEnd | even |
| 20 | Mint | even |
| 22 | Pointer | even |
| 126 | Cenotaph | even |
Unrecognized odd tags are safely ignored. Unrecognized even tags produce a cenotaph (malformed runestone)—an upgrade mechanism that ensures old clients do not misinterpret new features.
A rune is etched (created) by a transaction whose runestone has the Etching flag set (bit 0 of the Flags field). Etching defines the rune's immutable properties:
| Property | Description |
|---|---|
| Name | 1–26 letters (A–Z), encoded as modified base-26 integer |
| Symbol | Unicode codepoint displayed after amounts (e.g., $, U+16A0) |
| Divisibility | Decimal places (0 = indivisible, 2 = 0.01 precision) |
| Spacers | Bullet characters (•) between letters for readability |
| Premine | Units allocated to the etcher at creation |
| Terms | Open-mint parameters: cap, amount, height/offset limits |
Names are encoded as modified base-26 integers: A = 0, B = 1, …, Z = 25, AA = 26, AB = 27, and so on. Names are between 1 and 26 letters long. To prevent front-running, etching a non-reserved name requires a commitment: a data push of the name in an input's tapscript, where the committed output has at least six confirmations.
Initially, only names of 13+ characters are unlocked. Shorter names unlock progressively: every 17,500 blocks (4 months), the next shorter length becomes available. One-character names will unlock between blocks 1,032,500 and 1,050,000 (2028).
Each rune is identified by its block height and transaction index within that block, written as BLOCK:TX. For example, the rune etched in the 2nd transaction of block 840,000 has ID 840000:1.
If an etching includes the Terms flag (bit 1), it creates an open mint. Anyone can mint units of that rune by including a Mint field (tag 20) with the rune's ID in their runestone. Minting is subject to the etcher's terms:
A mint is open when all terms are satisfied and closed when any term is violated.
Runes are transferred by edicts—instructions within the runestone that assign rune balances to specific outputs. Each edict contains:
| Field | Description |
|---|---|
| Rune ID | Block height + transaction index (delta-encoded) |
| Amount | Number of units to transfer |
| Output | Index of the destination output |
Edicts appear after tag 0 (Body) in the integer sequence and are encoded in groups of four integers: block delta, tx delta, amount, output. The delta encoding compresses rune IDs: sorted by rune ID, each edict stores only the difference from the previous one.
After all edicts are processed, any unallocated runes transfer to the first non-OP_RETURN output (or the output designated by the optional Pointer field).
The Runes protocol activated alongside Bitcoin's fourth halving at block 840,000 (April 20, 2024). The competition to etch the first runes was fierce: transactions paid extraordinary fees to secure inclusion in this historic block.
| Field | Value |
|---|---|
| txid | 2bb85f4b… c69e |
| Block | 840,000 (April 20, 2024 00:09 UTC) |
| Version | 2 |
| nLockTime | 0 |
| Input | 1 (P2TR, 2,471,128,002 sats) |
| Output 0 | P2TR, 1,797,928,002 sats |
| Output 1 | OP_RETURN (runestone), 0 sats |
| Fee | 673,200,000 sats (6.732 BTC) |
| Size / Weight / vsize | 330 B / 747 WU / 187 vB |
| Feerate | 3,600,000 sat/vB |
A fee of 6.732 BTC (3.6 million sat/vB) reflects the extreme competition for inclusion in the runes activation block. Block 840,000 collected over 37.6 BTC in total fees—more than the 3.125 BTC subsidy by a factor of twelve. This was a one-time event; typical rune transactions pay normal market feerates.
Output 1's scriptPubKey in hex:
6a OP_RETURN
5d OP_13 (Runes protocol tag)
21 OP_PUSHBYTES_33
02 07 04 b5 e1 d8 e1 c8 ee b7 88 a3 07 05 a0 2d
03 9f 3e 01 02 06 80 dc 9a fd 28 08 c7 e8 43 0a 64 33-byte payload
The 33-byte payload decodes as LEB128 tag/value pairs:
| Tag | Field | Value | Meaning |
|---|---|---|---|
| 2 | Flags | 7 | Etching + Terms + Turbo |
| 4 | Rune | (128-bit int) | Rune name (modified base-26) |
| 5 | Symbol | 5,792 | Runic letter fehu (U+16A0) |
| 3 | Spacers | 7,967 | Bullet placement bitmap |
| 1 | Divisibility | 2 | Two decimal places |
| 6 | Premine | 11,000,000,000 | 110,000,000.00 units (div. 2) |
| 8 | Cap | 1,111,111 | Max 1,111,111 mints |
| 10 | Amount | 100 | 1.00 unit per mint (div. 2) |
This transaction also contains an inscription in its witness—the "ord" envelope with a delegate field (tag 0x0b). The two protocols coexist without conflict:
This separation is by design: inscriptions and runes occupy different parts of the transaction, enabling a single transaction to perform both operations simultaneously.
A malformed runestone is called a cenotaph (an empty tomb). A cenotaph is produced when the runestone contains:
The consequences are severe:
The burn-on-error design is intentional. When the protocol evolves (new tags, new flags), old clients cannot correctly interpret the new semantics. Rather than silently misrouting runes, old clients treat the unknown fields as a cenotaph and burn everything. This ensures users are never misled about where their runes are: either the client understands the transaction fully, or all runes are visibly destroyed. It is a strong incentive to keep software updated.
OP_RETURN outputs prefixed with OP_13.Exercises
OP_RETURN instead of witness data for its protocol messages. What are the tradeoffs compared to the inscription approach?OP_RETURN usage in Runes (Chapter 19) with the simple data embedding in Chapter 14. How does adding OP_13 and LEB128 encoding transform OP_RETURN from a raw data field into a structured protocol layer?OP_RETURN output plus a standard P2TR input and output. Estimate its weight. Compare to a minimal inscription (Ch. 18) with 40 bytes of content.OP_RETURN size limit were reduced to 40 bytes (as some proposals have suggested), how would this affect the Runes protocol? Could runestones still function?Solutions
L1. A runestone output is identified by a scriptPubKey beginning with OP_RETURN OP_13 (bytes 6a 5d). The OP_13 distinguishes it from other OP_RETURN protocols.
L2. LEB128 (Little-Endian Base 128). Each byte uses 7 bits for data and bit 7 as a continuation flag. Values up to 128 bits (the width of rune amounts) can be encoded.
L3. A cenotaph is a malformed runestone—one containing unrecognized even tags, invalid varints, out-of-range outputs, or other errors. All runes entering the transaction are burned (permanently destroyed). This ensures old clients never silently misroute runes when the protocol evolves.
L4. As modified base-26 integers: A = 0, B = 1, …, Z = 25, AA = 26, AB = 27, and so on. The 128-bit encoding allows names up to 26 characters.
L5. Block 840,000 (April 20, 2024)—the same block as Bitcoin's fourth halving.
H1. \(300 = 256 + 44 = 2 \times 128 + 44\).
LEB128 encoding: take 7 bits at a time from the least significant end.
0101100). More bytes follow, so set bit 7: \(44 + 128 = 172 = \texttt{0xac}\).0000010). Last byte, so bit 7 stays clear: \(2 = \texttt{0x02}\).Result: ac 02.
H2. Divisibility 3 means three decimal places. \(12,345\) atomic units \(= 12,345 / 10^3 = 12.345\). With symbol #: displayed as 12.345 #.
H3. Inscription #0 paid 1 sat/vB (322 sats for 322 vB, block 767,430, December 2022). The rune specimen paid 3,600,000 sat/vB (6.732 BTC for 187 vB, block 840,000, April 2024). The difference is not a protocol cost—it reflects the extreme competition for inclusion in block 840,000, which simultaneously activated the Runes protocol and the fourth halving. Both events attracted massive demand for block space. Normal rune transactions pay market feerates comparable to any other Bitcoin transaction.
P1. Runestone payloads are small (\(<\)80 bytes for typical operations), so the 4\(\times\) weight penalty of non-witness data is modest in absolute terms (\(<\)320 WU). Using OP_RETURN makes the protocol message visible in the transaction's output list without parsing witness data—simpler for indexers and light clients. Inscriptions use the witness because their payloads are large (images, media), where the 4\(\times\) discount matters enormously. Runes are optimized for compact protocol messages; inscriptions are optimized for bulk data storage.
P2. "Returning to sender" requires knowing which input owns which runes—a complex, potentially ambiguous operation. A default fallback would create situations where old clients think runes went to one place while new clients know they went to another, breaking consensus on rune state. Burning is unambiguous: all parties agree the runes are destroyed. This creates a strong incentive for users to keep software updated (protecting their runes) while ensuring the protocol can safely evolve by adding new even tags. The harshness of the penalty is the mechanism's strength—it eliminates ambiguity entirely.
P3. Without a commitment requirement, an attacker could observe a pending etching transaction in the mempool, extract the desired rune name, and submit a competing etching at higher feerate to claim the name first (front-running). The six-confirmation tapscript commitment means the name must be committed to a confirmed UTXO before the etching transaction appears. Six confirmations (60 minutes) make it impractical to front-run because the commitment must be buried deep enough that reorganizing it out would require significant hashrate.
C1. Chapter 15's OP_RETURN is raw data embedding—arbitrary bytes with no structure beyond what the application imposes. Runes adds the OP_13 prefix as a protocol discriminator, LEB128 encoding for compact 128-bit integer representation, and a defined tag/value schema that gives the data semantics (etching, minting, transferring). This transforms OP_RETURN from a "write arbitrary bytes" mechanism into a structured protocol layer with versioning (even/odd tag parity) and error handling (cenotaphs).
C2. Rune mint (P2TR 1-in-2-out with 40-byte runestone):
Minimal inscription with 40 bytes of content:
The inscription is slightly lighter (151 vB vs. 163 vB) because the 40-byte payload benefits from the witness discount. For small payloads, the difference is modest. As payload size grows, the witness discount favors inscriptions increasingly.
B1. Lightning exploits P2WSH (funding output), multisig (2-of-2 control), timelocks (CSV, CLTV for revocation and HTLC timeouts), and SegWit (malleability fix for the commitment chain). Runes exploit OP_RETURN (protocol messages), Taproot script commitments (name front-running protection), and the output ordering rules of standard transactions. Lightning builds a persistent off-chain state machine; Runes builds a token ledger. Both are purely interpretive—no consensus changes required—but they interpret different transaction fields for different purposes.
B2. Most runestone payloads are \(<\)40 bytes for simple mints and transfers, so a 40-byte limit would still accommodate basic operations. However, complex etchings with multiple fields (name, symbol, divisibility, terms, premine) can exceed 40 bytes, and transactions with many edicts certainly would. The protocol could adapt by splitting operations across multiple transactions, but this would increase complexity and cost. More critically, the 40-byte limit would constrain future protocol evolution by limiting the number of tag/value pairs per runestone.