Null data transaction

People wanted to write things into the blockchain long before there was a safe way to do it. The safe way is an output beginning with OP_RETURN, which fails immediately if anyone tries to spend it, so full nodes can drop it from memory rather than tracking it forever. Almost all such outputs hold zero satoshis, and the sender pays only for the bytes.

How it works

A null data output is a locking script that can never be satisfied, which is precisely the point.

The script starts with the OP_RETURN opcode and is followed by a data push. Because the opcode aborts the script the moment it is reached, no combination of signatures can unlock the output, and nodes are free to leave it out of the unspent output set they hold in memory. That set is the expensive thing a full node maintains, and keeping junk out of it is the entire justification for the feature.

Bitcoin Core made a single such output standard in version 0.9.0, released in March 2014, with a payload capped at 40 bytes. The cap rose to 80 bytes of data during 2015, which the node counts as 83 bytes of script once the opcode and push prefix are included. Version 30.0, released in October 2025, removed the default limit and the one output per transaction restriction, after a long and bad tempered argument about whether relay policy should be trying to discourage data storage at all. Bitcoin Knots kept the stricter defaults, so the two most used node implementations now disagree on purpose, and a node operator picks a side by choosing software.

The change is a policy change, not a consensus change. Data in an OP_RETURN output has always been valid; the argument was only ever about whether ordinary nodes should pass it along.

Where you see it

Look at any block on an explorer and you will find null data outputs listed with a value of zero and a script rendered as OP_RETURN followed by hex.

The oldest heavy user is Omni Layer, the protocol that issued the first version of Tether on bitcoin, which encoded its instructions this way. Timestamping services such as OpenTimestamps commit a hash of a document into an output, so you can later prove the document existed before that block. Runes, the token protocol that launched at the halving block on April 20, 2024, puts its entire instruction set into a single null data output, which is why that block and the ones after it were full of them.

For someone buying bitcoin, the practical effect is indirect but real. Data outputs compete for the same block space as your payment, and a burst of them raises the fee rate you have to pay to confirm. That is the mechanism behind most of the fee spikes of the last few years.

Null data transaction vs OP_RETURN

OP_RETURN is one opcode; a null data transaction is a whole transaction that happens to contain an output using it. The distinction matters when reading node configuration, because Bitcoin Core's settings are named after the transaction category rather than the opcode: -datacarrier decides whether such transactions are relayed at all, and -datacarriersize sets how large the payload may be. Searching documentation for OP_RETURN will not find those options.

Null data transaction vs inscription

Inscriptions put their data somewhere else entirely. An ordinal inscription hides its payload inside a taproot witness script, which receives the SegWit weight discount and can run to megabytes, while a null data output is charged at full weight and was historically capped at 80 bytes. That difference in price and size explains why images and collectibles arrived as inscriptions rather than as OP_RETURN data, and why the two provoke very different arguments about blockchain bloat.