Six Teams Shipped the Same ZK Verifier Bug. Quantum Doesn’t Get a Patch.

Introduction

On March 3, 2026, OtterSec published “Unfaithful Claims: Breaking 6 zkVMs,” disclosing a Fiat-Shamir transcript-binding failure across Jolt, Nexus, Cairo-M, Ceno, Expander, and Binius64. Six organizations, six codebases, one mistake: a value that affects the verification equation was not absorbed into the transcript before the challenge was sampled, so a prover could see the challenge and then choose the value. Trail of Bits documented the identical class in 2022 under the name Frozen Heart. Solana patched two instances in 2025. The rekt.news write-up has the sequence, and its conclusion is uncomfortable: the papers existed, the trackers existed, the bounties existed, and six teams arrived at the same error independently. Most of the fixes ran to one or two lines.

Twenty-seven days later, researchers at Google Quantum AI, UC Berkeley, the Ethereum Foundation, and Stanford published an aggressive resource estimate for running Shor’s algorithm against secp256k1, the curve behind Bitcoin and Ethereum signatures. Ryan Babbush and colleagues gave two configurations: under 1,200 logical qubits with 90 million Toffoli gates, or under 1,450 logical qubits with 70 million, running in minutes on fewer than half a million physical qubits at a 10⁻³ error rate. I covered the paper when it landed. They withheld the circuits, substantiating the numbers instead by proving properties of a hidden point-addition circuit in zero knowledge, simulating it inside the SP1 zkVM and compressing the output with a Groth16 wrapper. On April 17, Trail of Bits published a better proof, by exploiting memory-safety and logic defects in Google’s Rust guest program to forge an attestation claiming superior circuit metrics, with a reproduction repository. SP1 worked. Groth16 worked. The proof system faithfully proved the execution of a program that would accept invalid resource accounting. Google patched it, the scientific conclusions held, and the arXiv comment on v2 records the fix in eight words: “patches software bug enabling exploit against ZKP soundness.”

Three failures, three layers. Trail of Bits attacked the relation being proved. OtterSec attacked Fiat-Shamir transcript binding. Shor attacks a third thing entirely, the discrete-log and pairing assumptions beneath many deployed verifiers, though not beneath every zkVM in OtterSec’s set. What they share is the boundary they arrive at, which is the code path that accepts a proof as true and writes its consequences into canonical state. And that is where the quantum case separates from the other two: the classical defects were local and correctable in place, while a broken hardness assumption leaves nothing to correct. For many deployed zero-knowledge systems, the migration unit is not a parameter or a library. It is the verifier, the contract, and sometimes the consensus rule.

Where the Quantum Risk Actually Sits

The most useful framework I have seen for this appeared quietly at the end of June, when Swiss cryptologist Andreas Renz published a 54-page systematization of knowledge titled “Post-Quantum Risk in Deployed Zero-Knowledge Architectures: A Layered Analysis.” The PDF is dated June 30 and went up on July 3, published through Encryptorium, his affiliation. It carries a CC BY 4.0 license, does not sit on the Cryptology ePrint Archive, and the Zenodo copy is labeled by the author as not peer reviewed. As of August 12, 2026, I could find no independent scholarly citations of it.

I am recommending it on the strength of the analysis, not the imprimatur, and readers should weigh it accordingly. What it has is a decomposition that makes the deployment question tractable.

Renz splits a proof system into four layers. L1 is arithmetization: turning computation into constraints, using R1CS or AIR or a PLONKish format. L2 is the commitment and consistency mechanism, where the prover commits to large objects and proves small claims about them. L3 is protocol and argument logic, often organized as an interactive oracle proof. L4 is non-interactivity and the extraction model together: Fiat-Shamir compilation, the oracle assumption it rests on, and extractability. Groth16 is the exception, because its non-interactivity comes from its algebraic CRS structure rather than Fiat-Shamir. Renz is careful that the boundaries are analytical rather than literal, and FRI is his own example: it straddles commitment and protocol logic. His per-system classifications are likewise a snapshot of early 2026 and may move as the literature does.

L2 carries the quantum exposure in many widely deployed systems. KZG commitments derive binding from the d-Strong Diffie-Hellman assumption in a pairing group, which a discrete-log oracle solves directly, recovering the trapdoor from the structured reference string and permitting fabricated openings for arbitrary evaluation claims. Inner-product arguments in Halo 2 and Bulletproofs place their soundness-critical dependency on plain discrete-log binding in a prime-order elliptic-curve group. Groth16 fails for the same higher-level reason, through its own pairing-based verification structure rather than through a separable commitment module. Larger curves can buy quantitative delay in each case; they do not restore a hardness assumption.

L4 carries an obligation many deployed pipelines have not documented end to end. Classical Fiat-Shamir security proofs live in the random oracle model, and quantum adversaries can query the oracle in superposition. Lifting a ROM proof to the QROM is not automatic: rewinding-based extraction interacts badly with no-cloning. For Fiat-Shamir applied to suitable Σ-protocols, the DFMS reduction costs a loss quadratic in the query bound rather than the linear ROM loss; multi-round IOP compilers are more system-dependent, with losses polynomial in the round count.

The generic result arrived earlier than most summaries suggest. Chiesa, Manohar, and Spooner showed in 2019 that round-by-round soundness of an IOP yields QROM soundness for the BCS-transformed SNARG, with proof of knowledge requiring the corresponding round-by-round knowledge condition. Block and co-authors then proved the relevant properties for FRI, batched FRI, and a formal Plonky2-style model, and sketched rather than proved the same for ethSTARK and RISC Zero. Chiesa’s team returned in late 2025 to generalize the BCS framework from IOPs and SNARGs to IORs and SNRDXs, obtaining adaptive straight-line quantum extraction for the latter. All three are frameworks rather than certifications. The remaining task is to show that each deployed compiler’s actual batching, recursion, domain separation, and transcript conventions satisfy their hypotheses, and Block’s own Plonky2 treatment is candid that its model leaves low-level implementation choices unaddressed.

One scope condition matters before the numbers. This is a proof-system analysis, not a complete quantum threat model for a chain. It assumes signatures, VRFs, randomness, and block production migrate on their own track; if they do not, Shor enables more direct chain-level compromise, and Zcash’s own specification says exactly that below. Nor does a future forgery rewrite already-finalized blocks under an intact consensus mechanism. What it does is enable new invalid transitions for as long as a vulnerable verifier keeps accepting them. Verifier migration is an independent workstream, not a substitute for migrating a chain’s other public-key primitives.

All of this is a design constraint rather than a philosophy seminar, because of what the resource numbers now say. Renz reads the Babbush estimates as I do: the pairing-friendly curves underneath KZG, BN254 and BLS12-381, should sit in broadly the same regime, with BLS12-381 needing a larger machine. Those are extrapolations rather than optimized attack estimates for those curves, and the source is a Google-led whitepaper that has not been externally peer reviewed. Nor is the Google figure the floor any more. In July 2026, a preprint from four Chinese institutions reported an 835-logical-qubit construction at a substantially higher Toffoli count, and as I wrote then, the hardware picture did not move. QuEra’s Nature paper, published online in late 2025 and appearing in the January 2026 volume, demonstrated up to 96 distance-4 logical qubits on an architecture using 448 neutral atoms. That is not a commensurable quantity with an algorithmic width estimate. Cryptanalytic depth requires logical error rates sustained across tens of millions of non-Clifford operations, and the code distance that demands depends on the code, the physical noise, the decoder, and the target failure probability. Width is the least demanding of the constraints my CRQC Quantum Capability Framework tracks. The honest answer on timing is that we do not know the year. We do know it falls plausibly inside the operating life of infrastructure being deployed in 2026.

Three Failure Modes, Not Two

Most discussion of post-quantum ZK reduces to a binary: hash-based systems are fine, pairing-based systems are not. Renz’s second contribution is showing that the binary hides the decision organizations actually face.

He crosses cryptographic effect against deployment feasibility. On the cryptographic axis, a structural break means the broken assumption is fused into verification semantics or statement structure, so no swap preserves the system. A modularly replaceable break means the broken component sits behind a stable interface and can be exchanged. Quantitative degradation means Grover and QROM losses erode concrete security that parameter increases restore. On the deployment axis, a system is upgrade-ready, upgrade-constrained, or upgrade-blocked depending on whether verifier replacement has a defined mechanism, faces coordination obstacles, or has no path at all.

The combinations produce the outcomes. A Groth16 verifier embedded in an upgrade-constrained deployment lands in what Renz labels total collapse. PLONK with KZG is the comparatively favorable case: the commitment interface is separable, so a swap to FRI, STIR, or WHIR preserves the arithmetization and the statement being proved. That still means a new proving backend, proof format, transcript conventions, verifier implementation, and audit, but it is migration rather than redesign. STARK-style systems, Plonky2 and Plonky3, circle STARKs, and Binius fall under quantitative degradation. Their dominant commitment dependency avoids Shor, so the pressure shows up as larger digests and more query rounds, though concrete assurance still turns on hash margins and pipeline-faithful QROM analysis that has not been completed.

Transparent discrete-log systems are the interesting case. Halo 2 and Bulletproofs avoid trusted setup, which the community reasonably treats as a virtue, and both place a soundness-critical dependency on discrete-log binding. Worse, the inner-product argument’s recursive halving performs multi-exponentiations that are part of the verification equation rather than calls to a replaceable module. Halo 2’s accumulation scheme is tightly coupled to that linear homomorphism, and no known post-quantum construction preserves the same homomorphic vector-commitment interface at comparable efficiency. Common Nova instantiations inherit the discrete-log or pairing exposure of their commitment and compression backends. Recursion arithmetizes the verification relationship into the outer circuit; it does not restore binding once alternative openings become computable. Folding as a construction is not intrinsically tied to those assumptions, as the lattice work below shows.

Lattice folding has started to close that gap. LatticeFold+ replaced the bit-decomposition range proof that bottlenecked Boneh and Chen’s original prover with a more efficient algebraic construction, and Neo and SuperNeo extended lattice-based folding to small fields like Goldilocks while keeping Module-SIS commitments. None has comparable production deployment.

Zcash Ran the Experiment in July

Renz applies his modularity test to Zcash Sapling and reaches total collapse: Groth16 verification semantics with no separable commitment module, embedded in consensus rules, requiring hard-fork coordination to change. Correct, and by publication the more instructive case was already underway.

On May 29, researcher Taylor Hornby, auditing the protocol for Shielded Labs, found an under-constrained elliptic-curve multiplication in the Orchard circuit, the flaw now known as the infinity bug. It could have permitted undetectable counterfeit ZEC and had been live since Orchard activated in 2022. Zcash froze Orchard transactions overnight on June 1–2, then re-enabled the pool through the NU6.2 hard fork on June 3. ZEC fell roughly by half over the disclosure window, from about $624 on June 4 to about $309 on June 5, a move that Arthur Hayes exiting his entire position intraday helped accelerate. Shielded Labs was candid about the part that stings: because the pool is private, no one can determine from the chain whether the flaw was ever exploited.

Then, on July 28, Zcash activated Ironwood at block 3,428,143. The NU6.3 upgrade introduced an entirely new shielded pool with a v6 transaction format, its own note commitment tree and nullifier set, a turnstile capping outflows at verified deposits, and a machine-checked balance-integrity proof of more than 2,700 Lean theorems under stated cryptographic assumptions. Orchard was closed to new deposits and restricted to withdrawals.

The cost: roughly 3.66 million ZEC, near $1.7 billion at the price around activation, sat in a pool that could take no more deposits, with migration entirely voluntary. CoinDesk reported about 176,000 ZEC entering Ironwood on day one, roughly 5 percent of the balance, and not all of it from Orchard; by mid-August that figure had passed 1.5 million. Node operators were simultaneously being forced off zcashd, and the activation slipped a week because exchanges, mining pools, and wallet providers said they needed more runway.

That is what a consensus-embedded protocol migration looks like with strong engineering, aligned funding, an active foundation, a genuine emergency, and a bug its own auditors found. And Zcash did it without changing proof systems at all.

Ironwood reuses Orchard’s Halo 2, exactly the family Renz classifies as having no drop-in replacement. Zcash knows. ZIP 2005 shipped quantum-recoverable notes with Ironwood, changing how notes are constructed so that a future recovery protocol could reclaim funds after discrete log falls. The specification is blunt about what that does and does not buy: the note commitment algorithms in Sapling and Orchard are not post-quantum binding, which means that even upgrading the proof system to a quantum-safe one and rebuilding the commitment tree with a suitable hash would leave a discrete-log-capable adversary able to forge and spend notes that were never in the tree.

Zcash’s own protocol authors, writing in a consensus ZIP, state that swapping the proof system would not have been sufficient. The quantum-vulnerable assumption reaches into the note construction itself, which is why the fix arrived as a new note format in a new pool rather than as a component substitution. That is Renz’s structural-break definition arriving at the same place from a working deployment, and ZIP 2005 was created on March 31, 2025, so Zcash got there fifteen months first.

Ironwood is not quantum-safe. It is quantum-recoverable, a much more modest property: prepared for an eventual transition rather than defended against a live attacker. The recovery protocol exists in outline, with many design decisions intentionally left open. Funds left in Sprout, Sapling, and Orchard get none of it and become inaccessible once those protocols are disabled.

The ZIP goes further than I would have, and it comes from the people who would have to execute the migration. Its effects analysis works through what a discrete-logarithm break does to each pool, and the answer is not a gradual erosion. One logarithm on BLS12-381 is enough to attack Sprout and Sapling; one on Pallas or Vesta is enough for Orchard and Ironwood. Either breaks balance and spend authentication for the pools in its family, and the ZIP is explicit that Ironwood is included. Its conclusion, which the authors italicize for emphasis, is that the older protocols have to be turned off before quantum attacks become feasible. That is a migration deadline written into a consensus proposal by the people who will have to meet it.

Shielded pools exist because some people need financial privacy for reasons that are not speculative: journalists, dissidents, people in jurisdictions where a visible transaction is a risk to their safety. Whatever their operational security depends on today, it now includes a note format designed to support a recovery protocol nobody has finished writing.

No Regulator Sets the Deadline for a Permissionless Chain

I have argued for years that Q-Day predictions have become the wrong thing to argue about. Regulators, insurers, investors, and clients have set their own deadlines, and those dates bind whether or not the hardware cooperates. The UK NCSC published 2028, 2031, and 2035 milestones as final guidance. NIST IR 8547, still an initial public draft, proposes deprecating 112-bit asymmetric algorithms after 2030 and disallowing quantum-vulnerable ones after 2035. The EU’s coordinated roadmap tiers by risk, with high-risk transitions at 2030 and medium-risk at 2035. For an enterprise, the argument is settled: your procurement cycle already contains your deadline.

None of it reaches an on-chain verifier.

Regulators and market intermediaries can apply pressure at the edges. They reach exchanges, custodians, foundations, and identifiable developers, and that pressure is real. What none of them can do is schedule a change to a permissionless consensus rule. The mechanism I rely on to make enterprise urgency concrete has no direct counterpart here, and I would rather say that plainly than pretend my framework generalizes further than it does.

The historical parallel worth studying is SHA-1, which I treat as the canonical agility failure in my work on crypto-agility. NIST began deprecating it for signature use through SP 800-131A in 2011, with transitions effective at the end of 2013. The first public collision arrived in 2017. Support persisted for years past both dates because dependent systems could not drop it without breaking. What eventually forced the issue in the public Web PKI was not the mathematics and not the standards body. It was that browser vendors could unilaterally distrust certificates, and there were few enough of them to coordinate.

There is no browser-vendor equivalent for a verifier embedded in consensus rules. There is governance, and governance in this domain is structurally biased toward reacting to visible failures. Zcash moved decisively in June and July, and it moved because a researcher found a live counterfeiting bug and the token lost half its value in two days. Starknet combines token-weighted governance with a twelve-member security council that can approve emergency upgrades without the ordinary delay. zkSync Era’s verifier sits behind a proxy under multisig control, and the Boojum upgrade showed that a governed rollup can replace its entire proving architecture without regenesis. Each of those is a working technical upgrade path. None of them guarantees that operators, bridges, wallets, exchanges, and token holders coordinate before the threat becomes operational, and a threat that is credible but not yet operational is the hardest kind to act on through token-weighted voting.

So this is the one domain where the timeline question cannot be routed around. Structural-break systems need to begin migrating at T_CRQC minus T_mig, and Renz estimates T_mig at three to five years for specification, implementation, audit, coordinated deployment, and sunsetting legacy acceptance. He labels that an author estimate, and Ironwood does not validate it: that was an emergency protocol migration completed in roughly two months on a pre-existing proof system. What Ironwood does show is how much coordination a narrowly scoped, well-funded, crisis-driven transition consumes even so. Replacing the proof system underneath is a materially larger undertaking than the one Zcash just finished.

The Lattice Exit Has Its Own Problem

If pairing-based and discrete-log commitments are the exposure, the obvious replacement at L2 is a lattice-based polynomial commitment scheme. The proof-size objection that dominated this conversation in 2024 has weakened sharply. Greyhound composed with LaBRADOR brought evaluation proofs down to the tens of kilobytes at degree 2³⁰, Hachi reported comparable sizes for multilinear commitments over extension fields, and Jindo cut proof sizes a further 4.8× over prior lattice work. Megabyte-scale openings no longer disqualify the approach. Prover cost, verification cost, batching, and recursion-friendliness remain open, and Renz names the last two as bottlenecks, so this is a research-stage trade-off rather than a drop-in KZG competitor.

It is also not the whole post-quantum picture. Renz excludes MPC-in-the-Head and purely symmetric-key constructions from his scope while conceding they are arguably the most naturally post-quantum family, and analyzing them properly needs a different decomposition than L1–L4.

Which puts the leading escape route from a PCS-centric architecture on an assumption family now attracting fresh scrutiny. I covered Daniel Simon’s dihedral-coset claim and the Wen-Zheng CRYPTO 2026 result on August 6, and my position has not moved: neither breaks Module-LWE or lattice commitments, Simon’s paper is a recent preprint with sketched proofs, Wen-Zheng establishes a reduction rather than an attack, and lattice cryptography faces real emerging risk that deserves architectural rather than rhetorical treatment. That position applies with more force here than in TLS. An enterprise that has already built crypto-agility can hedge ML-KEM with a second family at the protocol and configuration layers. A rollup hedging its polynomial commitment scheme is redesigning its proof system twice.

Renz arrives at the same caution from the SIDH precedent. SIKE fell in 2022 to a classical attack exploiting torsion-point information in the public key, after years as a leading NIST candidate. His modularity test is not really a quantum instrument. It measures whether an architecture can absorb any assumption failure at a specific layer, which is crypto-agility as an architecture problem reaching a domain I had not previously seen it applied to.

This Is Trust Now, Forge Later

Collect now, forge later is the name Renz gives the deployment threat, positioned as the proof-system analogue of harvest now, decrypt later. The phenomenon is real and precisely characterized. Verification keys, on-chain verifier code, and proof transcripts are public and persistent, so as long as a Shor-vulnerable verifier keeps accepting proofs, a future quantum adversary generates fraudulent ones that pass. He separates two consequences: forward forgery, where new false proofs are accepted by a legacy verifier, and retroactive trust erosion, where historical attestations lose evidentiary weight once forgery becomes indistinguishable from honesty. On a live chain with intact consensus, the second is narrower than it sounds, since trusted chronology can still establish that a proof was accepted before the break. It bites hardest on retained attestations with no such anchoring.

The name is the part I would change, and the objection is mine rather than his. The report observes that verification keys, verifier code, and transcripts are typically public and persistent on-chain, so an adversary does not need to harvest anything secretly. Renz draws a different distinction from that observation: HNDL threatens the confidentiality of past data, CNFL threatens future integrity. He does not argue about the name. I will. If the artifacts are already public, the collecting verb is doing no work, and a threat model whose first verb is vestigial has the wrong parent.

I described the signature-side analogue in 2018 as Sign Today, Forge Tomorrow, and I now use Trust Now, Forge Later, which better names the integrity pattern. It describes this structure for signatures: the exposure window is the life of the verifier rather than the life of the data, and every verifier still trusting the old mathematics is a live attack surface for as long as it runs. Swap signature for proof and code-signing chain for rollup verifier contract and the integrity pattern transfers closely, allowing that proof systems add canonical-state transitions and knowledge-soundness questions that signatures do not have. HNDL is about confidentiality of things already captured. TNFL is about integrity enforced by long-lived verification infrastructure. What Renz describes is TNFL applied to proof systems, and I would rather the field carry one concept across two domains than two concepts that need reconciling.

This is a naming disagreement inside an argument I largely accept, and the layered decomposition and the modularity test are contributions I expect to use. Blockchain verifiers are also the more punishing instance of the pattern. A code-signing verifier is usually an update away from migration. A verifier embedded in consensus rules may need a coordinated network fork, and that fork has no external scheduler with authority to impose a date.

What Follows From This

Renz closes his report with stakeholder recommendations in section 6.8, and most of what follows tracks them: the dual-verifier pattern, the state-root binding, the governance question about how evidence is read across verifier versions, and the ROM-versus-QROM audit line are all his. Where I have added something, I say so.

For protocol designers: separability at L2 is usually set by the initial architecture and is expensive to revisit later, and it determines whether your successor pays a swap cost or a redesign cost. PLONKish arithmetization with a clean commitment interface is the cheaper long-term position than Groth16 or an accumulation scheme welded to a homomorphic vector commitment, whatever the proof-size comparison says today. If you are choosing a proof system this year and expect the deployment to outlive the decade, this belongs in the decision alongside prover time.

For rollup operators and on-chain deployers: deploy successor verification beside the legacy verifier, run a dual-verifier epoch window in which both proof formats bind to identical public inputs and the same pre- and post-state roots, then sunset legacy acceptance. Three things I would add to Renz’s version. Publish the sunset date, because an open-ended window is a decision deferred rather than made. Treat the sequence as a rehearsed procedure rather than a plan on paper. And be clear that this is a pre-break pattern: once the legacy assumption has actually fallen, a verifier that accepts either format still accepts forgeries, so the window buys migration time and nothing else. Boojum shows a governed rollup can replace its proving architecture without regenesis; it did not demonstrate the dual-verifier epoch, which is cheaper to rehearse than to invent under pressure.

For auditors: QROM status belongs on the standing checklist as an explicit line, distinguishing Fiat-Shamir compilation proven in ROM only from a QROM proof applying under stated conditions. I would add a third state, not analyzed at all, which is where many deployed pipelines appear to sit and which the first two categories quietly hide. I would also add a separate line for transcript binding, since the OtterSec disclosure established that six competent teams got it wrong independently and the class predates them by four years.

For governance owners: decide now how evidence is interpreted across verifier versions. Valid under verifier v1 at issuance and must remain valid under the current verifier are different policies with different consequences for anything you retain as a record, and the choice is much cheaper to make before the migration than during it.

And if you hold exposure to any of this without building it, the question to ask is which of two problems your position actually turns on. Parameter tuning has vendors and a price list. Architecture has neither.

Six teams shipped the same verifier bug, and the fixes ran to a line or two. The quantum version does not get a line.

Disclosure: I advise Project Eleven, which develops post-quantum cryptography for digital assets, and I am founder and board chair of Cryptosec, which works in blockchain security. Neither has any involvement in this analysis.