A broadcast nobody can spend.

Output anatomy

An OP_RETURN output is an ordinary transaction output with a value (almost always zero satoshis) and a scriptPubKey that begins with the byte 0x6a. Everything after that byte is data pushes. The organisation's readers assemble the payload by concatenating every push in order.

Frame: a 54 byte scriptPubKey carrying a 52 byte OP-20 mint payload. Total transaction weight cost is driven by the script length, not by the value field.

Push encodings the readers accept

Any other opcode inside the carrier makes the payload unreadable to the OP-20 and OP Names decoders, which raise protocol_mismatch rather than guessing. A truncated push, where the declared length runs past the end of the script, is rejected the same way.

Provably unspendable

When a script is evaluated, OP_RETURN marks the transaction as invalid immediately. There is no witness, signature, preimage or future soft fork that lets you satisfy it. This is different from an output that merely looks hard to spend: it is a proof, checkable by anyone, that no spend exists.

The practical consequences are worth stating plainly:

• Any value you attach to an OP_RETURN output is destroyed. Use zero.
• You cannot recover an OP_RETURN output by "sweeping" a wallet, because there is nothing to sweep.
• Nothing about the payload gives anyone rights over anything. Ownership in the protocols on this carrier is expressed by other outputs in the same transaction, not by the OP_RETURN itself.

Prunable from the UTXO set

Because the output is provably unspendable, a node has no reason to keep it in the set of outputs it must track in order to validate future transactions. Full nodes therefore skip OP_RETURN outputs when building the UTXO set. This is the technical reason OP_RETURN is considered the polite way to attach data to Bitcoin.

Note the second consequence, which matters for anyone writing software here: because indexers cannot read protocol state out of the UTXO set, they must replay blocks. That is exactly what the Bitcoin Universe OP Names authority does, and it is why its state can be rebuilt deterministically from a chosen start height.

Relay and standardness

Whether a node forwards your transaction is policy, not consensus. A transaction that no node will relay is still perfectly valid if a miner includes it.

• Bitcoin Core carried a default data carrier limit of 83 bytes for the whole scriptPubKey for many years. That is OP_RETURN plus a one byte push prefix plus 80 payload bytes.
• Under that default policy a transaction with more than one data carrier output was also non standard.
• Bitcoin Core version 30 removed that default cap, so a node running current defaults will relay larger OP_RETURN outputs. Older nodes, alternative implementations and individual relay operators may still apply their own limit.

The Bitcoin Universe OP Names reader applies its own hard bound of 4096 assembled payload bytes and records anything larger as payload_too_large evidence. That is an indexer safety bound, not a network rule.

What it costs

An OP_RETURN output costs fee for its size and nothing else, permanently. There is no dust threshold to satisfy because the output holds zero value, and there is no future spending fee because it can never be spent.

Output total counts 8 bytes of value plus the script length prefix plus the script. Every byte here is non witness data, so it is charged at four weight units per byte.

That last point is the honest cost comparison: OP_RETURN data is never discounted. Data in a witness is.

Compared with other carriers

Three families of technique put data on Bitcoin, and they make genuinely different trade offs. This is the part most easily misrepresented, so the differences are stated in mechanism terms.

Witness envelopes

An envelope hides content inside a taproot script path that is never executed, then reveals it when the committing output is spent. The content is cheap because witness bytes are discounted, and it is prunable because it is input data rather than an output. What it costs you is a two transaction ceremony and a much larger reveal transaction. Ordinals inscriptions are the well known example of this family, and they are documented elsewhere in the Bitcoin Universe estate.

Unprunable outputs, the Stamps approach

Bitcoin Stamps (SRC-20) takes the deliberately opposite position: encode data into outputs that a node cannot discard, historically by splitting the data across fabricated public keys in a bare multisig output. The stated goal is that the data cannot be pruned away even in principle, because it sits in the UTXO set. That is a real property, and it is bought by imposing a lasting cost on every node, plus a dust value per output. Stamps originated outside this organisation.

Pitfalls

• Sending value to the data output. Those satoshis are gone. Always set the value to zero.
• Two data outputs. OP-20 rejects a transaction that carries two OP-20 payloads, and OP Names marks any transaction with more than one OP_RETURN as ambiguous_op_return and applies nothing.
• Assuming the payload proves ownership. It does not. It names an intent. The receipt output decides who owns the result.
• Assuming an indexer saw it. A valid payload that no indexer replayed is invisible to every product. Confirmation on chain and visibility in an application are separate events.
• Spending an asset bearing UTXO as fee change. Protocol assets on this carrier ride ordinary looking outputs. Wallets that do not screen their coin selection will destroy them. See funding safety.