Why on-chain verifiers matter

Bitcoin Cash is usually described as money: payments, and lately tokens. A chain that can check a cryptographic proof on its own, with no trusted operator, can do 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. On other networks this one building block already supports privacy pools, rollups, bridges and identity checks. A Groth16 verifier (code that checks one widely used, compact proof format) is the smallest complete example of it.

What that costs on Bitcoin Cash today, as we measured it on a node:

• A Groth16 verifier from the leaderboard (one that passed our soundness review): about 27.6 KB in one standard transaction, roughly 28,000 sats in fees, checked by a node in about 3.5 ms.
• PLONK (a proof format that reuses one existing public setup instead of needing a new one per app): 83–90 KB in one standard transaction, about 11 ms. Research; see other proof systems.
• A post-quantum STARK private spend: 99 KB in one standard transaction, about 17 ms. Research.

The sections below go through the main places where other chains verify proofs in a contract today, and what each could mean for BCH.

Privacy

In a shielded pool, many users deposit into one contract. Later, each user withdraws to a fresh address with a zero-knowledge proof that says “I own one of the unspent deposits” without revealing which one. A nullifier (a one-time tag) stops the same deposit from being withdrawn twice. A contract checks the proof on every withdrawal.

The largest deployments are on Ethereum. Tornado Cash holds about $738M, and Railgun, a shielded token ledger, uses the same approach. Both check Groth16 proofs in a verifier contract: the same kind of verifier this leaderboard ranks. Zcash builds the same idea into its protocol; its shielded pools hold roughly 29% of supply.

On BCH, a shielded pool is a covenant (a contract that constrains how its coins are spent) that verifies the proof itself, with no mixing service and no custodian. The Groth16 verifier measured above fits in one standard transaction. Toorik’s ShieldKit already runs Groth16 shielded pools on Chipnet, BCH’s test network, built on a verifier from this leaderboard (a research beta; that verifier has since been withdrawn). Our own post-quantum pool accepts batched deposits and rejects double spends on a local test node. Research only.

Status: deployed elsewhere; built here as research.

ZK rollups and settlement

A rollup runs transactions off chain and posts a summary to a base chain. In a ZK rollup, every update must come with a validity proof that the batch was processed correctly, and a contract on the base chain checks it. Unlike optimistic rollups, withdrawals need no multi-day challenge window.

On Ethereum, the largest ZK rollups (Starknet, Linea and ZKsync Era) each secure a few hundred million dollars, though usage is modest.

BCH scales its own payments on layer one, so the point is not offloading BCH’s throughput. The point is letting other systems settle to BCH: an app chain or an EVM chain posts a proof and BCH checks it instead of re-running the work. Our PLONK verifier uses the same public ceremony as ZKsync’s and SP1’s PLONK verifiers, so a developer can bring a new circuit without running a ceremony. We have not tested it on those projects’ own proofs. For how this compares with Bitcoin’s BitVM approach, see rollups: BCH vs BitVM.

Status: deployed elsewhere; verifiers built here as research; no rollup settles to BCH.

Bridges and light clients

A bridge contract on chain B checks a proof that chain A’s consensus finalized a given block. Deposits on chain A can then be released on chain B without trusting a multisig. General-purpose zkVMs (provers for ordinary programs) such as SP1 and RISC Zero make this practical, and their shared verifier contracts check a small Groth16 or PLONK proof at the end.

Of these uses, bridges are the least mature. SP1 verifier contracts are deployed on several chains, and Wormhole and Boundless offer an Ethereum ZK light client to pilot. We could not confirm production volume for ZK bridges.

On BCH, a covenant that checks the same kind of final proof could accept another chain’s finalized state without a federation. It would also need the source chain’s light-client logic (the rules for following that chain’s consensus), which no one has built.

Status: early elsewhere; possible on BCH, not built.

Zero-knowledge beyond on-chain verifiers

Exchange proof of reserves and ZK initial block download (a new node checking a proof of the chain’s history instead of replaying it) are checked off chain, by people or nodes, not by a contract. A Script verifier matters when coins should move only if a proof checks out.

Post-quantum

Groth16 and PLONK rely on elliptic-curve pairings, which a large quantum computer could break. STARKs rely only on hash functions. The post-quantum private spend above verifies on today’s VM with no new opcode, using SHA-256, which BCH’s script VM already has. Details and limits are on other proof systems.

And AI is good at it

This kind of code (finite-field arithmetic, pairings, verifiers in low-level VM bytecode) is painstaking and highly structured, and it is easy to test against valid and tampered proofs, though passing tests does not prove a verifier sound (see the soundness review). That suits modern AI models, which can work through the algebra and byte-level optimization while the harness checks each step on chain. Every BCH-native verifier on this leaderboard was built with AI models. The same loop applies to larger targets, such as bitjson’s open challenge to design a post-quantum, activity-aggregating STARK covenant for the 2026 CashVM.

A higher ceiling, and why bytes matter

The 2026 upgrade added bounded loops, big-integer arithmetic and reusable functions to BCH’s VM. Work that once had to be hand-unrolled thousands of times can be written once and looped, which makes complex programs like these verifiers practical to write and audit. The Groth16, PLONK and STARK verifiers measured above each fit in one standard transaction today.

A Groth16 verifier’s byte count is not really about one circuit. It proves out the primitive, trustless on-chain proof verification, that privacy, settlement and bridges all build on. Anyone can try to beat the current entries on the leaderboard. On BCH, bytes are also the fee: smaller verifiers make every one of these uses cheaper. Further protocol upgrades could shrink them more, though none is required; see which limits to raise.