TL;DR: The standardness limit on OP_RETURN outputs was lifted by default because it did more harm than good.
Disclaimer: I am the author of the proposal to lift this policy limit.
The OP_RETURN policy limit was introduced as a nudge to rate limit the amount of arbitrary data published onchain. By tolerating some small amount of arbitrary data publication (up to 80 bytes) through the public relay network, it would incentivize developers of applications wishing to publish arbitrary data to adapt their software to these limits rather than building alternative ways to reach miners.
This limit became obsolete when users started exploiting the witness discount to store arbitrary data in transaction witnesses. This method is called “inscriptions” and allows to store close to 400kb of data (i.e. 5000x more data than standard OP_RETURN outputs). These “inscriptions” created a trend and quickly became the main driver of block space demand, generating hundreds of millions of dollars in mining fees.
Meanwhile, infrastructure was being built to make it easier to bypass the public relay network and therefore Bitcoin Core’s relay policy. APIs to submit transactions directly to miners, alternative peer-to-peer networks with looser relay policy restrictions, and a broad interest from users and developers to build these alternatives. Therefore while the OP_RETURN limit in particular was made obsolete by inscriptions, nudging with paternalistic policy limits in general was made less effective as an application developers now has access to many alternatives to access the block chain.
A good example of this dynamic is the recent “sub 1sat/vb summer” trend. Bitcoin Core has for a decade only ever relayed transactions paying a feerate of at least 1sat/vb. This was one of the most well-known and accepted relay policy limit. During the summer of 2025 a number of users, developers and miners “memed” themselves into bypassing this limit. Very quickly, close to half of all transactions included in the block chain were transactions that no version of Bitcoin Core would relay by default. This just goes to show how fragile policy limits really are, and that they are unsuitable to counteract what gets included in the block chain.
While the OP_RETURN policy limit was obsoleted by inscriptions, and while relay policy limits are anyways unsuitable for counteracting how block space gets used, they did do something. By definition, the OP_RETURN limit prevents leveraging the peer-to-peer transaction relay network. Using this network, while not necessary to get access to block space, still has value. It is to this day the best way to ensure fast and robust propagation to the majority of miners. This is an essential property for second-layer protocols (like the Lightning Network), whose security relies on being able to get a transaction confirmed in a timely manner.
If it was the case that some application wished to store arbitrary data in non-witness parts of a Bitcoin transaction while still benefiting from the properties of the peer-to-peer transaction relay network, the OP_RETURN policy limit would actually be counterproductive! It would create an incentive for such users to masquerade the data they want to publish as real, spendable, transaction outputs. This way they can still publish the data in non-witness parts of the transactions AND they can still benefit from the properties peer-to-peer transaction relay network. A relay policy that creates perverse incentives is terrible: this is the polar opposite to what it is supposed to be doing! The OP_RETURN policy limit was not serving its intended purpose anymore, yet it was created perverse incentives. From a principled standpoint, it had to be lifted.
It is the case that some application wished to store arbitrary data in non-witness parts of a Bitcoin transaction while still benefiting from the properties of the peer-to-peer transaction relay network. The Citrea bridge is an example of that. And guess what, they started masquerading the data they wanted to publish as spendable outputs! This provided further evidence that the OP_RETURN policy limit was now a liability and was the trigger for my proposal.
The OP_RETURN policy limit did more harm than good and that is why it was proposed to be lifted, and the proposal accepted.
Doesn’t uncapping by default increase the bandwidth and storage burden on every full node?
No. The storage burden is bounded by the consensus limit on the block size. The bandwidth burden on a node depends on usage patterns on the network. For instance if it was common to use OP_RETURN outputs larger than 80 bytes and you kept this policy limit on your own node (with the -datacarriersize option in Bitcoin Core), it could possibly increase the bandwidth burden of your node. Therefore lifting the limit in this case would reduce your bandwidth burden. But i don’t think this will happen, and i think bandwidth usage will be unaffected.
Doesn’t uncapping by default create potential legal risks for operators forced to store arbitrary or illicit data.
No. There may be risk associated with a Bitcoin node, because you cannot prevent the storage of arbitrary data. These risks are not materially affected by this change, if only because for anything that can be stored in a 100KB OP_RETURN output, something 4x bigger (and therefore potentially more harmful) can already be stored in a 400KB inscription. It would use a different encoding, but this has no bearing on the legality of the stored content. It’s also the case that someone malicious willing to store nefarious content in a large OP_RETURN specifically (for some reason) can already do so today at minimal cost. Again, relay policy are not suitable to counteract how block space gets used.
Doesn’t risk mission drift by encouraging non-monetary use of Bitcoin’s scarce block space?
This change does not encourage non-monetary use of Bitcoin. Users wishing to use Bitcoin to store arbitrary data can already use inscriptions that are 4x cheaper to use for the same amount of data, and also allow to store up to 4x the amount of data.
For more about the implication of this change, please see this answer.
