verifier.cash
← back

How it works

Better than the state of the art

Bitcoin Cash's 2025/2026 upgrades (big-integer script numbers, bounded loops, and reusable functions via OP_DEFINE/OP_INVOKE) give Script enough power to run a real Groth16 verifier on chain. Not just to run one, but to run it more efficiently than the state-of-the-art verifiers that exist today: those execute as single multi-megabyte transactions, while BCH's new opcodes let us compress the same work with loops and shared functions and spread it across cheap steps.

What it takes

Bitcoin Cash has no pairing precompile, so the entire verifier (field-tower arithmetic up through F_p¹², the Miller loop, and the final exponentiation) is written in Script. The recent upgrades are exactly what make that tractable: big-integer numbers for 256-bit modular arithmetic, loops to collapse repeated work, and reusable functions so the field operations aren't re-inlined everywhere.

A chain, not a singleton

BCH keeps a per-transaction budget: a 10 KB unlocking-bytecode cap per input, and an op-cost budget that scales with it. The whole pairing computation is larger than one transaction's budget, so a BCH-native verifier splits the work across a chain of transactions, carrying state forward in a commitment between steps. That is the design, and minimising its total footprint is the game.

The competition

  • Goal: verify a fixed Groth16 statement on the BCH 2026 VM.
  • Score = total on-chain bytes across all steps. Lower wins: bytes are what a user pays in fees.
  • A single huge transaction is allowed, but it will not fit BCH's per-tx limits; a valid BCH-native entry is a multi-transaction chain.
  • Correctness is a gate: a submission must accept the valid proof and reject tampered ones, or it isn't listed.
  • Secondary metrics (op-cost, step count, BCH-compatibility) are shown but don't set the rank.

The baselines we're beating

The only Groth16 verifiers in the wild run on BSV, which removed Bitcoin's limits, so they execute as single multi-megabyte transactions. We seed them as reference baselines (nChain, BLS12-381; sCrypt, BN254). Both are correct; both exceed BCH's per-tx limits. They use different curves, so their byte totals aren't directly comparable, so use the curve filter.

Submitting

Submissions (GitHub sign-in plus a compiled bytecode artifact graded by the harness) arrive in the next phase. For now this is a live read-out of the benchmark. Follow zk-verifier-bench.