verifier.cash
← back

Why does it even matter?

Bitcoin Cash is usually described as money: payments, and lately tokens. But a chain that can verify a cryptographic proof on its own, with no trusted operator, can do far more than move balances. A verifier is the on-chain half of any system whose heavy work happens off-chain: do the expensive computation elsewhere, post a short proof, and let the chain check it cheaply. That one primitive is what powers privacy, scaling, and post-quantum security on other networks today, and a Groth16 verifier is the smallest complete example of it.

Privacy

A zero-knowledge proof lets a contract accept a spend as valid without revealing who is spending, how much, or which earlier deposit it came from. That is the basis for shielded transactions and privacy pools, the Tornado-Cash pattern: many users deposit into one pool, and each later withdraws to a fresh address by proving, in zero knowledge, that they own an unspent deposit without linking the two. On Bitcoin Cash this is just a covenant that verifies the proof on-chain: no mixing service, no custodian, no trusted operator.

Compression and settlement

A proof can attest that an entire batch of transactions, or a whole off-chain execution, was processed correctly, compressing thousands of operations into a single succinct on-chain check. Bitcoin Cash scales its own payments on layer one, so this is not about offloading throughput; it is about letting other systems settle to BCH trustlessly. An application-specific chain, an alternative VM such as the EVM, or a system that makes different decentralization tradeoffs can post a validity proof, and BCH verifies it instead of re-running the work, so that system inherits BCH's settlement without anyone having to trust its operator.

Post-quantum security

Proof systems built only on hash functions (STARKs) stay secure even against a quantum computer, unlike pairing-based systems such as Groth16 itself. An on-chain verifier is what lets Bitcoin Cash support these constructions, from quantum-secure vaults like bitjson's Quantumroot to private, compressed post-quantum systems. A succinct, genuinely zero-knowledge, quantum-ready prover for one-off proofs under ~100 KB is still an open frontier, which is exactly the kind of thing an efficient on-chain verifier invites people to build.

And AI is unusually good at it

Writing this kind of code (finite-field arithmetic, pairing-based cryptography, and proof verifiers expressed in low-level VM bytecode) is painstaking and highly structured, and it is easy to check: a verifier either accepts the valid proof and rejects every tampered one, or it does not. That combination suits modern AI models well. They can grind through the algebra and the byte-level optimization while the harness verifies each step on-chain. In fact, every BCH-native verifier on this leaderboard was built with Claude. The same loop scales to larger targets: bitjson's open challenge to design a post-quantum, activity-aggregating STARK covenant for the 2026 CashVM is the kind of task that looks impractical by hand but increasingly tractable with an AI in the loop, and could be real and working soon.

A higher ceiling for on-chain programs

Just as important as any single application is what the 2026 upgrades did to CashScript itself. Bounded loops, big-integer arithmetic, and reusable user-defined functions make the language far more expressive: work that previously had to be hand-unrolled thousands of times can now be written once as a function and looped. That makes genuinely complex programs practical to write and audit, and this Groth16 verifier is a demonstration of exactly that, an advanced contract that would have been impractical to express before the upgrades.

It's already possible; this just shows how far it reaches

Covenants already make these systems expressible on Bitcoin Cash: zkVMs, Zcash- and Monero-style privacy, Mimblewimble, rollups. The 2026 upgrades (loops, reusable functions, P2S) are what made them practical rather than theoretical, and it shows: a complete BCH-native verifier already fits the per-input limits and runs on chain today. The chunking overhead against a singleton with comparable, minimized op-cost (~1.3× more bytes) is real but workable, so none of this waits on a further protocol change. Bitcoin Cash is now computationally universal and competitive with Ethereum on raw compute, with higher limits and lower fees.

That is why a Groth16 verifier's byte count is worth competing over. It is not really about one circuit. It is about proving out the primitive (trustless on-chain proof verification) that a whole class of privacy, scaling, and post-quantum applications stands on, and showing how far the upgraded language already reaches. Smaller verifiers make more of that practical, and further protocol upgrades could shrink them further, though they are not required: how could we solve this?