📝

OP_RETURN: Bitcoin's Data Layer

5 min read

educational history protocol-upgrades
Share: X Bluesky Mastodon Reddit HN

Bitcoin's scripting language has an opcode named OP_RETURN whose explicit job is to make a script fail. An output that begins with OP_RETURN is unspendable by anyone, ever. Bitcoin Core marks these outputs as provably-unspendable and skips them when building the UTXO set. They cost block space, they pay no rent, they confer no economic right. And yet they have become Bitcoin's most important extension point.

Why does this exist?

For Bitcoin's first five years, people who wanted to embed arbitrary data on chain (timestamping services, alt-protocol bootstraps, image enthusiasts) did so by encoding bytes as fake Bitcoin addresses, sending tiny amounts to those addresses, and accepting that the bitcoin would be lost forever. This worked, but it left junk in the UTXO set forever, because nodes had to keep track of those outputs in case someone (impossibly) showed up with the matching private key.

Bitcoin Core 0.9 (March 2014) introduced standardness rules that accepted OP_RETURN outputs as a "real" way to embed data. The deal: if you mark your data output with OP_RETURN, bitcoind will see that it's unspendable, exclude it from the UTXO set entirely, and accept your transaction as standard. Initially the limit was 40 bytes. Bitcoin Core 0.11 (July 2015) raised it to 80 bytes, and that ceiling stood for a decade. Bitcoin Core 30.0 (October 10, 2025) raised the default to 100,000 bytes, which in practice leaves the transaction size limit as the only cap, and began relaying transactions with more than one OP_RETURN output. Bitcoin Knots kept a small default. None of this is consensus: it is relay policy, and a miner has always been free to include a larger OP_RETURN.

What an OP_RETURN looks like

The script is just OP_RETURN <data bytes>. Pull a block from the inscription era (height 800,000, July 2023) and look for outputs of type nulldata:

Open in playground → current tip
Open in playground → block-level summary
Open in playground → July 2023, plenty of OP_RETURN activity
Open in playground → full block 800,000, look for nulldata outputs

In the verbose-2 output, look for outputs whose scriptPubKey.type is nulldata. Their asm field starts with OP_RETURN followed by the hex bytes. Decode those bytes (often UTF-8 text or a protocol-specific binary format).

What protocols use it

Once OP_RETURN became standard, an entire ecosystem of "second-layer" protocols adopted it to use Bitcoin as a settlement layer for non-payment data:

Each protocol has its own envelope format. Most start with a short "magic number" or ASCII tag, like omni (Omni) or OA (Open Assets: the bytes 4f41 plus a two-byte version), so you can identify which protocol owns a given OP_RETURN by the first few bytes of its data. Counterparty is the exception: its CNTRPRTY tag is there, but the whole payload is scrambled with ARC4 keyed by the transaction's first input txid, so you only see the tag after you unscramble it.

The aggregate footprint

Modern Bitcoin blocks contain a meaningful but minority share of OP_RETURN-using transactions. Compare a block from April 2024 to one from March 2015, before OP_RETURN traffic took off:

Open in playground → early 2015, mostly payment txs
Open in playground → 2024, lots of OP_RETURN + ordinals + payments

Both blocks are valid. Both follow the same consensus rules. The second one carries vastly more diverse data because the protocol layer above it has matured to use Bitcoin as a settlement substrate for many things beyond just payments.

The debate that never quite settled

Many Bitcoin Core developers were skeptical of OP_RETURN as a feature. The argument: Bitcoin's job is to be money, and cluttering blocks with arbitrary data drives up fees for normal payments. The counter-argument: Bitcoin's job is to be uncensorable settlement, and "what counts as a payment vs. data" is exactly the kind of judgement Bitcoin's design avoids making. If you're paying the fee, you're entitled to the bytes.

For ten years the 80-byte limit was a soft compromise: enough to be useful for timestamping and protocol commitments, not so much that you could embed full images. (Inscriptions, which use the witness path instead of OP_RETURN, sidestepped the limit entirely while it stood. That's a different story: Ordinals.)

In 2025 the argument flared again. A June 6, 2025 statement from Bitcoin Core contributors said relay policy is not a tool for mandating how Bitcoin is used, and that refusing to relay what miners include anyway just pushes the data into other channels. Bitcoin Core 30.0 (October 10, 2025) raised the default OP_RETURN size limit to 100,000 bytes. Bitcoin Knots kept a small limit, so the relay limit a node enforces depends on which software it runs.

Sources

Read more: The Genesis Block, The Halvings, or The Patoshi Pattern.