Runes

What Are Runes?

Runes is a fungible token protocol built directly on Bitcoin's UTXO model. It allows anyone to create, mint, and transfer fungible tokens on Bitcoin without relying on a separate network or sidechain. Unlike BRC-20, which encodes token data inside Ordinals inscriptions stored in witness data, Runes uses OP_RETURN outputs: a designated space in Bitcoin transactions for embedding arbitrary data that nodes can prune without affecting the UTXO set.

The protocol was designed by Casey Rodarmor, who also created the Ordinals protocol. Rodarmor built Runes specifically to address the inefficiencies he observed in BRC-20 and other early Bitcoin token experiments. BRC-20 tokens create large numbers of small, unspendable UTXOs that bloat the UTXO set: a critical data structure that every Bitcoin full node must keep in memory. Runes avoids this by keeping all token metadata in OP_RETURN, which nodes can safely discard.

The core design philosophy is simplicity: Runes aims to be the thinnest possible fungible token layer on Bitcoin, adding minimal overhead to the base chain while leveraging Bitcoin's existing UTXO architecture for tracking balances and ownership.

How It Works

Runes defines three primary operations: etching (creating a new token), minting (issuing units of an existing token), and transferring (moving tokens between UTXOs). All three operations are encoded within standard Bitcoin transactions using an OP_RETURN output that begins with a specific protocol tag.

The Runestone

Every Runes transaction contains a data structure called a "runestone" stored in an OP_RETURN output. The runestone is identified by its protocol tag and contains encoded instructions for the Runes indexer. A transaction can contain at most one runestone. If a transaction has no valid runestone, or if the runestone is malformed (called a "cenotaph"), any rune inputs are burned.

The OP_RETURN output format follows this structure:

OP_RETURN
OP_13              # Protocol tag identifying this as a Runes transaction
<encoded data>     # Serialized runestone payload

# The payload contains:
# - Edicts: transfer instructions (rune ID, amount, output index)
# - Etching: new rune definition (name, divisibility, symbol, terms)
# - Mint: which rune to mint
# - Pointer: default output for unallocated runes

The protocol tag OP_13 tells Runes-aware indexers that this transaction contains rune operations. Non-Runes nodes simply see a standard OP_RETURN output and ignore it. This is a key advantage: Runes transactions are valid Bitcoin transactions that require no consensus changes or soft forks.

Etching: Creating a New Rune

Etching is the process of defining a new rune. The etcher specifies the token's properties in the runestone:

• Name: a base-26 encoded string using only letters A through Z. Initially, only long names (13+ characters) are available. Over time, a name unlock schedule progressively allows shorter names, with single-character names unlocking last.
• Divisibility: how many decimal places the rune supports (0 for indivisible tokens, up to 38 for high precision).
• Symbol: an optional Unicode character displayed alongside amounts (like $ for dollars).
• Premine: the number of units allocated to the etcher in the etching transaction itself.
• Mint terms: optional rules for open minting, including per-mint amount, total mint cap, and start/end block heights or offsets.
• Turbo: a flag indicating the etcher opts in to future protocol upgrades for this rune.

Each rune receives a unique ID based on the block height and transaction index where it was etched, formatted as BLOCK:TX_INDEX. This ID is used in all subsequent mint and transfer operations.

Minting

If a rune's etching includes open mint terms, anyone can mint new units by including a mint directive in their runestone. Each mint transaction creates a fixed number of units (defined by the etching) and assigns them to one of the transaction's outputs.

Minting is bounded by the terms set during etching: the per-mint amount is fixed, and the etcher can cap total mints or restrict minting to a range of block heights. Once the cap is reached or the block height window closes, no more minting is possible.

Transferring: Edicts

Rune transfers are expressed through "edicts" in the runestone. Each edict specifies a rune ID, an amount, and an output index. When a transaction spends UTXOs containing runes, the indexer applies the edicts to determine which output receives which runes:

# Example: transfer 1000 units of rune 840000:1 to output 0
# and 500 units of rune 840000:1 to output 1

Edict { rune_id: 840000:1, amount: 1000, output: 0 }
Edict { rune_id: 840000:1, amount: 500,  output: 1 }

# Any remaining balance goes to the pointer output (default: first non-OP_RETURN output)
# If no edicts are specified, all runes go to the pointer output

This design mirrors how Bitcoin itself handles value: inputs are consumed entirely, and the transaction explicitly allocates outputs. Unallocated runes flow to a default pointer output, similar to how unallocated satoshis become miner fees in Bitcoin (though unallocated runes go to a designated output rather than to miners). For a deeper comparison of UTXO-based and account-based models, see the research article on the UTXO model vs. account model.

UTXO-Native Balance Tracking

Unlike account-based token systems where a single address holds a balance, Runes ties token ownership to specific UTXOs. If a UTXO contains 1000 units of a rune, spending that UTXO requires explicitly assigning those runes to new outputs. This means:

• Token transfers happen through standard Bitcoin transactions, making them compatible with existing wallet infrastructure, PSBTs, and multisig setups.
• There is no separate "token transfer" transaction type: rune movements are embedded in ordinary Bitcoin transactions.
• Each UTXO can carry multiple different runes simultaneously, allowing batch transfers in a single transaction.

Runes vs. BRC-20

Both Runes and BRC-20 enable fungible tokens on Bitcoin, but their architectures differ significantly:

The most impactful difference is UTXO set bloat. BRC-20 mint operations create thousands of small, dust-sized UTXOs that Bitcoin nodes must track indefinitely. During the BRC-20 frenzy of 2023, UTXO set growth accelerated noticeably, increasing memory requirements for full nodes. Runes avoids this entirely by storing data in OP_RETURN, which nodes prune from the UTXO set. For more context on how fee dynamics shift during periods of high on-chain activity, see the research on Bitcoin fee market dynamics.

The Halving Launch

Runes launched on block 840,000: the same block as Bitcoin's fourth halving in April 2024. This was a deliberate choice by Rodarmor. The halving block carries cultural significance in the Bitcoin community and guaranteed maximum attention for the protocol launch. The first rune (rune 0) was etched in the halving block itself, with rune IDs starting from 840000:0.

The launch triggered an intense wave of etching and minting activity. Transaction fees spiked as users competed to etch early runes with short or desirable names. For several days following the halving, Runes transactions represented a significant share of Bitcoin block space, demonstrating both the demand for Bitcoin-native tokens and the protocol's ability to operate within standard transaction limits.

Use Cases

• Community tokens: projects can issue fungible tokens on Bitcoin without deploying smart contracts on other chains, keeping their token ecosystem natively on the Bitcoin base layer.
• Memecoins and social tokens: the open minting mechanism allows permissionless participation, where anyone can mint tokens within the etcher's defined rules.
• Fungible collectibles: gaming items, loyalty points, or other fungible digital assets that benefit from Bitcoin's security and immutability.
• Stablecoin experiments: while not the primary use case today, the protocol's flexibility allows for stablecoin-like tokens backed by external reserves, similar to how tokens operate on other chains.
• Protocol governance: projects building on Bitcoin can use runes as governance tokens for on-chain voting or signaling.

Risks and Considerations

Indexer Dependency

Runes is not enforced by Bitcoin consensus. Bitcoin nodes validate that transactions are structurally valid and that OP_RETURN data is within size limits, but they do not interpret or enforce rune rules. All token logic: balance tracking, transfer validation, mint cap enforcement: is handled by off-chain indexers that parse the blockchain and maintain a rune state database.

This means rune "validity" depends entirely on indexer software. If two indexers disagree on state (due to bugs, different protocol interpretations, or version mismatches), users may see conflicting balances. There is no on-chain arbiter. The ord indexer maintained by the Ordinals project serves as the reference implementation, but running it requires a fully synced Bitcoin node and significant disk space.

Centralization of Indexing

While anyone can run an indexer in theory, the practical reality is that most users interact with runes through a small number of indexing services and marketplaces. If these services go offline, experience bugs, or censor certain runes, users may lose access to their tokens. Running a personal indexer requires technical expertise and hardware resources comparable to running a Bitcoin full node.

No Smart Contract Logic

Runes is deliberately simple. It supports etching, minting, and transferring, but nothing more. There is no on-chain programmability: no conditional transfers, no automated market making, no DeFi primitives built into the protocol. Any complex logic must be built in application layers above the protocol, coordinated through standard Bitcoin transactions and potentially leveraging Bitcoin Script or Taproot features.

Name Speculation and Squatting

The name unlock schedule (shorter names become available over time) was designed to prevent early squatting of short, desirable names. However, it also means that name speculation is baked into the protocol. Users may etch runes primarily to claim names rather than to create useful tokens, consuming block space for speculative purposes.

Fee Pressure

High levels of Runes activity can increase transaction fees for all Bitcoin users. The halving-block launch demonstrated this clearly, with fees rising sharply as users competed for block space. While each individual Runes transaction is more efficient than a BRC-20 transaction, the aggregate demand from a popular token launch can still create significant fee pressure.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.