What is Runes?

Introduction

Runes is a Bitcoin-native fungible token protocol that lets Bitcoin transactions etch, mint, and transfer interchangeable token units using compact messages embedded in transaction outputs. The reason it matters is not simply that it puts tokens on Bitcoin (other schemes already did that) but that it tries to do so in a way that matches Bitcoin’s native accounting model instead of fighting it.

That design choice is the key to understanding Runes. Bitcoin does not keep balances in accounts. It tracks spendable chunks of value called UTXOs, short for unspent transaction outputs. If you want a token protocol on Bitcoin to feel mechanically natural, the obvious question is: should token balances also live in UTXOs? Runes answers yes.

This sounds like an implementation detail, but it drives almost everything else: how transfers are encoded, why the protocol uses [OP_RETURN](https://scribe-topic-id.invalid/protocols.bitcoin.op_return), how wallets and indexers reconstruct balances, and why Runes was presented as a cleaner alternative to BRC-20-style token tracking. In the official Ordinals documentation, Runes are described as allowing Bitcoin transactions to etch, mint, and transfer Bitcoin-native digital commodities, and every unit of a rune is fungible; unlike an inscription, where each item is distinct.

There is also an important practical fact up front: the normative specification of Runes is the ord reference implementation. The official documentation is explicit that, aside from the ord code itself, prose descriptions are not the final authority. For anyone building wallets, explorers, or indexers, that means compatibility is not just about understanding the idea of Runes. It is about matching the behavior of ord, especially around edge cases and malformed messages.

Why were Runes created and what problem do they solve?

Bitcoin token protocols existed before Runes, so why invent another one? The short answer is that earlier approaches often asked Bitcoin to carry more interpretive baggage than its transaction model naturally supports.

A useful contrast is Ordinals and the ecosystem that grew around them. Ordinals give individual satoshis identity. That is a natural fit for NFT-like artifacts, where uniqueness matters. But fungible tokens are the opposite problem: you do not care which unit you hold, only how many. Building fungibility on top of machinery designed around individually tracked artifacts can work, but it tends to introduce extra state conventions, more indexing rules, and more room for disagreement between implementations.

This is where Runes fits. Casey Rodarmor’s earlier design rationale emphasized a few goals: keep the protocol simple, avoid off-chain dependencies, avoid a native protocol token, and fit Bitcoin’s UTXO model. The idea was not that fungible tokens on Bitcoin were suddenly a perfect use of block space. Even the protocol’s author was unusually blunt that fungible tokens are mostly speculative and often low-quality. The narrower claim was that if such demand already exists, then a token format that is more compact and more UTXO-aligned may impose less structural mess on the chain than alternatives.

So the problem Runes solves is not “how do we create a token system from scratch?” Bitcoin already gives you transactions, outputs, and a globally ordered chain. The problem is: **how do you attach fungible-asset meaning to ordinary Bitcoin transactions with as little extra machinery as possible? ** Runes answers by saying that rune balances live in outputs, protocol messages live in a specific OP_RETURN pattern, and all state changes happen when transactions consume and create UTXOs.

How do Runes represent token balances; in UTXOs or in accounts?

If you remember only one thing, remember this: a rune balance is attached to a Bitcoin output.

That means a single UTXO can contain some amount of bitcoin and, in the Runes interpretation layer, some amount of one rune, several runes, or none. When that UTXO is spent, the transaction consumes not just the bitcoin value at the consensus layer but also the rune balances attributed to that output by the Runes indexer. The new transaction can then reassign those rune balances among its outputs.

This is a very different mental model from account-based token systems, where an address has a balance that gets incremented and decremented in place. In Runes, nothing is updated in place. Instead, token state moves the same way bitcoin value moves: by destroying old outputs and creating new ones.

That alignment has consequences. It makes the protocol easier to reason about if you already understand Bitcoin transactions. It also means wallets and indexers need to know which outputs currently hold which rune amounts, not just a per-address total. If you lose track of output-level state, you lose the thread of the protocol.

It also explains why Runes is often described as more native to Bitcoin than BRC-20. Whether one prefers it or not, the mechanism is cleaner: the protocol does not need to pretend Bitcoin has accounts when it does not.

Where and how is a Runes runestone stored and decoded inside a Bitcoin transaction?

Runes protocol messages are called runestones. A runestone is the part of a Bitcoin transaction that tells Runes-aware software whether this transaction is creating a rune, minting more of one, transferring balances, or some combination of those.

Mechanically, a parser looks for the first output in the transaction whose [scriptPubKey](https://scribe-topic-id.invalid/protocols.bitcoin.bitcoin_script) begins with OP_RETURN OP_13. If it finds one, it concatenates all following data pushes in that script into a payload buffer. That payload is then decoded as a sequence of 128-bit LEB128 varints, which are variable-length integers.

The exact choice of OP_RETURN matters. OP_RETURN creates provably unspendable outputs and is Bitcoin’s standard place for carrying small amounts of arbitrary protocol data. Runes uses that space to carry instructions while keeping the token balances themselves associated with ordinary spendable outputs elsewhere in the transaction.

This separation is important. The OP_RETURN output is not where your rune balance “lives.” It is where the transaction publishes the rules for how rune balances should be interpreted. The balances themselves end up in the spendable outputs the runestone points to.

There is also a strictness here that many readers underestimate. If the runestone output contains a non-data-push opcode where the parser expects data pushes, or if the varints are malformed, the result is not a soft warning. It becomes what the protocol calls a cenotaph, which has severe consequences.

What information can a runestone contain (etching, mint, edicts, pointer)?

At the highest level, a runestone can contain four kinds of information: edicts, an optional etching, an optional mint, and an optional pointer.

An etching creates a new rune and sets its properties. A mint asks to create additional supply of an existing rune, if that rune’s mint is still open. Edicts say how many units of which rune should be allocated to which outputs of the current transaction. The pointer is a fallback output index for unallocated runes that remain after processing edicts.

This structure is compact, but it is easier to understand with a narrative example.

Imagine Alice controls a UTXO that already holds 500 units of some rune. She builds a Bitcoin transaction with three spendable outputs: one paying Bob, one returning change to herself, and one unrelated payment. She includes a runestone in an OP_RETURN output. In that runestone, she includes edicts saying that 200 rune units go to Bob’s output and 250 go to her change output. After those edicts are processed, 50 rune units remain unallocated. If the runestone has a pointer to her change output, those 50 also go there. If there is no pointer, the remaining units go to the transaction’s first non-OP_RETURN output by default.

The mechanism here is simple but powerful: a Runes transaction begins with whatever rune balances are present in its inputs, possibly adds newly minted units if a mint succeeds, and then allocates the resulting pool across outputs according to the runestone. The outputs become the new holders of those rune balances.

How is a new rune created (etching) and how is it identified on‑chain?

A rune starts life through an etching. This is the act that creates the asset and fixes its permanent properties.

The official documentation says those properties are immutable once set. They include the rune’s name, its divisibility, an optional symbol, an optional premine, and optional mint terms. Divisibility is just a display convention over integer units: if divisibility is 2, then an on-chain amount of 1234 is displayed to humans as 12.34. The protocol tracks integer quantities; decimals are presentation.

A rune is identified not primarily by its human-readable name, but by a RuneId, written as BLOCK:TX. Here BLOCK is the block height where the etching transaction appears, and TX is that transaction’s index within the block. This is one of the protocol’s cleanest ideas. Human names are memorable, but on-chain identity comes from chain position.

That distinction matters because names can be desirable, scarce, and socially important, while RuneId is deterministic. If indexers agree on the chain and transaction ordering, they agree on the rune’s canonical ID.

The naming system has additional rules. Rune names are encoded as a modified base-26 integer, and the protocol includes a staged unlocking schedule for names starting at activation. The Runes protocol activated at block 840,000, and runestones appearing before that block are ignored.

For non-reserved names, etching also requires a commitment in a tapscript input to prevent front-running. The mechanism is easy to miss, but the reason is straightforward: if you broadcast an etching for a desirable name with no prior commitment, someone else could copy the name and attempt to get confirmed first. The commitment binds the etching transaction to the intended name in advance.

How does minting work for Runes and who can create additional supply?

Not every rune is fixed-supply. An etching can define an open mint with terms. If those terms are satisfied, anyone can create a mint transaction.

The important thing to understand is that Runes separates the existence of a mint policy from the act of minting under that policy. The etching sets the rules once, immutably. Later transactions can invoke those rules by including the rune’s ID in the runestone’s Mint field.

Those mint terms can include a cap on the number of mints, a fixed amount created per mint, and opening or closing conditions based on block heights or offsets. A mint is open only while all of its terms are satisfied. Once any required condition fails, the mint is closed.

If a mint succeeds, the newly created amount is added to the transaction’s pool of unallocated runes. From there, the transaction may distribute those newly minted units using edicts, or let them fall through to the pointer or default output routing. So minting is not a separate asset-delivery step. It plugs directly into the same allocation mechanism used for ordinary transfers.

This is conceptually elegant because it preserves one invariant: whether rune units came from inputs or from a successful mint, they enter the same temporary pool and are assigned to outputs by the same rules.

How do edicts allocate Runes to specific transaction outputs?

The workhorse of Runes transfers is the edict. In decoded form, each edict specifies four integers: the rune ID’s block height, the rune ID’s transaction index, the amount, and the output number.

The documentation makes two encoding details especially important. First, rune IDs in edicts are delta-encoded for compactness. Second, the edicts must be sorted by rune ID before encoding. This is not cosmetic. It is part of how the protocol keeps transfer data small and deterministic.

When a parser encounters the tag value that signals edicts, it interprets all following integers as a series of four-integer edict records. Each edict then allocates units of the specified rune to a transaction output. Edicts are processed in order.

After all edicts are processed, some rune units may still remain unallocated. The protocol then needs a deterministic fallback. By default, those units go to the first non-OP_RETURN output in the transaction. A runestone can override this with a pointer, which directs the leftovers to a specified output instead.

This fallback rule matters operationally. It means a transaction can move runes even if its runestone does not explicitly allocate every last unit. But it also means wallet software must be careful: if you build a transaction without understanding how unallocated balances flow, you may accidentally send tokens somewhere unintended.

Runes can also be burned intentionally by directing them to an OP_RETURN output. That fits the broader rule that OP_RETURN outputs are unspendable. If tokens end up there, they are effectively destroyed.

What is a cenotaph and what happens if a runestone is malformed?

The sharpest edge in Runes is the cenotaph. A cenotaph is what results when a runestone is malformed.

This is not just invalid metadata that indexers ignore. The protocol assigns cenotaphs active consequences. According to the official documentation, if a transaction contains a cenotaph, all runes input to that transaction are burned. If the malformed runestone attempted an etching, the etched rune exists with zero supply and is unmintable. If the transaction attempted a mint, the mint still counts against the rune’s cap, but the minted units are burned.

That design does two things at once. It strongly discourages sloppy implementations, and it creates a crisp, machine-detectable failure mode that can also serve as an upgrade boundary. But it also means the protocol is unforgiving. A parser disagreement is not merely a display bug. It can change supply accounting and burn assets.

This is one reason the documentation repeatedly pushes integrators toward ord. If alternate implementations differ even slightly in decoding malformed data, they can diverge on which transactions burned runes, which runes are mintable, and where balances should live.

For developers and operators, this is the central operational lesson: in Runes, edge cases are part of the protocol, not peripheral details.

Why is the ord implementation the authoritative Runes specification?

Many blockchain protocols have a written spec and multiple implementations that try to match it. Runes is more explicit about where truth lives. The official documentation states that the ord reference implementation is the normative specification and that alternative implementations are used at the integrator’s own risk.

That sounds unusual until you consider what the protocol is asking software to do. A Runes indexer must scan Bitcoin transactions, discover runestones, decode varints, interpret fields, apply mint windows and caps, track balances per UTXO, and handle malformed data in a way that may burn assets. Small ambiguities do not stay small.

If two indexers disagree on whether a payload overflowed, whether a malformed opcode sequence created a cenotaph, or how a corner-case edict should be interpreted, they may produce different balance sheets. For a fungible token protocol, that is existential. Markets, wallets, and explorers need a shared answer to the question “who owns what?”

So the governance model of Runes is not just social. It is embodied in software. In practice, ord anchors interoperability.

How do Runes compare to Ordinals and BRC‑20 for implementing fungible tokens?

Runes emerged from the broader Ordinals ecosystem, but it solves a different problem. Ordinals track individual satoshis and are best understood as a way to attach uniqueness and provenance to specific sats. That is why they fit collectibles and inscription-style artifacts.

Runes, by contrast, are for fungibility. They do not care which satoshi carries a unit in the way Ordinals do. They care which output currently holds a quantity of a given rune.

That is why Runes is often contrasted with BRC-20. BRC-20 demonstrated that there was demand for fungible tokens on Bitcoin, but it did so using conventions layered on top of inscriptions and indexing rules that many developers viewed as awkward for fungible balances. Runes was positioned as a more compact, more UTXO-native alternative.

This does not mean Runes is “part of Bitcoin” at the consensus level. It is still a protocol that lives in interpretation space: Bitcoin miners validate the transactions, but they do not enforce rune balances. Runes-aware software does. The difference is that the interpretation is built to mirror Bitcoin’s own transaction model more closely.

What are common use cases and market behaviors for Runes tokens?

Mechanically, Runes can represent any fungible token on Bitcoin. In practice, the early wave was dominated by meme assets, speculative launches, airdrops, and race-to-etch behavior around activation and early naming.

That early demand was large enough to matter for Bitcoin block space and fee markets. Secondary reporting on the launch period described Runes-related activity as accounting for a substantial share of Bitcoin transactions and miner fees shortly after activation, especially around the halving-era launch window. Those figures were time-bounded and volatile, but they showed that Runes was not a niche curiosity on day one.

This usage pattern is worth understanding without romanticizing it. The protocol is technically interesting because of how it maps assets onto UTXOs. The social uses have often been much more familiar: speculation, branding, collectibility around early issuance, and exchange-like trading behavior. The engineering and the market behavior are not the same thing.

What are the trade-offs of using Runes to host fungible tokens on Bitcoin?

Runes becomes easier to judge once you separate two questions that are often blurred together.

The first question is whether Bitcoin should host fungible token activity at all. Reasonable people disagree. Heavy token traffic consumes block space, raises fees, and can conflict with some users’ vision of Bitcoin as primarily money.

The second question is narrower: **if that activity exists, what is the least structurally messy way to encode it? ** Runes is an answer to the second question. Its claim is not that token speculation becomes noble if implemented with OP_RETURN. Its claim is that a compact, UTXO-based scheme is more coherent than one that forces fungible behavior through machinery designed for unique artifacts.

Whether that tradeoff is worth it depends on what you value. If you care mostly about minimizing protocol complexity and state ambiguity, Runes has a strong internal logic. If you care mostly about preserving block space for other uses, then a cleaner token format may still look like an unwanted burden.

Conclusion

**Runes is a fungible token protocol for Bitcoin that treats token balances as UTXO state and uses compact OP_RETURN runestones to describe how that state changes. ** That is the idea to keep.

Everything else follows from it. Etching creates a rune and fixes its rules. Minting adds new units when those rules allow it. Edicts allocate units to outputs. Pointers catch leftovers. Cenotaphs punish malformed messages harshly. And because these rules are precise and unforgiving, the ord implementation functions as the real specification.

If you remember that Runes is trying to make fungible tokens look as much like ordinary Bitcoin transaction flow as possible, the protocol stops feeling like a bag of special cases and starts looking like a consistent design choice.

How do you get practical exposure to Runes and Bitcoin‑native tokens?

Get practical exposure by either trading a listed rune token on Cube Exchange or by using Cube to move Bitcoin on‑chain so you can etch, mint, or transfer runes from your own wallet. Cube lets you fund an account and trade listed assets, or withdraw BTC to a Taproot wallet to construct runestone transactions that carry OP_RETURN messages.

1. Deposit BTC or USDC into your Cube account via the fiat on‑ramp or a direct crypto transfer.
2. If a rune token is listed, open the RUNE/BTC or RUNE/USDC market on Cube and place a limit order for price control or a market order for immediate execution.
3. If you need direct on‑chain interaction (etching, minting, or custom transfers), withdraw BTC from Cube to your Taproot‑capable wallet and confirm the exact UTXO(s) you will spend.
4. Build and broadcast the rune transaction with ord‑compatible tooling: include the OP_RETURN runestone, encode edicts and any pointer, then submit the signed TX; verify edicts and pointer to avoid accidental burns (cenotaphs).