The current OP_RETURN length limit on Bitcoin Cash (BCH) is far too restrictive for practical applications. If we aim to build social media posts or encrypted email services directly on the BCH blockchain, the existing 223-byte limit is clearly insufficient for daily functional use; I believe it should be at least 1KB to be truly viable. However, reaching a 100KB limit like Bitcoin’s is excessive, as it would likely flood the network with a massive amount of redundant and low-value data. My personal proposal is to adjust the OP_RETURN ceiling to approximately 5KB. This capacity would be just enough to host a complete article or a long-form email, striking an ideal balance between functionality and network efficiency.
As someone who is not a technical expert, I have an additional suggestion: I hope to see BCH wallets like Electron Cash integrate a built-in encrypted email feature, allowing users to engage in encrypted chats with others directly within the wallet. This would enable social media functionality while ensuring the user remains in total control of their private keys.
I’d push back on the core premise here. Blockchain is a settlement layer, not a content database. Storing full articles in OP_RETURN means every node carries that data forever, for no transactional benefit. The right pattern is that content should be off-chain, hash on-chain, you get the same guarantees without bloat.
We already have real-world examples of what happens when you go down this road. BSV removed OP_RETURN limits entirely and the result is a 3+ TB blockchain where 95%+ of transactions are non-financial data storage (a weather app was famously the dominant use case). Node requirements ballooned to 64GB RAM minimum, killing any hope of grassroots decentralization. BTC is now heading in a similar direction with Core v30 raising the OP_RETURN limit to ~100KB, which has already sparked a major backlash and migration to Bitcoin Knots. These aren’t success stories to emulate.
And before someone says “just prune”, pruning only helps with long-term disk usage. Every node still has to download, validate, and propagate every byte of that data on first sync and in real time. Pruning doesn’t reduce bandwidth, propagation latency, or mempool pressure. It also means pruned nodes can’t serve block history to new peers, so the full burden just concentrates onto fewer archival nodes, which is the opposite of decentralization.
Nostr is a great example where BCH community can build on, for example we can use NIP-59 (gift-wrapped encrypted messages) for encrypted messaging. It already does exactly what you’re describing, with stronger metadata protection than anything on-chain could offer. The sender is hidden behind a disposable keypair, timestamps are randomized, and messages are deniable. This is already being used in BCH-related projects. No need to cram it into a wallet when a purpose-built protocol does it better.
It’s also worth noting that BCH 223-byte OP_RETURN limit is kept intentionally. When @bitjson designed the VM Limits and CashVM upgrades, he explicitly left OP_RETURN data carrier limits untouched. The upgrades focus on computation (loops, functions, BigInt, ZK proof verification), not on turning BCH into a data storage chain. That’s a deliberate architectural decision, not an oversight.
Vox Channels use CashToken NFT data commitments to store data, then burns the NFT UTXOs for future coupons after a week.
There have been lots of long (<10kb) posts on vox. There was a 17k+ word book published on there in early Feb, late Jan.
Posts are the concatenated data across all NFTs in a transaction.
The current NFT commitment length is 40 bytes, but it’s increasing to 128 bytes in May '26.
Unlike OP_RETURN outputs, which is a cap on the data per transaction, by using CashTokens, the total limit for data is only limited by total transaction size. In May 26, the ratio of data that can be on NFTs will increase, because it can be written across fewer outputs.
Another strong advantage of using NFTs is that you can eliminate the need for a bespoke indexer from your app. If you have the data stored on contracts, you can just use any indexer that allows finding a balance or history of an address.
This is a simple example:
In the interest of the network, it is courteous to build a mechanism to clear storage utxos from the active unspent transaction set. You want to allow miners to spend old data, so that they don’t have to keep it in ram, but you could still look it up from a full index.
If you don’t want to cleanup old utxos, there is a ~800 sat minimum for NFT outputs.
The HUGE advantage of NFT commitments over dead-end OP_RETURNs is that the data can be programed to do stuff, and the data has some value associated with it to facilitate that stuff. If you can have people spend data that has money, the range of possibilities are infinitely more than a simple read only output.
In the case of the database and social contract above, the data is funding network maintainers and a market on future bitcoin cash.
Bitcoin Cash is permissionless.
If you pay the network fee and meet relay rules, then what you wanted to do was allowed.
Intelligence agencies collect aggregate encrypted data for a time when that data will become decryptable. If private messages get stored on chain, we’ve done their work for them.
What is considered “private” today, could have its encryption broken in the future.
There are a number of people building Nostr messaging and social media apps like ABLA suggested. For data that is and should remain private, using off chain transport is better, although a lot of the internet goes through chokepoints to collect everything anyway.
It has to download, validate, and propagate every byte of every block, anyway. Placing dumb data in an OP_RETURN actually saves node the work, when compared with other places one could stuff dumb data in.
IMO we should just set the per-output OP_RETURN limit to same value as input script: currently MAX_TX_IN_SCRIPT_SIG_SIZE = 1650, and do away with the aggregate per-transaction limit.
This way, dumb data won’t have incentive to create overheads for the network in dumy UTXOs and inputs.
The RAM is used to store the UTXO set, whereas OP_RETURN data does not impact memory; it is stored on the hard drive, which is inexpensive. A blockchain should not be used exclusively for payments; it ought to support diverse applications, and the current OP_RETURN limit significantly restricts these possibilities. Furthermore, there is no need to be as aggressive as BSV. Adjusting the OP_RETURN limit to a few kilobytes would not severely interfere with normal transactions, yet it would be highly beneficial for the blockchain’s ecosystem.
What about storing it off chain? Which was the original suggestion of the guy you replied to. Not sure if you read that as your answer doesn’t take that option into account.
It should be used for financial data, because THAT is the only thing that benefits the chain and thus the value of the network.
If you want people to do work, processing cycles and share drive space for your usage, you have to make it worth their while.
The way to make it worth people’s time disk and CPU is to make the bytes represent economic activity because that makes the price of the coin go up.
Comments on a social network decrease the price and take away value from the network. So if you push that, you are going against the benefits of the people RUNNING the network.
You should run your own network if you want to store data that doesn’t benefit anyone other than you and your friends.
Sure, we should encourage that, but IMO min. fee is enough to deter irrational use. If someone wants to pay 1000 sats to send a 100-word “e-mail”, isn’t that a financial transaction? Someone is paying 1000 sats to deliver a message.
Even now, nothing prevents people from just chaining input’s unlocking data as storage, they can store 1650 bytes per input rather than be limited by 223 bytes / TX in the OP_RETURN.
Sure, they may pay a little more in overheads, but the network will pay more, too: it has to push/pop from UTXO DB. As opposed to OP_RETURN which requires 0 UTXO DB operations.
This is not what people mean when they use the term “economic activity”.
What you see is the user paying a lucky miner some fee, but that doesn’t help anyone but the miner. While everyone in the ecosystem is actually processing the transaction. You see how that doesn’t match? One payment to one player while hundreds need to do work to process that.
No, an economic transaction is based on austrian economics ideas that two people making a voluntary trade benefits both and raises the wealth in the world. This paying being done in bitcoin cash means that the new wealth is represented in bitcoin cash too. And thus the value of the coin just went up. Or, less abstract, actual economic trades in bitcoin cash is utility and people will want to buy bitcoin cash for that purpose. The MEASURE of how much is based on the value of what is traded. Trading a $1 thing isn’t raising the value much, paying for a $50000 car substantially more so.
So what economic activity means is that the entire ecosystem benefits from this transaction, because it raises utility and it raises the value of the coin. Which raises the net worth of all holders.
Whereas your payment of fees was just a tiny amount paying one miner to secure the chain.
Those things are not the same.
So, the important part here is that Bitcoin Cash, as a platform and as a chain, is made for economic activity. People might even make transactions for free (no fee) and it will stil benefit the chain. Which is why we today have the very low fee of 1sat to make it more attractive to normal people to use without really paying the miners. Because we bet on the majority of those being economic transactions which raises the price.
The idea that “paying the fee” is economic activity is completely missing the point of what people use the term economic activity for.
It is a peer-to-peer electronic cash system, not a data storage system. Long-term success and network security rely on Giga volumes of P2P transactions, merchant adoption, and DeFi activity with ultra-low fees, rather than a few hundred companies paying ultra-high fees to store data on-chain. Why make it easy for them to store data on-chain anyway? The limit is sufficient to store hashes and provide the same guarantees. We must remember our roots. What differentiates us from BTC is our commitment to being functional money for everyone.
