Bitcoin Runes and BRC-20 Tokens, Explained: UTXOs vs JSON

Bitcoin was designed as a peer-to-peer electronic cash system, not a platform for issuing new assets. However, the introduction of the BRC-20 standard and subsequently the Runes protocol has enabled the creation of fungible tokens directly on the $BTC network. These standards differ fundamentally from tokens on other blockchains, relying on off-chain indexers and unique data storage methods to function within Bitcoin's strict limitations.

The Origins of Tokens on Bitcoin

The ability to create tokens on Bitcoin stems from two major network upgrades: Segregated Witness (SegWit) in 2017 and Taproot in 2021. SegWit separated transaction signatures from the main transaction data, placing them in a new section called witness data. Taproot removed size limits on this witness data and made it cheaper to store arbitrary information.

Developers realized they could use this space to attach data to individual satoshis, the smallest unit of Bitcoin. This led to the Ordinals protocol, which assigned unique identifiers to satoshis and allowed users to "inscribe" images or text onto them. Shortly after, a developer applied this concept to create BRC-20, an experimental standard for fungible tokens.

How BRC-20 Tokens Work

BRC-20 tokens are not smart contracts. They are simple text files formatted in JavaScript Object Notation (JSON) inscribed into the witness data of a Bitcoin transaction. To deploy, mint, or transfer a BRC-20 token, a user creates a Bitcoin transaction containing a JSON file that states the action taking place.

Because Bitcoin's base layer cannot read or enforce JSON data, BRC-20 relies entirely on off-chain indexers. An indexer is a piece of software run by exchanges and wallet providers that scans the Bitcoin blockchain for these specific JSON files, calculates the balances, and enforces the rules. If a user attempts to transfer more BRC-20 tokens than they own, the Bitcoin network will still process the transaction and take the network fee, but the off-chain indexer will mark the token transfer as invalid.

This architecture creates significant inefficiencies. Transferring a BRC-20 token requires two separate Bitcoin transactions: one to inscribe the transfer function onto a satoshi, and a second to send that specific satoshi to the recipient. This dual-step process consumes block space and contributes to UTXO bloat, leaving the network burdened with unspendable "junk" transaction outputs.

The Shift to Bitcoin Runes

The Runes protocol was introduced in April 2024 by Casey Rodarmor, the original creator of Ordinals, as a more efficient alternative to BRC-20. Instead of stuffing JSON files into witness data, Runes utilizes a native Bitcoin transaction feature called OP_RETURN.

OP_RETURN is a script opcode that allows a user to attach up to 80 bytes of arbitrary data to an unspendable transaction output. Runes uses this tiny space to encode token operations. When a user transfers a Rune, the transaction assigns the token balances to new unspent transaction outputs (UTXOs) within the same transaction.

This approach integrates smoothly with Bitcoin's native architecture. It requires only one transaction to execute a transfer and does not generate leftover junk outputs, directly solving the UTXO bloat caused by BRC-20.

UTXO-based vs JSON-in-witness

The primary technical difference between Runes and BRC-20 is how they interact with Bitcoin's state. Bitcoin tracks balances using the Unspent Transaction Output (UTXO) model. When a user receives Bitcoin, it is held as a UTXO. When they spend it, that UTXO is destroyed, and new UTXOs are created for the recipient and the sender's change.

Runes map directly onto this model. A Rune balance is tied to a specific Bitcoin UTXO. When that UTXO is spent, the Runes move with it. This allows Runes to benefit from native Bitcoin features like the Lightning Network and multi-signature setups.

BRC-20 tokens operate outside this model. Their balances are tracked via a global ledger maintained by off-chain indexers reading JSON text files. BRC-20 tokens are merely associated with an address, not a specific UTXO, making them rigid and incompatible with advanced Bitcoin transaction types.

Worked Example: Network Fees

To understand the cost efficiency of Runes over BRC-20, consider the network fees required to transfer a token during a period of moderate network congestion.

Assume the current Bitcoin network fee rate is 50 satoshis per virtual byte (sats/vByte).

A BRC-20 transfer requires two transactions. The first transaction (the inscription) is roughly 150 vBytes. The second transaction (the transfer) is roughly 150 vBytes. Total vBytes: 300. Total cost: 300 vBytes * 50 sats/vByte = 15,000 satoshis.

A Runes transfer requires only one transaction, utilizing an OP_RETURN output. The transaction size is roughly 200 vBytes. Total vBytes: 200. Total cost: 200 vBytes * 50 sats/vByte = 10,000 satoshis.

In this scenario, utilizing Runes reduces the network fee by 33% compared to BRC-20, while also occupying less block space and preventing the creation of excess UTXOs.

Differences from Ethereum ERC-20 Tokens

Tokens on Bitcoin function entirely differently from tokens on Ethereum. Ethereum was built to support smart contracts—programmable code that runs directly on the blockchain.

The ERC-20 standard on Ethereum defines a set of rules for a smart contract to issue and track tokens. The Ethereum Virtual Machine (EVM) natively understands and enforces these rules. If a user attempts to send more ERC-20 tokens than they possess, the smart contract immediately rejects the transaction, and the transfer fails on-chain.

Bitcoin lacks a virtual machine for complex smart contracts. Both BRC-20 and Runes are "meta-protocols." The Bitcoin network only sees and validates the movement of satoshis. It does not know that BRC-20 or Runes exist. Enforcement of token balances and rules is handled entirely by the off-chain indexers interpreting the OP_RETURN or witness data.

Common Misconceptions

• Bitcoin tokens are smart contracts: Neither BRC-20 nor Runes utilize smart contracts. They are data embedded in Bitcoin transactions that require off-chain software to interpret.
• The Bitcoin network enforces token rules: The Bitcoin protocol does not validate BRC-20 or Rune balances. It only validates the underlying Bitcoin transaction. If a user sends an invalid token transaction, Bitcoin processes it, but indexers ignore the token movement.
• BRC-20 and Runes use the same technology: BRC-20 uses JSON files in witness data (creating UTXO bloat), while Runes use OP_RETURN outputs (aligning with Bitcoin's UTXO model).

What to Watch

The adoption of fungible tokens on Bitcoin fundamentally shifts the network's economics. Token minting and trading activity frequently cause sharp spikes in network fees. For more on how network fees impact miner economics, see our guide on Solo Bitcoin Mining vs Pool Mining: The Lottery Math Explained.

While higher fees provide increased revenue for miners—crucial as the block subsidy halves every four years—they also price out users attempting to use Bitcoin for peer-to-peer payments. The long-term viability of these meta-protocols depends on the infrastructure built around them. Developers are actively working to integrate Runes into the Lightning Network, which could eventually allow for fast, low-fee token transfers while keeping base layer congestion manageable.