Bitcoin OP_RETURN Explained: Data Carriers, Nulldata, and Unspendable Outputs

A Bitcoin transaction output contains a value and a locking script called scriptPubKey. An OP_RETURN, often classified as nulldata, is a script that begins with the OP_RETURN opcode and may then push a short byte string. The bytes are part of the transaction output itself, so they are recorded publicly when the transaction is included in a block. A simple schematic is OP_RETURN <pushed data>; the angle-bracket phrase is explanatory, not literal Bitcoin Script syntax.

The pattern can carry a commitment, a protocol marker, or other application-specific bytes. It does not create a separate data layer, token balance, or private message. A parser may recognize a particular format, while a normal Bitcoin node only applies its transaction and script rules. The bytes are visible to people and software that can inspect the transaction, so never place a secret, password, or personal information there.

OP_RETURN is an opcode that fails if execution reaches it. A transaction that tried to spend an output whose locking script starts with this opcode could not satisfy that script. Bitcoin Core therefore classifies such a script as unspendable. Its CScript::IsUnspendable() check explicitly tests whether the first byte is OP_RETURN, and Core can omit the output from its UTXO set immediately rather than keeping a coin that can never be spent.

“Unspendable” describes the output, not the transaction that created it. A transaction can still contain an OP_RETURN output and be valid under consensus rules. Nodes also apply local policy when deciding whether to relay a transaction into their mempool. Those two decisions answer different questions: consensus checks whether a block and its transactions are valid; standardness policy determines what a node is willing to relay or mine under its local settings. See Bitcoin Core 31.1's script.h and transaction checks.

The byte limit on a data carrier, when a node applies one, is not the same as the number of bytes of application data. A raw output script includes the OP_RETURN opcode, the push instruction and its length encoding, and the payload. For a payload longer than 75 bytes, the push encoding itself takes extra bytes. That is why the often-cited historical limit of 80 payload bytes was associated with an 83-byte script: one OP_RETURN byte, a two-byte OP_PUSHDATA1 header for an 80-byte push, and the 80 payload bytes.

This distinction helps when reading old wallet instructions. “80 bytes” can refer to payload in an older policy example, while newer Bitcoin Core configuration describes a limit on complete raw scriptPubKey sizes. A commitment may also be shorter than the script cap because a transaction has other outputs, inputs, and witness data. Measure the serialized script and the entire transaction rather than assuming that a headline payload number is the accepted size.

In Bitcoin Core 31.1, -datacarrier defaults to enabled. The -datacarriersize default is 100,000 bytes, and its help text defines the measured quantity as the aggregate size of raw data-carrying scriptPubKeys, allowing multiple outputs. IsStandardTx() subtracts the complete script size of each output classified as NULL_DATA from that transaction's remaining allowance. It does not count only the data bytes after OP_RETURN. These version-pinned defaults are documented in Core's init.cpp, policy.h, and policy.cpp.

The change arrived in Bitcoin Core 30.0: the default data-carrier allowance rose from the earlier 83-byte script-size limit to 100,000 aggregate raw script bytes, and standard transactions could use multiple data outputs. Core 31.1 retains that policy. An operator can configure a smaller threshold, including -datacarriersize=83 for a familiar older limit, but that setting does not restore every older behavior because multiple outputs remain part of the newer policy. The release notes explain this change in detail.

Every node can choose whether it relays standard data-carrier transactions and what local data-carrier size it accepts. A node started with -datacarrier=0, a lower size threshold, or another software version may reject a transaction from its mempool even when another node accepts it. A rejection can therefore mean “this node's policy declined to relay it,” not “the transaction is forbidden by Bitcoin consensus.” Relay is not guaranteed network-wide.

Consensus rules are checked when a node validates a block. Bitcoin Core's basic transaction checks enforce conditions such as nonnegative output values and transaction size against consensus limits; the policy-only IsStandardTx() test separately applies the data-carrier allowance before mempool acceptance. A miner may include a nonstandard transaction if it chooses to, provided the transaction and block satisfy consensus. Fully validating nodes can then accept that valid block without having relayed the transaction first. This does not promise that miners will include it or that nodes will store or forward it. See Bitcoin Core 31.1 mempool standardness implementation.

An OP_RETURN output can have a value, but because no valid spend can recover it, that value is permanently unspendable. Wallets commonly use zero value for a data output. If a transaction assigns 1,000 sats to the output, those sats are destroyed; they are not automatically added to the miner fee. The transaction fee is the sum of input values minus the sum of all output values. For example, with 10,000 sats in inputs and outputs totaling 9,000 sats, the fee is 1,000 sats whether the output values include a spendable payment, a zero-value data carrier, or a 1,000-sat unspendable output.

Data still occupies transaction space and therefore contributes to weight and virtual size under BIP 141. The output's script bytes can increase the fee required at a chosen sat/vB rate, even when its value is zero. If value is placed in an unspendable output, that is an additional loss on top of whatever fee the transaction pays. The Bitcoin transaction-fee guide explains how size and fee rate relate.

Bitcoin Core 31.1 permits multiple standard NULL_DATA outputs, but their raw script sizes share one transaction-level allowance. Splitting a payload into several outputs therefore does not multiply the default size limit. Every additional output also adds transaction data, which uses block weight and may increase the fee. Each output begins with OP_RETURN and is itself unspendable; it does not become a sequence of recoverable storage fragments.

The local threshold is only one acceptance condition. A transaction must also fit standard transaction weight and satisfy other standardness and fee policies at a node. A different node or miner can use different settings. Do not interpret a successful wallet preview, one explorer's relay, or one node's mempool acceptance as a guarantee that the same bytes will propagate everywhere.

OP_RETURN data appears in an output's scriptPubKey when the transaction is created. SegWit witness data is serialized separately for each input; BIP 141 says that the witness fields are per-input stack data and are not themselves Script. Taproot script-path spending can reveal a script and control block in the input witness, as BIP 341 describes. Ordinals software can interpret a conventionally formatted envelope in that revealed script as an inscription, but that application-layer interpretation is not the same mechanism as a nulldata output.

The distinction is practical: the OP_RETURN output cannot be spent again and Core can omit it from the UTXO set, while a witness inscription is part of an input's witness data in a spending transaction. Both are public transaction data and both use finite block weight, but their locations, validation paths, and application conventions differ. For the separate sat-numbering and witness-inscription model, see [Bitcoin Ordinals and inscriptions](/learn/bitcoin-ordinals-inscriptions-satoshi-numbering-witness-data-explained).

Before constructing a transaction, identify the Bitcoin Core version and local settings whose behavior you are relying on. Confirm whether the receiver or service expects a specific data format; consensus does not assign meaning to arbitrary payload bytes. Calculate the serialized output script size, the transaction's overall weight, the value assigned to the unspendable output, and the miner fee as separate quantities. If broad relay matters, remember that each node and miner may set its own policy.

Treat any data written to the blockchain as public and durable in archival copies. Some nodes prune old block files after validating them, but pruning changes local storage rather than erasing a transaction from the chain's history. OP_RETURN is not a private note, a recoverable file system, or a substitute for a wallet backup. For the value model underlying transaction outputs and change, review Bitcoin UTXOs and coin control; for how witness inscriptions use another part of a transaction, review the Ordinals guide linked above.