Runes

Runes 4.25 % of the chain's bytes in Book A, as of block 972,299, 2026-10-20 09:30:48 UTC

A rune is a fungible token of the Runes protocol. BTI's token table names it by its rune id, the block and transaction of its etching (block:tx); the name is an alias. UNCOMMON•GOODS is rune 1:0, which the table calls "rune #0".

How runes put data on Bitcoin #

A rune's messages are runestones, carried in an OP_RETURN output tagged OP_13. The data-types reference describes the channel. An OP_RETURN output is provably unspendable and Bitcoin Core never puts it in the UTXO set. Its bytes are base bytes, four weight units each, so they get no witness discount. The reference says OP_RETURN pays four times the witness price per byte and wins for small messages, where single-transaction atomicity matters. It lists Runes as one of those.

A runestone is a list of integers. Case 1 of the BTI case studies decodes one: a pointer and one edict, which moves 10,000 raw units of LUNARBITS•ON•THE•MOON to output 1. The whole carrier is a 14-byte script. The runestone can also carry an etching, which creates a rune, or a mint of an existing rune.

How BTI attributes the bytes #

Runes is a native protocol. BTI's own runes decoder reads the chain from bitcoind. It is a transcription of ord's rune updater, and it keeps a balance state machine by replay. ord's decode and rune endpoints are used only to cross-check. The adapters table says runes "does NOT belong under the ord adapter". It is the one native unit allowed a clamp on ord, which only stops the pass from running ahead of the oracle.

The case studies show the main shapes:

• A dedicated transfer (case 1, block 961,197). Every output serves the rune or is change, so the claim is dedicated and covers the whole 408-byte transaction: content 0, structure 408, overhead 0. The edict's own 8 bytes are a named sub-span of the carrier output.
• Two protocols in one runestone (case 2, block 911,180). One 30-byte OP_RETURN mints UNCOMMON•GOODS and carries an Alkanes protostone. The rune and the alkane each take half of the 371 bytes, 185.5 bytes each.
• A rune on an inscription (case 3, block 905,952). A rune mint, a BRC-20 mint and an inscribed sat share one 367-byte reveal. The rune and the sat take 171 bytes each, and the tick takes 25.
• A cenotaph that still etches (case 11, block 840,101). A malformed runestone still created INSCRIBERUNES, with no terms. The claim is labelled mint, and the riding gate keeps two unrelated outputs out of its books.
• A failed mint of a rune that does not exist (case 12, block 840,000). Someone minted 8400000:1, a typo. ord records nothing for a mint of an unknown rune, so there is no claim, only a residue row: measured demand, never backing.
• A rune drifting through a plain spend (case 16, block 840,109). Runes on the inputs moved by the protocol's default route, with no runestone at all. That is a sighting, judged carriage: zero in every book.

Ruleset v1's fact table adds one rule for runes: an edict or pointer aimed at a provably unspendable output is a burn. The case studies found no reachable cenotaph that exercises the burn arm by hand, and left it to a fixture drawn from the replay (finding F6).

Runes carry no file, so their Book C is 0 honestly. A rune's backing is its structure and overhead.

Live figures #

The family's books (as of block 972,299, 2026-10-20 09:30:48 UTC):

ord, as the audit oracle, counts 216,409 runes (as of block 972,304, 2026-10-20 10:17:29 UTC).

Two runes stand out. Read from the protocols API on 2026-10-20 (books at block 972,199), UNCOMMON•GOODS (1:0) had 23.87 GB of Book A across 165,758,746 book entries, and COOK•THE•MEMPOOL (840000:65) had 0.84 GB. The API lists both as sub-items of the family. On 2026-10-18 the heaviest tokens board put UNCOMMON•GOODS at rank 1 of all tokens by Book A.

Holders: read on 2026-10-20, the leaderboard's coverage table placed 99.95 % of the family's Book A on 1,098,444 addresses.

Measured findings #

In the July 2026 measurement run, runestones had a bytes:vbytes ratio of 1.0000, "zero discount, to four decimals". Inscriptions, on the same chain in the same year, measured 3.374.

The same run gives runes a place in the chain's history. Data payload peaked at 45.4 % of block bytes at height 833,000 and fell to 31.9 % at 850,000. The measurements page reads the fall as "runes replacing inscription bodies with 20-byte runestones": a more efficient protocol cut the chain's data share while the number of tokens grew, and backing per token fell.

Related #

• Claims (T2)
• The three books
• Carriage and the free-ride index
• The witness discount
• Holders and share of backing
• blockspace.to
• rune
• edict
• etching
• cenotaph

Sources #

1. block.space docs: data types · block.space/docs/datatypes
2. block.space docs: measurements · block.space/docs/measurements
3. block.space protocols API · block.space/api/protocols
4. block.space leaderboard coverage API (holders measured per protocol) · block.space/api/leaderboard/coverage
5. ord /status (the blockspace.to ord server) · blockspace.to/status
6. Blockspace Holdings records