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.
