OP_RETURN

OP_RETURN is a Bitcoin Script opcode that immediately marks the script it appears in as invalid, making any output that uses it provably unspendable. Because the output can never be redeemed, it does not need to live in the UTXO set forever — full nodes can recognise and prune it from their spendable-coin database. This makes OP_RETURN the sanctioned way to commit a small amount of arbitrary data to the timechain (timestamps, asset-issuance proofs, commitment hashes) without bloating the set of spendable coins every node must hold in fast storage.

How it works

A typical data-carrying output sets a value of zero satoshis and a scriptPubKey of OP_RETURN <data>. When a node evaluates the script, OP_RETURN halts execution and fails the output, so any coins assigned to it are burned by design — which is why the convention is to assign none. The data after the opcode is simply stored in the transaction, never executed. The elegance is in what this avoids: before OP_RETURN was standardised as the data-carrier pattern, embedders abused fake public keys and unspendable-looking addresses, creating outputs that nodes could never prove dead and therefore had to carry in the UTXO set indefinitely. OP_RETURN gave that demand a pressure valve that is honest about its own unspendability.

The relay-policy limit

For years, default node relay policy capped a single OP_RETURN payload at 80 bytes via the datacarriersize setting — a standardness rule governing what a node relays, not a consensus rule governing what a block may contain. Bitcoin Core v30 (October 2025) relaxed this default, raising the cap and admitting multiple OP_RETURN outputs per transaction, a change that drew vigorous community debate about whether the network should accommodate or resist data-heavy use. Miners and node operators running alternative policies (for example, Knots) can still set tighter limits on what they relay or template into blocks. The consensus layer was untouched throughout: OP_RETURN behaviour at validation is unchanged, and a transaction exceeding someone's relay policy has always been valid inside a block if a miner includes it. The episode is a clean case study in the difference between policy and consensus — a distinction every node runner should internalise.

What it means for miners and node runners

For miners, OP_RETURN traffic is simply fee-paying demand: the data pays its way into a block through the same mempool auction as every other transaction, and templates include it when it wins on fee rate. For node runners, the design protects your long-term costs — the data lives in block storage, which can be pruned, rather than in the UTXO set, which every node carries forever. In our experience explaining this to miners, the key intuition is that the network charges you for the data via the fee while sparing every node the cost of storing it as live state. Reasonable people disagree about how much non-monetary data Bitcoin should carry; the protocol's answer is to price it and keep it out of the state that matters.

Using it well

For builders, the craft is minimalism: commit a hash of your data rather than the data itself whenever possible, since 32 bytes of digest can anchor gigabytes of off-chain content — this is precisely how timestamping services aggregate thousands of documents into a single OP_RETURN commitment. The chain then proves that something existed at a point in time, while storage lives wherever storage is cheap. For node operators, the takeaway is agency: relay policy is yours to set, and running with defaults, tighter limits, or looser ones are all legitimate choices that shape only what your node forwards, not what the network can ultimately confirm. That local sovereignty over policy — while consensus stays uniform — is one of Bitcoin's quieter design strengths, and OP_RETURN is where most people first encounter it.