Thanks for creating the topic @ABLA!
We’re multiple years from an “industry standard” ZKP
Just to give an update on that March 2021 comment about an “OP_CHECKZKP”: I still think we’re multiple years away from a widely-accepted, “industry standard” zero-knowledge proof construction (theory + implementation + message formats) in the way that e.g. our signatures follow a widely-accepted standard.
In fact, for years we’ve seen a consistent stream of relevant advances; consensus systems rapidly become outdated/sub-optimal, requiring adopting networks to carefully develop further upgrades + migrations (e.g. Zcash’s ZIP 224: Orchard Shielded Protocol).
In my opinion, Bitcoin Cash’s protocol should be as timeless as possible – if something can be done using contracts rather than new consensus upgrades, it should be.
Permissionless innovation: ZKP contracts
Fortunately, Bitcoin Cash is uniquely positioned to enable permissionless experimentation with zero-knowledge proofs at the contract level. Other popular networks – BTC, ETH, SOL, ADA, etc. – have architectural limitations that preclude following us this way (without significant upgrades to make them more like BCH).
Ideally, I’d like to see ZKP and similar privacy systems first developed and used on-chain as contracts to “shield” BCH and CashTokens. Full thread here (source of @ABLA’s screenshot).
I also wrote here a bit more about where the BCH VM stands in making these developments:
- possible (2023),
- easier (2025), and finally
- efficient – minimizing transaction sizes (2026?)
Since May 2023, Bitcoin Cash contracts have been able to implement: zk-SNARKs, STARKs, BLS signatures, Lamport signatures & hash-based signature schemes, post-quantum cryptography, verifiable delay functions, bulletproofs, ring signatures, confidential transactions (within covenants), homomorphic encryption, multi-party computation, and any other cryptosystem being implemented on or in any other cryptocurrency.
(Note these were also possible on Bitcoin Cash in 2009, but they were broken by the 2010 emergency anti-DoS patches.)
Bitcoin Cash’s May 2023 upgrade allowed computations to be split across inputs and/or transactions, so even without further upgrades, it is already possible to perform any kind of computation within Bitcoin Cash contracts. In practice though, important use cases require KBs or MBs of transactions to incrementally complete a computation, presenting a practical barrier to development and deployment.
After the 2025 BCH upgrade, many constructions that would have ballooned transaction sizes by KBs or MBs will now require only a few bytes: larger stack items and bigint arithmetic bring down these transaction sizes by 10-100x. Technically only a quantitative improvement, but significant enough to feel qualitative.
So for the record, BCH has been computationally universal since May 2023, the 2025 upgrade just makes things more efficient: smaller transactions, lower fees, and simplified development/security audits.
For comparison, I’ll note again that these constructions have also been possible on ETH since it’s inception (but with higher fees), and BTC since the Taproot Schnorr hack (but with KBs or MBs of waste in transaction sizes vs BCH).
Continued:
[2025], easier rather than a new capability.
BCH and ETH have been computationally equivalent since 2023: it’s possible (but absurdly inefficient) to emulate each VM on the other. So we’re down to comparing the relative byte-efficiency of various use cases.
BCH has always had the parallelization advantage over ETH (enabling far lower fees on BCH), and the 2025 upgrade pushes BCH significantly ahead on some financial arithmetic (ETH requires emulated precision in some otherwise-simple contracts), while other financial arithmetic cases are still very inefficient on BCH (without OP_POW and/or loops).
Most crypto arithmetic still favors ETH due to silly code factoring logistics: without loops and word/function definition, BCH contracts are forced to duplicate a lot of bytecode. E.g. a BCH contract should reasonably be able to specify the code for a batched modular inversion in <100 bytes (or much less), but currently contracts have to duplicate that code N times to execute it N times. BCH has a >1000x architectural advantage allowing for much lower fees, but code factoring can waste most of the difference for many use cases (and in practice, make it not worth the development/verification costs).
Hoping to have proposals out soon, but I think we can close the rest of the gaps by 2026 or 2027. I’m going to CHIP relaxing output standardness (“P2S: Pay-2-Script”) and re-propose loops (same 2021 OP_BEGIN/OP_UNTIL spec) + a function-calling strategy (OP_EVAL) for deduplicating large segments of repeated code (as loops are still not sufficient for minimizing all contract sizes).
2026 Proposals
And finally, those 2026 proposals:
Proposing three CHIPs for Bitcoin Cash’s 2026 upgrade: loops, function eval, and Pay to Script (P2S). These would make BCH contracts more efficient than ETH, SOL, etc. across some remaining gaps + optimize transaction sizes for zero-knowledge and post-quantum covenants. (1/6)
Loops were excluded from the VM as part of an initial, anti-DOS approach. The “no loops” approach was quietly abandoned for explicit limits in 2010, but Satoshi left a code comment that said “There are no loops” – and a generation of Bitcoin devs missed the context. (2/6)
“CHIP 2021-05 Loops” adds the well-established, OP_BEGIN/OP_UNTIL loop construction used by most Forth-like languages. The CHIP was ready-but-blocked on VM Limits since 2021. Finally unblocked by BCH’s 2025 upgrade, I’m re-proposing for activation in 2026. (3/6)
Function Evaluation (OP_EVAL) would let Bitcoin Cash contracts be efficiently factored into reusable functions. Optimizes contract sizes for finite field arithmetic, pairing-based crypto, ZKP systems, homomorphic encryption, post-quantum crypto, and many other applications. (4/6)
Pay to Script (P2S) improves wallet ecosystem safety, simplifies contract design, and reduces transaction sizes for vault, multi-party, and DeFi applications. (5/6)
The next branches of @libauth and @BitauthIDE now have draft support for OP_BEGIN/OP_UNTIL, OP_EVAL, and P2S. You’ll see a some new UI for stepping through loops in the IDE too: (recording from locally-installed app, offline mode! 
)
Screen recording of UI 
Getting to ZKP addresses
Of these, I would say OP_EVAL is the most critical for optimizing the efficiency of ZKP contracts, but P2S and loops would each make development easier in important ways (see those links).
If those 2026 proposals are activated, we’ll be in a good position to rapidly implement new ZKP systems as they are discovered/invented.
While other blockchain networks have to “bet the whole network” on new ZKP upgrades, BCH builders can permissionlessly ship new ideas with negligible funds at stake.
Once our tooling is good enough, I hope we’ll even see various university and industry teams choosing BCH as a target environment to demo in new whitepapers. 
Opcodes? Maybe eventually
Once one or more ZKP covenant systems are widely used on-chain, it will always be possible to optimize them by extracting common constructions (modular exponentiation? specific fast fourier transforms?) into network-standardized opcodes.
These sorts of byte-saving opcode upgrades would be particularly straightforward too – chain analysis will tell us approximately how many bytes we can expect each upgrade to save based on real word usage, and we can simply weigh the complexity vs. storage/bandwidth saved.
And of course, if one ZKP construction becomes very widely-standardized, dominating the industry and gaining significant trust over multiple years, that would be a good candidate for an “OP_CHECKZKP”.
