# Runes

Fungible tokens whose messages, runestones, ride an OP_RETURN output. BTI decodes them itself; ord is only its audit oracle.

URL: https://blockspace.wiki/protocols/runes/

A [rune](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/sighting/), judged [carriage](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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):

| measure | value |
|---|---|
| Book A | 33.05 GB |
| share of the chain's bytes (Book A) | 4.25 % |
| share of all Book A bytes | 24.71 % |
| tokens | 216,402 |
| operations | 249,889,795 |
| first height | 840000 |

ord, as the audit oracle, counts 216,423 runes (as of block 972,320, 2026-10-20 12:17:07 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](https://blockspace.wiki/glossary/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.

Sources:

- Blockspace Holdings records
- block.space docs: data types · https://block.space/docs/datatypes
- block.space docs: measurements · https://block.space/docs/measurements
- block.space protocols API · https://block.space/api/protocols
- block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage
- ord /status (the blockspace.to ord server) · https://blockspace.to/status

Live figures: ord as of block 972,320, 2026-10-20 12:17:07 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC

Updated: 2026-10-20