Beyond Groth16
Groth16 is the right first target: the smallest proofs and the leanest verifier of any deployed proof system. But it has two lasting limits. Every circuit needs its own trusted setup, and its pairing-based cryptography falls to a large quantum computer (see why Groth16). This page looks at where on-chain proof verification is likely to go next, and what each direction would ask of Bitcoin Cash.
Post-quantum proofs are arriving
Two post-quantum families matured in 2026. On the hash-based side, Microsoft Research’s Magnetar is a general-purpose zkVM whose security rests only on a standard hash such as SHA-256 or SHA-3: no curves, no lattices, no circuit-friendly hash and no conjectured proximity gaps, at 120 bits of provable security. Its paper measures proofs of about 600 KiB, and its author projects recursively compressed proofs at about 100 KB. On the lattice side, Lattice Jolt swaps Jolt’s curve commitments for Akita, a Module-SIS scheme with 128-byte commitments, for proofs under 100 KB with no trusted setup.
| family | rests on | setup | post-quantum | proof |
|---|---|---|---|---|
| Groth16 (this leaderboard) | pairings (BN254, BLS12-381) | per circuit | no | 128–192 B |
| PLONK / KZG | pairings | one, shared | no | ~0.5–1 KB |
| Hash-based (STARKs, Magnetar) | hash functions (standard in Magnetar, algebraic in most STARKs) | none | yes | ~30–600 KB |
| Lattice (Lattice Jolt / Akita) | Module-SIS | none | yes | ~60–100 KB |
The newest systems in both post-quantum families aim at about 100 KB, hundreds of times a Groth16 proof, though only a few times the total bytes a Groth16 verifier puts on chain. What applications need is narrower still. bitjson has tracked it as a standing feature request: a prover that is actually zero-knowledge, quantum-ready, and succinct enough for one-off proofs (under 100 KB). In January 2026 no system had all three:
| prover | zero-knowledge | smallest proof | soundness | BCH VM fit |
|---|---|---|---|---|
| Triton VM (Neptune Cash) | yes | ~345 KB | ~96 bits | poor: over the 100 KB standard transaction; emulated Tip5 costs 24× the op-cost its bytes buy |
| Miden VM | leaks | ~33 KB | ~96 bits | bytes fit (4+ inputs today), compute does not: emulated RPO costs 194× the op-cost its bytes buy |
| Stwo (Starknet) | leaks | ~64 KB | ~96 bits | bytes fit (7+ inputs today); emulated Blake2s costs 33× the op-cost its bytes buy, so it does not pay its own way |
| Magnetar | possible, not built | ~600 KB; ~100 KB projected with recursion | 120 bits | hashing native if SHA-256; a GF(2^128) multiply costs 36× a prime-field one; ~100 KB plus code is tight even for one 100 KB input |
| Lattice Jolt | announced | ~91 KiB | ~122 bits (Akita targets 128) | prime-field math fits big integers; transcript hash and lattice-check cost not yet assessed |
The first three are his January figures; all five are quantum-ready. The last column is our reading of what each verifier would need on CashVM, using hash and field costs we measured on CashVM. Plonky3 set up with SHA-256 (below) also has a zero-knowledge mode: we verified 128-bit zero-knowledge proofs of a private spend, under 80 KB, in one standard transaction. The 2026 systems narrow the soundness gap and reach or approach 100 KB (Lattice Jolt measured, Magnetar projected), but neither is zero-knowledge yet, so a proof can still leak the private data it is about. Magnetar’s author says zero-knowledge can be added without overhead, and a zero-knowledge companion paper for Lattice Jolt has been announced.
What it means for Bitcoin Cash
With a native hash, bytes become the constraint. Bitcoin Cash ties each input’s compute to its size: every unlocking byte buys 800 op-cost (VM limits). A Groth16 verifier has the opposite shape, a tiny proof that needs a lot of compute, which is why the entries here split work across inputs or pad. A hash-based proof is mostly Merkle paths, and each 32-byte node buys far more hashing than native SHA-256 needs to check it.
We measured a 128-bit SHA-256 STARK verifier (research, not zero-knowledge). Its 78 KB proof pays for its own verification, using under half the budget it buys. Checking the Merkle paths takes about a quarter; the field arithmetic takes most of the rest.
It works with existing tools. Those proofs come from Plonky3, an open-source prover used by several zkVMs, set up with SHA-256. For Bitcoin Cash that means a contract can check post-quantum proofs made with standard tooling, under today’s VM and with no new opcode. Most of the verifier is generic, so one design serves many statements, including ones with several tables and lookups. Its zero-knowledge mode, the basis for private payments, bridges and rollups, also verifies on chain, at the cost of a larger proof. These are research results: the 128-bit security level rests on a published theorem plus a proof step of ours that is reviewed internally, not yet externally, and the hiding comes from Plonky3’s construction and was not tested by us.
The hash has to be native. Emulating a hash CashVM lacks (RPO, Tip5, Blake2s) costs 24 to 194 times the op-cost its bytes buy, so those proofs do not pay their own way.
Size limits are what bind. Today an input carries at most 10 KB and a standard transaction 100 KB, so a 128-bit zero-knowledge private spend is split over 12 inputs of one transaction, using almost all of its 100 KB; with 100 KB inputs it fits in a single input. Raising the input limits (which limits to raise) matters more for post-quantum proofs than any new opcode.
The field matters. Systems over prime fields map onto Bitcoin Cash’s big-integer arithmetic, a multiply and a reduction per field multiplication. Binary-field systems such as Magnetar, which works over GF(2128), need carry-less multiplication, which CashVM does not have. Shifts (new in 2026) and XOR can emulate it: we measured 36 times the op-cost of a 128-bit prime-field multiply with the best method found, and 81 to 373 times with the textbook ones.
Aggregation spreads the cost. A 100 KB proof is expensive for one payment but cheap for a thousand: one proof can attest to many users’ activity at once, which is the idea behind bitjson’s activity-aggregating STARK covenant challenge. Ownership is already covered: Quantumroot gives post-quantum vaults on Bitcoin Cash today with hash-based signatures, about 1.5 KB per spend. Post-quantum proofs are the next layer: privacy and settlement that stay secure after Groth16 does not.
Hash or lattice?
For Bitcoin Cash, hash-based proofs instantiated with SHA-256 look like the more natural fit: they rest on the hash function alone, like Quantumroot, add no new assumption, and run on a native opcode. Magnetar shows a hash-based zkVM can avoid algebraic hashes and conjectured proximity gaps, two of the lattice camp’s main criticisms, though at 120 bits it still sits below 128, and on CashVM it pays for its binary field. Lattice Jolt answers with smaller proofs measured today (about 91 KiB to Magnetar’s 600 KiB), 128-byte commitments, about 122 bits (Akita targets 128) and prime-field arithmetic that suits CashVM, at the cost of the Module-SIS assumption. Both are new in 2026, and neither has shown its ~100 KB recursive or zero-knowledge form end to end. What decides a Bitcoin Cash verifier is the same short list: proof bytes, the opcodes the verifier needs, and how conservative its assumptions are.
Other directions
- Wrapping. Prove with a post-quantum system, then wrap the result in a Groth16 proof. Most zkVM rollups do this today: small proofs, but the wrapper is not post-quantum, and it lands on a verifier like the ones on this leaderboard.
- Universal setup. PLONK-style systems with KZG commitments need one ceremony shared by all circuits, instead of one per circuit. We verified proofs from gnark, a widely used prover whose challenges already use SHA-256, against Aztec’s public Ignition ceremony (176 participants). For Bitcoin Cash that means a developer could take a new circuit from standard tooling and verify its proofs on chain without running a ceremony of their own, including circuits that use gnark’s commitment-based gadgets such as range checks, as long as the circuit makes a single commitment. The verifier fits in one standard transaction today, at about three times the bytes of a sound Groth16 verifier on the leaderboard (about 28 KB). Still pairing-based, so not post-quantum.