You've got a PDF. A contract draft, timestamped by nobody but you, sitting on a server that your counterparty could later claim was backdated. You don't need to move money. You need to nail that document to something immovable. So you hash it, push 32 bytes into a Bitcoin transaction, and walk away. The chain does the rest.
That's OP_RETURN in one motion. The mechanism underneath it is worth understanding precisely, because the details are where developers go wrong.
The UTXO Set: Why It's Not Just a Bookkeeping Detail
Every unspent transaction output (UTXO) in Bitcoin is live state. Full nodes keep the entire set in memory or fast storage because they need to validate every new transaction instantly: is this coin actually spendable, or is someone trying to spend air? The UTXO set sits in the low hundreds of megabytes and has grown steadily for years. That growth isn't free. It taxes every new node joining the network, every existing node processing blocks, every hardware wallet verifying a payment path.
Now think about what happens if someone stuffs arbitrary data into spendable outputs. You'd create UTXOs carrying a few satoshis as dust, encoding data in their locking script. Those outputs would technically be spendable, so every node would track them forever, waiting for a spend that probably never comes. The UTXO set bloats. The cost gets socialized across everyone running a node. It's like leaving a shopping trolley in a parking space: technically legal, a quiet tax on everyone else.
OP_RETURN was designed specifically to close that door.
What OP_RETURN Actually Does
OP_RETURN is a script opcode that, when the interpreter encounters it, immediately marks execution as failed. Not "failed due to a bad signature" failed. Provably, deterministically, permanently unspendable.
A standard OP_RETURN output looks like this:
``` OP_RETURN <data> ```
The data portion can be up to 80 bytes (Bitcoin Core's standard relay policy limit, raised from an original 40 bytes; the consensus layer itself doesn't hard-cap it at this figure). Eighty bytes is enough for a SHA-256 hash (32 bytes) with room left for a protocol prefix and a version byte.
Because the output is provably unspendable, nodes don't add it to the UTXO set. It lives in the block permanently, indexed in transaction data. But it never enters the live state database every node has to carry forward. The shopping trolley gets taken away at the door.
The satoshi value attached to an OP_RETURN output is set to zero. Any miner including the transaction effectively burns a non-zero amount assigned to it, because it can never be claimed. In practice, wallets building OP_RETURN transactions always set that output value to 0.
A Worked Example: Timestamping a Legal Document
A small law firm wants to prove a contract draft existed before a client meeting. Their developer, call her Priya, hashes the PDF with SHA-256 and gets a 32-byte digest. She constructs a Bitcoin transaction with one normal input (spending an existing UTXO she controls) and two outputs: one change output back to her own address, and one OP_RETURN output carrying a 6-byte protocol prefix followed by the 32-byte hash. Total data: 38 bytes, well inside the 80-byte limit.
The transaction fee is paid by the input. The OP_RETURN output carries 0 satoshis. The transaction broadcasts, gets mined, and now that hash is sealed into Bitcoin's chain with a block timestamp. Anyone disputing when the document was created gets handed the original PDF, an independent hash, and a block explorer link. Done.
Priya's colleague Marcus tries the same thing six months later using an older library that didn't zero out the value field. He accidentally assigns 1,000 satoshis to the unspendable output. Those satoshis are gone. The miner claimed them, because the protocol allows miners to take any output that can't be spent normally. Always zero out the value field. This is not a subtle point.
The Relay Policy Layer vs. the Consensus Layer
This is where people consistently get confused, and I want to be precise about it because the confusion has real consequences.
Bitcoin's consensus rules determine what's valid in a block that nodes will accept. Bitcoin's relay policy (also called standardness rules) determines what transactions nodes will forward through the mempool before they're mined. These are different things.
OP_RETURN outputs are consensus-valid in any quantity, with any data size, as long as the transaction as a whole is valid. A miner could include a transaction with three OP_RETURN outputs each carrying 200 bytes of data and no node would reject the block. Consensus-valid.
But Bitcoin Core's default relay policy only forwards transactions with at most one OP_RETURN output carrying 80 bytes or fewer. Transactions violating standardness rules don't get relayed peer-to-peer, which means miners running default software won't see them in their mempools, which means they're unlikely to be mined. A soft filter, not a hard wall. Miners can and do configure custom policies.
This distinction matters enormously for anyone building on top of OP_RETURN. Your application might work perfectly in testing, where you control the mining, and fail completely in production, where you need standard relay, if you exceed the 80-byte limit. I've watched developers publish "OP_RETURN is broken" posts after exactly this scenario. The payload wasn't rejected by the network's truth; it was filtered by default relay policy. Different failure modes, different remedies entirely.
What Gets Built on Top
OP_RETURN became the foundation for a small ecosystem of data-anchoring protocols.
OpenTimestamps batches thousands of document hashes into a single Merkle tree, then commits the root in one OP_RETURN transaction. One transaction, one block, proof for potentially millions of documents. The per-document cost approaches zero asymptotically as volume grows. Elegant is the right word for it.
Counterparty, one of the earliest Bitcoin meta-protocols, used OP_RETURN to encode asset issuance and transfer instructions directly in transactions. The Bitcoin network sees normal transactions moving satoshis. Counterparty nodes also read the OP_RETURN data and maintain a separate state layer tracking asset ownership. Two ledgers, one chain.
Various certificate-anchoring and supply-chain provenance systems have adopted similar patterns. The 80-byte payload is tight: a 32-byte hash, a 4-byte protocol identifier, 44 bytes left for metadata. Tight constraint. Surprisingly flexible in practice.
What People Get Wrong
The most persistent misconception is that OP_RETURN outputs are "deleted" or "pruned" from the chain. They're not. They're in every full block, forever. What they're excluded from is the UTXO set, the live database of spendable coins. The data is permanent and publicly retrievable by anyone querying transaction history. If you're using OP_RETURN to store something sensitive, even hashed, think carefully about what you're anchoring and why.
The second common mistake is treating the 80-byte standardness limit as a consensus rule. It isn't, as I've already argued above.
The third: confusing OP_RETURN with other data-embedding techniques. Segregated Witness introduced a separate witness data field. Taproot's tapscript allows larger scripts. Some protocols embed data in multisig pubkeys (sometimes called "pubkey stuffing"), which does pollute the UTXO set and is, in my view, genuinely bad practice that the ecosystem has been too slow to deprecate. OP_RETURN's virtue is that it's clean: the protocol explicitly signals unspendability, nodes don't track it, and the intent is legible to anyone reading the script.
Ask yourself whether any other data-embedding technique can say all three of those things at once.
The Bargain
OP_RETURN represents a deliberate tradeoff that Bitcoin's developers thought through carefully and revised twice before settling. The initial implementation allowed 40 bytes, later raised to 80. The one-output-per-transaction standardness rule was added to prevent OP_RETURN from becoming a cheap bulk data-storage layer that bloats block space without serving Bitcoin's primary function. That was the right call.
The result is a narrow but clean channel: enough space to commit to almost any external data via a hash, not enough to store the data itself. Bitcoin stays a payments network. The anchoring capability comes along for the ride, priced at whatever transaction fee the market demands.
Priya's timestamped contract will be readable by any Bitcoin node a century from now. The UTXO set will never have carried it as a burden. What's interesting is that the constraint itself, 80 bytes, no UTXO entry, zero value, is what makes the whole thing trustworthy: a channel narrow enough that nobody can abuse it into something the network didn't sign up to be.