OP_RETURN: Data on the Blockchain

The blockchain is a ledger, not a filing cabinet. Every byte stored on-chain is replicated across tens of thousands of nodes, validated by every full node forever, and can never be deleted. Yet from Bitcoin's earliest days, people have found ways to embed arbitrary data alongside financial transactions—love notes, political statements, images, and entire protocols.

The question was never whether people would embed data on-chain. They were already doing it before Bitcoin Core 0.9.0—hiding messages in fake addresses, stuffing data into multisig scripts, and creating forever-unspendable outputs that bloated every node's UTXO set. The question was whether to provide a clean, prunable channel for data, or force it underground where it does more damage.

OP_RETURN was Bitcoin's answer: a designated opcode that makes an output provably unspendable. Nodes can safely prune OP_RETURN outputs from their UTXO set—the data is stored in the blockchain history but doesn't consume memory in the critical set of spendable coins.

Our specimen is a declaration of love, etched permanently into block 308,570 on a summer day in 2014.

15.1The Specimen

Txid:^†

8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684

15.2The OP_RETURN Output

The heart of this transaction is Output 0—the OP_RETURN:

15.2.1The Zero Value

An OP_RETURN output always carries zero satoshis. Any value assigned to it would be permanently destroyed—the output can never be spent. While Bitcoin consensus allows non-zero OP_RETURN values (they're simply burned), Core's dust rule explicitly exempts unspendable outputs, so even a non-zero-value OP_RETURN output relays — the sats are simply destroyed.

15.2.2The Opcode

OP_RETURN (0x6a) immediately terminates script execution with failure. When the Script interpreter encounters this opcode, it does not evaluate any further bytes—the script fails unconditionally. This makes the output provably unspendable: no combination of witness data, scriptSig, or future opcodes can ever satisfy a script that begins with OP_RETURN.

/**
 * Returns whether the script is guaranteed to fail at execution,
 * regardless of the initial stack. This allows outputs to be pruned
 * instantly when entering the UTXO set.
 */
bool IsUnspendable() const
{
    return (size() > 0 && *begin() == OP_RETURN)
        || (size() > MAX_SCRIPT_SIZE);
}

void CCoinsViewCache::AddCoin(const COutPoint &outpoint,
                              Coin&& coin,
                              bool possible_overwrite) {
    assert(!coin.IsSpent());
    if (coin.out.scriptPubKey.IsUnspendable()) return;
    // ... otherwise insert coin into the cache ...
}

15.2.3The Data Payload

After OP_RETURN, the remaining bytes are arbitrary data. The Script interpreter never evaluates them—it already failed at the OP_RETURN. The push opcode (0x13 = push 19 bytes) is a convention, not a requirement: nodes parse it as valid Script syntax, but the bytes after OP_RETURN are effectively opaque data.

Our specimen's 19 bytes decode to ASCII:

A love note, immortalized across every Bitcoin full node on Earth.

15.3The Data Limit

OP_RETURN's data capacity has evolved through three stages:

From 2015 through 2025, the default cap was a relay policy, not a consensus rule. Miners could include OP_RETURN outputs of any size in their blocks—but standard Bitcoin Core nodes would not relay transactions with OP_RETURN data exceeding 83 bytes (the total scriptPubKey size, including the opcode and push bytes).^†

15.3.1Bitcoin Core 30: Opening Door 3

On October 10, 2025, Bitcoin Core 30.0 raised the default -datacarriersize from 83 to 100,000 bytes (effectively removing the limit, since a transaction would hit the block weight limit first) and allowed multiple OP_RETURN outputs per transaction—with the 100 kB applying to the aggregate size of their scriptPubKeys. Operators who preferred the old behavior could set -datacarriersize=83. The pull request that shipped (#32406) followed an earlier, more radical proposal (#32359) that had been debated on the mailing list, BitcoinTalk, and Delving Bitcoin since April 2025.

The change was politically charged precisely because it looked like surrender to on-chain data carriers. The strongest defense came from a framing developed by the BitcoinTalk user d5000 and echoed by Greg Maxwell: the question isn't whether data lands on-chain—the bytes are valid Bitcoin and there's no way to prevent them—but through which door it enters.

The argument for opening Door 3 is that an artificially narrow Door 3 doesn't stop data storage—it merely redirects embedders through Doors 1 and 2, both of which cost the network more. Before v30, data carriers that wanted to write more than 80 bytes had exactly two options: impersonate a key (Door 1, permanent UTXO pollution) or use an inscription envelope (Door 2, witness-discount-subsidized and never actually pruned in practice). Neither is cleaner than OP_RETURN. Greg Maxwell's framing on the April 2025 mailing-list thread put it bluntly: the 80-byte limit was "actively harmful" because "overly restrictive relay rules create serious collateral damage"—OP_RETURN data is "completely prunable and pruned," but the substitutes are not.

The counter-argument, voiced most persistently by BitcoinTalk user pooya87 and others, is that the limit worked empirically—"most spam respects the 80-byte boundary"—and that removing it signals institutional acceptance of on-chain non-monetary use. Chapter 19 revisits this tension from the Ordinals side, where Door 2 is the dominant pattern.

15.4Before OP_RETURN: Creative Abuses

OP_RETURN solved a problem that was already entrenched. Before 2014, data-embedding schemes used two techniques that were far worse for the network:

15.4.1Fake Addresses

The simplest trick: encode 20 bytes of arbitrary data as a fake Hash160 in a P2PKH output: OP_DUP OP_HASH160 <20 bytes of data> OP_EQUALVERIFY OP_CHECKSIG

This creates a valid-looking P2PKH output that no one can ever spend (no key hashes to that value). But unlike OP_RETURN, nodes cannot prune it—the output appears spendable, so it sits in the UTXO set forever, consuming memory on every full node.

15.4.2Multisig Data Embedding

More sophisticated: encode data in the public key slots of a bare multisig output. A 1-of-3 multisig can carry \(3 \times 33 = 99\) bytes of data disguised as compressed public keys: OP_1 <33B data> <33B data> <33B data> OP_3 OP_CHECKMULTISIG

Again, the output is unspendable (no corresponding private keys), but it pollutes the UTXO set. This was the technique used by early Counterparty transactions.

15.5Protocols Built on OP_RETURN

OP_RETURN's 80 bytes of structured data became the foundation for several major protocols:

15.5.1Omni Layer and USDT (2013–2025)

The Omni Layer — originally Mastercoin, one of the very first "smart contract" proposals for Bitcoin, launched in 2013 and rebranded in 2014 — used OP_RETURN to embed token operations: issuance, transfer, and decentralized-exchange offers. Every Omni transaction was a perfectly ordinary Bitcoin transaction carrying a specially formatted OP_RETURN output. The payload began with the 4-byte marker 6f6d6e69 ("omni" in ASCII), followed by a 2-byte message version, a 2-byte transaction type, and type-specific fields encoding the token ID, amount, and metadata.

Because Omni reused Bitcoin addresses to identify token holders, a token transfer also needed to name the recipient somehow. The convention: the transaction's first non-OP_RETURN output went to the recipient's Bitcoin address as a dust output (typically 546 sats, the minimum relayable value for legacy P2PKH at the time). Omni-aware wallets watched for those dust-plus-OP_RETURN patterns and updated their off-chain token ledger accordingly; Bitcoin itself knew nothing of USDT — it only saw an ordinary transaction moving a trivial amount of BTC with an arbitrary data output attached.

From 2014 through the late 2010s, USDT on Omni was the most common OP_RETURN protocol on Bitcoin. At its peak it drove a significant fraction of Bitcoin's transaction count and fee revenue, and the Omni Layer was frequently cited as proof that OP_RETURN could anchor a serious economic protocol. Then two forces eroded it. First, as Bitcoin's fees rose with each cycle of congestion, moving $100 of USDT across a protocol whose settlement cost had ballooned to $5 or $20 became economically absurd compared to the same transfer on Tron (sub-cent fees) or Ethereum L2s (a few cents). Second, Tether itself began issuing USDT on a widening list of faster, cheaper chains — TRC-20 on Tron became the dominant venue, with ERC-20 on Ethereum, SPL on Solana, and Jetton on TON close behind.

15.5.2OpenTimestamps

OpenTimestamps — announced by Peter Todd on October 4, 2016 — aggregates thousands of timestamp requests into a single Merkle tree, then commits the root hash to the blockchain via one OP_RETURN output. A single 32-byte Merkle root can commit an unlimited number of documents to a specific point in time. The public calendar servers (alice, bob, finney) pay the Bitcoin fees themselves, so timestamping is free for end users.

To verify a timestamp, the service provides a Merkle proof: the sequence of sibling hashes from the document's leaf to the on-chain root. Anyone can independently verify the proof in \(O(\log n)\) hash operations — an elegant use of OP_RETURN's limited space.

15.5.3Counterparty

Counterparty (launched 2014 via a "proof-of-burn" where participants sent BTC to the unspendable address 1CounterpartyXXXXXXXXXXXXXXXUWLpVr in exchange for XCP tokens) encodes asset creation, transfers, and decentralized-exchange operations in OP_RETURN data. After decryption, the payload begins with the 8-byte marker 434e545250525459 ("CNTRPRTY" in ASCII) followed by a type byte and operation-specific fields — enabling an entire asset layer on Bitcoin without any consensus changes.

A small technical wrinkle: Counterparty XORs its OP_RETURN data with a key derived from the first input's txid (an ARC4 stream seeded from the reversed prev-output hash). This obfuscation was added to keep Counterparty payloads from being flagged by spam filters or block explorers that grep for literal prefix strings. It means you cannot find Counterparty transactions by searching the blockchain for CNTRPRTY — you have to decrypt each candidate OP_RETURN before the marker becomes visible.

15.5.4Witness Commitment

As we saw in Chapter 14, every modern coinbase transaction contains a SegWit witness commitment in an OP_RETURN output with the magic prefix aa21a9ed. This 4-byte tag identifies the output as the witness commitment: miners include it in one coinbase output on every block that contains SegWit transactions, and the 32 bytes that follow are the commitment hash over all witness data in the block (BIP 141). This is perhaps the most critical use of OP_RETURN in Bitcoin: it binds witness data to the block header, ensuring that stripping witness data invalidates the commitment.

15.6OP_RETURN vs. Witness Embedding

For the decade between v0.11 and v30, OP_RETURN carried at most 80 bytes of data and cost 4 WU per byte (non-witness). The Taproot upgrade (Part IV) opened a different channel for data: the witness field, where data costs only 1 WU per byte. That witness discount is the foundation of the Ordinals inscription protocol (Chapter 19). Since v30, Door 3 has been effectively uncapped, but the cost-per-byte asymmetry remains:

Ordinals inscriptions use an OP_FALSE OP_IF … OP_ENDIF envelope in the witness, storing content types and data as push operations inside a dead code branch. Because witness data is discounted 4:1, a single inscription can embed 400 KB of data at one-quarter the cost of equivalent non-witness storage. Chapter 19 examines this mechanism in detail.

15.7Weight Analysis

Our specimen is a legacy transaction (no SegWit marker/flag, no witness). All bytes are non-witness data:

The OP_RETURN output contributes 30 bytes (120 WU) to the transaction. Of those, 21 bytes are the scriptPubKey (OP_RETURN + push opcode + 19 bytes of ASCII data), and the rest is the 8-byte zero value and 1-byte script length.

15.8What We Learned

• OP_RETURN (0x6a) makes an output provably unspendable: the Script interpreter fails immediately, and no spending transaction can ever satisfy it.
• OP_RETURN outputs carry zero value and can be safely pruned from the UTXO set—they never consume memory in the set of spendable coins.
• The datacarrier limit is a relay policy, not a consensus rule: 40 bytes in v0.9 (2014), 83 bytes in v0.11 (2015), 100,000 bytes across any number of OP_RETURN outputs in v30.0 (October 10, 2025). At no point did miners need the relay policy's permission—they can include an OP_RETURN of any size in a block under every version.
• The Three Doors framework (d5000, 2025) ranks on-chain data-embedding methods by harm: Door 1 fake keys (permanent UTXO pollution), Door 2 Taproot witness / inscriptions (moderate, theoretically prunable), Door 3 OP_RETURN (never enters the UTXO set). Tightening Door 3 redirects traffic to Doors 1 and 2, not away from the chain.
• Before OP_RETURN, data was embedded via fake addresses and multisig abuse—both polluting the UTXO set permanently.
• Major protocols that have used OP_RETURN include the Omni Layer (host of USDT from 2014 until Tether wound it down on September 1, 2025), OpenTimestamps, Counterparty, and the SegWit witness commitment. Tether's current Bitcoin presence is via Lightning + Taproot Assets, not OP_RETURN.
• Taproot's witness discount (1 WU/byte vs 4 WU/byte) opened a new data channel, enabling Ordinals inscriptions at far greater capacity than OP_RETURN.

15.8.1Looking Ahead

OP_RETURN and data embedding are atemporal—they exist across every era of Bitcoin. Chapter 16 introduces a different dimension of transaction anatomy: time. Timelocks make transactions programmable in time, enabling everything from delayed payments to Lightning Network channels.

Exercises

Litmus (L)

1. What does OP_RETURN do when the Script interpreter encounters it?
2. Why does an OP_RETURN output always carry zero satoshis?
3. What is the maximum OP_RETURN data size in bytes? Is this a consensus rule or a relay policy?
4. Why is OP_RETURN better for the network than embedding data in fake P2PKH addresses?
5. Decode the ASCII message from the hex bytes: 63 68 61 72 6c 65 79 20 6c 6f 76 65 73 20 68 65 69 64 69.

Hands-On (H)

1. Parse our specimen's OP_RETURN output byte by byte. Identify the value, script length, opcode, push length, and data. Verify the script length matches the actual byte count.
2. Compute the fee rate for our specimen. Given 254 bytes, weight 1,016 WU, and fee 20,000 sats, express the fee in both sat/byte and sat/WU.
3. Construct a raw OP_RETURN scriptPubKey for the message "Hello, Bitcoin!" (15 ASCII characters). Write the complete hex including the opcode and push byte.
4. Our specimen uses an uncompressed public key (65 bytes). If a compressed key (33 bytes) were used instead, what would be the new scriptSig length, total transaction size, and weight?

Proofs and Reasoning (P)

1. Explain why embedding data in fake P2PKH addresses is "more expensive" for the network than OP_RETURN, even though the on-chain size may be similar. Consider UTXO set growth, node memory, and initial block download.
2. The OP_RETURN relay limit is 83 bytes for the entire scriptPubKey. What is the maximum number of ASCII characters that can fit in a single OP_RETURN output? Account for the OP_RETURN byte and the push opcode(s).
3. Could a miner include an OP_RETURN output with 1,000 bytes of data in a valid block? Would other nodes accept it? Would other nodes relay transactions with such outputs? Explain the distinction.

Connections (C)

1. Omni Layer. Explain how USDT transfers worked on the Omni protocol (2014–2025). What went in the OP_RETURN, and why did the transaction also need a small "dust" output to the recipient? Then: why did USDT migrate off Omni to chains like Tron and Ethereum, and why did Tether choose Taproot Assets on Lightning instead of resurrecting an OP_RETURN-based layer when it returned to Bitcoin?
2. OpenTimestamps. How does OpenTimestamps use a single 32-byte OP_RETURN payload — a bare Merkle root — to timestamp thousands of documents? What cryptographic structure makes this possible?

Bridge (B)

1. Chapter 19 covers Ordinals inscriptions, which embed data in the witness rather than in OP_RETURN. Why does the witness discount make this economically viable for large data (images, media)? What is the approximate maximum inscription size?
2. The Runes protocol (Chapter 20) uses OP_RETURN with a specific tag (OP_PUSHNUM_13). Why would a new protocol choose OP_RETURN over witness embedding? What advantages does OP_RETURN offer for structured, small-payload protocols?

Solutions

L1. OP_RETURN immediately terminates script execution with failure. The script is unconditionally invalid, making the output provably unspendable. No combination of input data can ever satisfy a script beginning with OP_RETURN.

L2. Any satoshis sent to an OP_RETURN output are permanently destroyed—the output can never be spent, so the value is irrecoverable. While consensus allows non-zero values (they're simply burned), relay policy does not forbid them (the dust rule exempts unspendable outputs) — setting the value to zero simply avoids destroying bitcoin.

L3. The maximum scriptPubKey size for a standard OP_RETURN is 83 bytes (relay policy in Bitcoin Core, set by MAX_OP_RETURN_RELAY). This is not a consensus rule—miners can include larger OP_RETURN outputs in blocks, and all nodes will accept those blocks as valid. However, transactions with OP_RETURN scriptPubKeys exceeding 83 bytes will not be relayed by standard nodes.

L4. OP_RETURN outputs are provably unspendable, so nodes can prune them from the UTXO set. Fake P2PKH addresses create outputs that appear spendable (the node cannot know the Hash160 is fake), so they remain in the UTXO set forever, consuming memory on every full node. OP_RETURN explicitly marks data outputs as non-financial, allowing the network to handle them efficiently.

L5. Reading each hex byte as ASCII: 63=c, 68=h, 61=a, 72=r, 6c=l, 65=e, 79=y, 20=(space), 6c=l, 6f=o, 76=v, 65=e, 73=s, 20=(space), 68=h, 65=e, 69=i, 64=d, 69=i. The message is: "charley loves heidi".

H1. Output 0:

• 00 00 00 00 00 00 00 00: Value = 0 sats (8 bytes)
• 15: Script length = 21 bytes (1 byte)
• 6a: OP_RETURN (1 byte)
• 13: OP_PUSHBYTES_19 (1 byte)
• 63 68 61 72 6c 65 79 20 6c 6f 76 65 73 20 68 65 69 64 69: 19 bytes of ASCII data

Script length check: \(1 + 1 + 19 = 21\) bytes = 0x15.

H2. Fee rate: \(20,000 / 254 = 78.7\) sat/byte. In weight units: \(20,000 / 1,016 = 19.7\) sat/WU. Since this is a legacy transaction (no witness), the sat/byte and sat/vB rates are identical, and the sat/WU rate is exactly one-quarter of the sat/byte rate.

H3. "Hello, Bitcoin!" = 15 ASCII characters. Hex encoding:

48 65 6c 6c 6f 2c 20 42 69 74 63 6f 69 6e 21

The complete scriptPubKey: 6a (OP_RETURN) + 0f (push 15 bytes) + the 15 data bytes:

6a 0f 48 65 6c 6c 6f 2c 20 42 69 74 63 6f 69 6e 21

Total: 17 bytes.

H4. With a compressed key: scriptSig = \(1 + 72 + 1 + 33 = 107\) bytes (vs 139 with uncompressed). Savings: 32 bytes. New total: \(254 - 32 = 222\) bytes. New weight: \(222 \times 4 = 888\) WU (vs 1,016). New vsize: 222 vB.

P1. On-chain, both approaches use a similar number of bytes. But the critical difference is in the UTXO set—the in-memory database of all spendable outputs. An OP_RETURN output is provably unspendable, so nodes prune it immediately. A fake P2PKH output is indistinguishable from a real one, so it must be stored in the UTXO set forever (or until a spending transaction proves it's been claimed—which, for a fake address, is never).

The UTXO set must fit in RAM for fast validation. As of 2024, it contains 170 million entries totaling 7 GB. Every fake address adds one entry that can never be removed. Over time, this accumulates into a permanent tax on every full node. During IBD (initial block download), these fake UTXOs are created, indexed, and stored just like real ones—wasting disk I/O and memory that OP_RETURN avoids entirely.

P2. The 83-byte limit applies to the entire scriptPubKey: OP_RETURN (1 byte) + push opcode(s) + data. There are two cases:

• Data \(\leq 75\) bytes uses a single-byte push opcode (0x01–0x4b): \(1 + 1 + 75 = 77\) bytes, well within the 83-byte limit—but the single-byte push maxes out at 75 bytes of data.
• Data \(> 75\) bytes requires OP_PUSHDATA1 (2 bytes: opcode + length): \(83 - 1 - 2 = 80\) bytes of data.

The maximum is therefore 80 ASCII characters, achieved with OP_PUSHDATA1.

P3. Yes, a miner can include a 1,000-byte OP_RETURN in a valid block. The OP_RETURN data limit is a relay policy, not a consensus rule. Every node will accept the block as valid because no consensus rule restricts OP_RETURN size (beyond the overall block weight limit of 4,000,000 WU).

However, standard nodes will not relay transactions with OP_RETURN scriptPubKeys exceeding 83 bytes. The miner would have to create the transaction themselves and include it directly in their block template. This is why the relay policy is often called "soft" enforcement—it controls propagation, not validity.

C1. An Omni/USDT transfer (while the protocol was active) was a standard Bitcoin transaction with three components: (1) an input spending the sender's BTC, (2) an OP_RETURN output containing the Omni payload (6f6d6e69 prefix + 2-byte version + 2-byte transaction type + token ID + amount), and (3) a small "dust" output (546 sats) to the recipient's Bitcoin address.

The dust output was necessary because Omni used Bitcoin addresses to identify token holders. The OP_RETURN encoded the transfer instruction ("send 100 USDT from address A to address B"), but Omni-aware wallets needed to know which Bitcoin output corresponded to the recipient. The convention: the first non-OP_RETURN output was the recipient. The dust amount was the minimum value Bitcoin Core would relay (below the dust threshold, nodes rejected the transaction as spam).

Why the migration. The Omni approach piggy-backed on Bitcoin's security and decentralization, but it also inherited Bitcoin's fee market. As median Bitcoin fees rose from cents to dollars and occasionally tens of dollars per transaction, a protocol that billed a full Bitcoin transaction's worth of fees for every stablecoin transfer became uneconomic for everyday use. Tron's TRC-20 USDT settled in seconds for sub-cent fees; Ethereum's ERC-20 and L2s offered programmability Omni could never match. Tether halted new Omni issuance on August 17, 2023, and froze the remaining supply on September 1, 2025.

Why Taproot Assets, not a new OP_RETURN layer. When Tether returned to Bitcoin in 2025, it chose the Lightning Network via Taproot Assets rather than another OP_RETURN protocol. The reason is the same economic pressure that killed Omni: base-layer per-transfer cost. OP_RETURN writes a full Bitcoin transaction per token transfer — fine for issuance and anchoring, ruinous for payment volume. Taproot Assets commits only token-tree roots on-chain (via the Taproot output structure from Chapter 12) and lets Lightning carry the per-payment traffic off-chain, bringing stablecoin-grade UX to a Bitcoin rail without putting every transfer in an OP_RETURN.

C2. OpenTimestamps uses a Merkle tree. Each document submitted for timestamping is hashed, and all hashes become leaves in a binary Merkle tree. The single root hash (32 bytes) is embedded in an OP_RETURN output. With a 32-byte root, a tree of depth \(d\) can timestamp \(2^d\) documents. A tree of depth 20 timestamps over 1 million documents in one OP_RETURN.

To prove a document was timestamped, the service provides a Merkle proof: the sequence of sibling hashes from the document's leaf to the root. Anyone can independently verify the proof against the on-chain root in \(O(\log n)\) hash operations. This is the same structure Bitcoin uses for transaction Merkle trees in block headers.

B1. Witness data costs 1 WU per byte, while non-witness data (including OP_RETURN) costs 4 WU per byte. For a 100 KB image: via OP_RETURN, it would cost \(100,000 \times 4 = 400,000\) WU (10% of block weight); via witness, only \(100,000 \times 1 = 100,000\) WU (2.5% of block weight). The 4:1 cost advantage makes witness embedding economically viable for large data.

The maximum inscription size is bounded by the block weight limit: \(4,000,000\) WU minus the minimum transaction overhead. Since witness data costs 1 WU/byte, the theoretical maximum approaches 400 KB. In practice, inscriptions are slightly smaller to leave room for the transaction structure and other block transactions.

B2. OP_RETURN is superior for structured, small-payload protocols like Runes because: (1) the data is in the non-witness portion, making it visible in the stripped transaction (no witness needed to read it); (2) the long-standing 80-byte default (pre-30.0) is sufficient for protocol headers, token IDs, and amounts; (3) OP_RETURN is a well-established standard supported by all node software; (4) it doesn't require Taproot or SegWit—any transaction version can include it. Witness embedding is better for large opaque data (images, media), but for small structured protocol messages, OP_RETURN is simpler, more universal, and more explicit.