OP_RETURN

In June 2025, developers explained their rationalisation for removing the longstanding default OP_RETURN policy rule, stating that "Knowingly refusing to relay transactions that miners would include in blocks anyway forces users into alternate communication channels, undermining the above goals."

Those monitoring the situation were not surprised at this news, but given the default OP_RETURN policy had not changed in 10 years there were some who viewed this as a radical change in policy (many of whom are now promoting a controversial soft fork which will trigger regardless of miner support after a period of time).

This report puts the number and size of nonstandard OP_RETURN transactions into the appropriate context - in summary:

1. The overwhelming majority of recent OP_RETURNs are standard, and would be unaffected by BIP110.
2. The number of nonstandard OP_RETURNs is extremely low, and has not changed since the release of core v30.

To start, we plot the historic count of OP_RETURN outputs created per month, classifying into categories of standard and nonstandard. For the purpose of this report by nonstandard we refer to the pre-v30 policy rules. See later section on nonstandard breakdown for more information.

We see that there were three spikes in the number of OP_RETURNs during 2019, 2024 and 2025, of which ~all were standard.

There are two important observations:

1. The nonstandard OP_RETURN transactions are so rare in comparison to standard OP_RETURNs that they are not visible on the chart (except for in March 2024).
2. There was a decrease in the number of OP_RETURN outputs following the release of core v30.

If we plot the size (in Bytes) of the data in OP_RETURNs we see broadly the same picture.

The chart above measures only the data bytes after the OP_RETURN opcode (aka the payload). But each OP_RETURN payload is carried inside a full transaction that also includes inputs, signatures, and change outputs. This below chart compares the OP_RETURN payload bytes to the total virtual size (vbytes) of the transactions that carry them, showing the actual block space consumed.

We now plot only the nonstandard data, for the last 2 full years, we see that there were spikes in March 2024, May 2025 & August 2025, all well before the release of core v30.

Observing the corresponding data by bytes we see that this is dominated by the May 2025 spike.

nonstandardness Analysis

An Oversized OP_RETURN is nonstandard, but so too is a transaction which creates multiple OP_RETURNs. With the release of v30 policy defaults were changed to make both Oversized & Multiple OP_RETURN transactions standard.

We separate out these two categories in the following plot.

We see that the March 2024 & August 2025 spikes were caused by multiple OP_RETURNs per transaction, none of which individually were oversized.

The May 2025 spike however was primarily caused by oversized OP_RETURNs, some of which were also made in transactions with multiple OP_RETURNs per transaction.

Plotting by the amount of data we see that the 2024 spike was insignificant, with the vast majority of the data being created in May 2025 (prior to the core v30 release).

Finally, to visualise this data in another way, we show a histogram of the size of OP_RETURN bytes in the months preceding and following the release of bitcoin core v30.

OP_RETURN Protocols

Since OP_RETURN was introduced, dozens of protocols have used it to embed data in Bitcoin transactions. We classify each OP_RETURN to see how usage has changed over time, see the table at the end of the report for the approach used. Note any metric preceded by a ~ uses a heuristic, and may not be accurate.

When viewing by count we see that the 2019 wave was predominantly omni & veriblock, whereas the 2024 & 2025 waves were almost exclusively runes.

Next we plot the amount of data embedded with each OP_RETURN protocol

We see that veriblock was responsible for most of the 2019 wave (note, later instances of veriblock are likely other protocols which happened to have the same number of bytes as a veriblock OP_RETURN).

For completeness we include plots of the data since 2024.

We aggregate the all time data in the following pie charts

Summary

It is clear that the number of OP_RETURN transactions in recent years has risen rapidly, in two waves, the latter of which appears to be subsiding having peaked around the release of v30.

The vast majority of OP_RETURNs are standard. The number of nonstandard OP_RETURNs has not increased since the release of bitcoin core v30 (which changed the longstanding OP_RETURN standardness rules relating to size & count per transaction). In fact, the release followed a massive number of such nonstandard transactions being mined, which aligns with the rationalisation given by the bitcoin core developers prior to release.

Almost all OP_RETURN transactions in recent years have been associated with the Runes protocol and were standard under the pre v30 rules. These transactions would even remain standard under BIP110 (which purports to reduce data embedding).

The recent waves of Runes transactions are not without historic precedent, we see that the 2019 wave of veriblock transactions was similar in scale.

OP_RETURN Protocol Categorisation Details

~ prefix indicates heuristic detection (not a definitive protocol identifier).