What is Runes Protocol?
👋 New to this? Just start reading at the top — it begins in plain English and gets more detailed as you scroll. Jump to any level:
🟢 The simple version
Plain English — no jargon. Start here.
Runes Protocol is a fungible token standard for Bitcoin, created by Ordinals inventor Casey Rodarmor and launched at the April 2024 Bitcoin halving, designed to be more Bitcoin-compatible than BRC-20 by storing token balances directly in Bitcoin UTXOs rather than requiring off-chain indexers to interpret JSON Inscriptions.
The BRC-20 problem Runes solves
BRC-20 tokens work by interpreting JSON text Inscriptions — "mint 1000 ORDI to address X" — as instructions processed by off-chain indexers. This creates two problems: UTXO bloat (BRC-20 operations create many "junk" UTXOs that clog Bitcoin's UTXO set) and indexer trust (different indexers may interpret the same Inscriptions differently, creating disagreements about token balances). BRC-20 is not natively understood by Bitcoin nodes — it is purely an application layer convention.
Runes Protocol, created by Casey Rodarmor and launched at Bitcoin block 840,000 (the April 2024 halving), solves both problems. Runes stores token balances directly in Bitcoin UTXO data, using Bitcoin's OP_RETURN output field — a standard Bitcoin field that Bitcoin nodes already process. Runes tokens are UTXO-native: a Rune balance is part of a Bitcoin UTXO, not a record in an off-chain indexer database.
How Runes work
A Rune is etched (created) in a Bitcoin transaction that includes a specific OP_RETURN output containing the Rune's name, supply, and other properties. Rune balances are stored in OP_RETURN outputs of subsequent transactions — the "runestone" in each transaction specifies which Rune is being transferred and to which outputs. Any Bitcoin full node running the Runes protocol can parse these OP_RETURN outputs and track all Rune balances without any external indexer.
The halving launch — deliberate timing
Runes launched at Bitcoin block 840,000 — the April 2024 Bitcoin halving block — as a deliberate decision by Rodarmor to concentrate initial excitement and fee revenue. The halving block itself etched the first Rune (UNCOMMON•GOODS). The launch generated significant miner fee revenue on halving day, the busiest Bitcoin fee day in years.
Is it legal in India?
Yes. Runes are tokens on Bitcoin — VDA classification applies. See India regulation.
🟡 A bit more detail
For when you want to go a little deeper.
Runes vs BRC-20 — the technical comparison
BRC-20 uses Inscription envelopes in Taproot witness data; Runes uses OP_RETURN outputs. BRC-20 requires off-chain indexers for state tracking; Runes state can be derived from on-chain data alone. BRC-20 minting creates many small UTXOs (UTXO bloat); Runes minimises UTXO creation — balances are consolidated in existing UTXOs rather than requiring new ones. BRC-20 has no protocol-level protection against double minting in edge cases; Runes is formally specified with clear precedence rules for conflicting operations.
Runes launched with significant speculative activity — hundreds of Rune tokens were etched in the first days, including DOG•GO•TO•THE•MOON (the largest airdrop in Bitcoin history), LOBO•THE•WOLF•PUP, and numerous meme tokens. The Runes ecosystem developed quickly: wallets (Xverse, Magic Eden Wallet), marketplaces (Magic Eden, OKX), and DEXes emerged within months. By 2026, Runes has largely displaced BRC-20 as the dominant Bitcoin fungible token standard due to its UTXO-native design and lower UTXO footprint.
Naming — the bullet separator convention
Rune names use a distinctive naming convention: all capital letters separated by bullet points (•). The name UNCOMMON•GOODS, for example, is a valid Rune name. Names with fewer characters require more time before they can be etched (to prevent squatting on short names), enforced by a time-lock that decreases as Bitcoin approaches the end of its emission schedule. Single-character Rune names cannot be etched until approximately 2057. This schedule ensures equitable name distribution over time.
Key Runes metrics: total Runes etched, Runes trading volume, miner fee contribution from Rune transactions, and wallet/marketplace adoption. Runes contributes meaningfully to Bitcoin miner fee revenue — an important consideration as Bitcoin's block subsidy continues to halve and miners must rely increasingly on transaction fees for security funding. Live data: Ordinals.com/runes · CoinGecko Runes.
🟣 The full technical picture
For the technically curious.
The Runestone format
A runestone is an OP_RETURN output containing a Runes protocol message. The runestone encodes: Edicts (token transfers — source Rune ID, quantity, output index), Etching (new Rune creation — name, supply, divisibility, mint terms), and Pointer (a default output for unallocated Rune balances). The encoding uses a compact varint format — Rune IDs reference the block and transaction index of the etching transaction, keeping IDs short. Rune balances not explicitly allocated in the runestone's edicts go to the pointer output (or the first non-OP_RETURN output by default). Cenotaphs — malformed runestones — burn all Rune inputs, preventing stuck balances.
Source: Rodarmor, C. (2024). Runes Protocol Specification. docs.ordinals.com/runes.html · Runes GitHub: github.com/ordinals/ord
Open minting and premined Runes
A Rune can be etched with open minting terms — specifying a mint cap (maximum mints allowed), mint limit (tokens per mint transaction), and optionally a start/end block range during which minting is active. Open minting allows anyone to permissionlessly mint the Rune by sending a transaction with the correct runestone. This is similar to BRC-20 minting but enforced at the protocol level. Alternatively, a Rune can be etched with all supply pre-allocated to the etching transaction's outputs (a "premined" Rune) — useful for projects wanting controlled distribution without public minting.
Runes' UTXO model tracks balances without an account system. When a Bitcoin UTXO containing Rune balances is spent, the runestone in the spending transaction specifies how to redistribute those balances across the transaction's outputs. If no runestone exists, all Rune balances in the inputs are burned (lost). This "explicit allocation required" model prevents accidental loss of Rune balances in normal Bitcoin wallets that don't understand Runes — they simply won't add a runestone, so the Runes burn rather than being transferred incorrectly. This is a deliberate safety design: wallet support must be explicit, not accidental.
Key facts
- Created by: Casey Rodarmor (same as Ordinals)
- Launched: Bitcoin block 840,000 (April 2024 halving)
- Storage: OP_RETURN outputs (UTXO-native)
- Advantage over BRC-20: No UTXO bloat, no off-chain indexer required
- First Rune: UNCOMMON•GOODS (halving block)
- Naming: ALL•CAPS•WITH•BULLETS (time-locked short names)