OP_RETURN

OP_RETURN is a locking script that can never be unlocked. It starts with the OP_RETURN opcode, which ends the script at once and marks it invalid. Data pushes follow it. Because the output can never be spent, its only job is to carry data. Anyone can create one, and nodes do not need to keep it in the UTXO set, since no later transaction can use it.

Putting data on chain is debated. OP_RETURN was added to stop data from sitting in outputs that look spendable, and that is still its main purpose.

What does an OP_RETURN output look like?

The output's locking script is 13 bytes:

6a0b68656c6c6f20776f726c64

6a is OP_RETURN, and 0b pushes the next 11 bytes. Those bytes spell hello world. Output 2 of 6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75 uses this script.

The data can be any bytes. Text is common, but nothing requires it.

What are the rules for an OP_RETURN output?

• The script can contain only OP_RETURN followed by data pushes. The opcodes OP_1 to OP_16 count as pushes too.
• Use a value of 0 satoshis. Nodes accept any value, but satoshis on an OP_RETURN output are lost for good, since nobody can spend the output.

Can you spend an OP_RETURN output?

No. The lock can never open, so an OP_RETURN output has no unlocking script. It can never be used as an input in a later transaction.

How much data can an OP_RETURN output hold?

The limit depends on the version of Bitcoin Core that a node runs, and it has changed several times.

• v0.9.0 (March 2014): one data push of up to 40 bytes, and one OP_RETURN output per transaction. The 0.9.0 release notes describe it.
• v0.11.0 (2015): one data push of up to 80 bytes.
• v0.12.0 (2016): several data pushes, with the whole script limited to 83 bytes.
• v30.0 (October 2025): the default -datacarriersize rose to 100,000 bytes. That effectively removes the cap, because the standard transaction size limit is reached first. The limit applies to all OP_RETURN outputs in a transaction together, and several OP_RETURN outputs are now permitted. Setting -datacarriersize=83 restores the older limit. The 30.0 release notes give the details.

These are policy settings. Each node decides what it relays, so a transaction above one node's limit may still reach a miner who accepts it.

How do you push more than 75 bytes?

A one-byte push opcode, OP_PUSHBYTES_X, can carry at most 75 bytes. For 76 to 255 bytes, use OP_PUSHDATA1 (4c), which is followed by a one-byte length. For 80 bytes, the start of the script is 6a 4c 50, where 50 is 80 in hex, followed by the 80 bytes of data. OP_PUSHDATA2 (4d) takes a two-byte length, in little-endian order, for 256 to 65,535 bytes.

Which OP_RETURN outputs can you check on our explorer?

• Output 2 of 6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75 holds hello world.
• Output 0 of 8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684 holds charley loves heidi, in 19 bytes.
• Output 2 of 2cf4f1ab0df25610231a0f4fb7e1e18720a6c555f102b75bb115e99b1ad41241 holds Amazing!.
• Output 1 of b33c1252ddc2fdb5396c7dc3ceed3749c587e3310c6df2f3605a38cc3c129e1f holds First OPReturn Message I was here :), in 36 bytes.
• Output 1 of 9aa48ce6b9045d5cd29398272502325255d731ddb97dc207f30d14f35628ed08 has a 15-byte push and then the number opcodes OP_1 to OP_4, which count as pushes too.
• Output 1 of the coinbase transaction 2d4cdcd29d0004c762790b579bc2541da788f042031fa87fc27e402244080394 is a 36-byte push that starts aa21a9ed. That is the wTXID commitment added by SegWit. It is not text.

To find OP_RETURN outputs in a transaction, look for a script that starts with 6a. Most of them have a value of 0 satoshis.

Why does OP_RETURN exist?

Before version 0.9.0, people stored data inside outputs that looked spendable. A text string could sit where a public key hash goes in a P2PKH lock. That worked, but a node could not tell that the output was unspendable. It would keep the output in the UTXO set forever, which uses up memory.

OP_RETURN fixes this. The output is provably unspendable, so nodes can leave it out of the UTXO set. The change does not endorse storing data on chain. It keeps the data out of the outputs that nodes must track.

Does an OP_RETURN always make a script fail?

No. The script fails only when OP_RETURN runs. The redeem script OP_IF OP_1 OP_ELSE OP_RETURN OP_ENDIF has an OP_RETURN in its OP_ELSE branch, which never runs when the spend pushes OP_1. The script is valid, and it leaves one OP_1 behind. Input 0 of 890d3814c2bc2516ff8e061d7a4580116459f4f693f2783d11a5fbb4b3597ac2 shows this inside a P2SH lock.

For the other script types, see the script overview.