The bug was two lines of code. It had been sitting inside Zcash Orchard privacy pool since May 2022. Human auditors reviewed the circuit multiple times and missed it entirely.
Taylor Hornby, a security researcher contracted by Shielded Labs, found the flaw on May 29, 2026, during an AI-assisted audit using Anthropic’s Claude Opus 4.8, which had been publicly released just the day before. Hornby’s zcash-full-stack-auditor agent framework flagged a missing constraint inside the halo2 variable-base scalar multiplication gadget, the component responsible for enforcing that a prover uses the correct incoming viewing key when spending an Orchard note.
The Code That Should Have Said No
The circuit constraint that was supposed to bind the base point in the double-and-add scalar multiplication loop was never there. Two assign_advice() calls in incomplete.rs were assigning witness values without producing any circuit constraint that forced those values to equal the actual base the algorithm was supposed to use. A malicious prover could substitute any base they wanted and pass the check.
That check, written as pk_d^old = [ivk]g_d^old in the Zcash Protocol Specification, is what enforces that the nullifier revealed by a spending action is the real nullifier for the note being spent. Without it, a prover can supply a wrong nullifier key nk, derive a fresh nullifier, and spend the same note again. Repeat indefinitely.
Hornby tested the theory against a local regtest environment. The RPC test he developed with Claude’s help doubled an Orchard note’s value in successive passes until the wallet balance exceeded 10 million ZEC. The attack worked. Regtest applies the same zero-knowledge proof validation rules as mainnet. Those transactions never touched mainnet or testnet, but the proof of concept was complete.
The vulnerability had been present since Orchard activated with the NU5 upgrade on May 31, 2022. That is four years, one day, and ten hours of exposure window. Claude Opus 4.7 on extended high settings failed to catch it in prior audit runs unless prompted with very specific language about the exact component to check. Opus 4.8 found it without that level of prompting, though Hornby’s own disclosure document notes the bug was still inconsistent to surface, appearing in only about one in four generic audit attempts even with the newer model.
Fix Speed That Surprised Everyone
Hornby reported the issue over Signal to Daira Emma Hopwood and Kris Nuttycombe at 11:53 PM on Friday, May 29. By 9:30 PM on Monday, June 1, a soft fork disabling Orchard had activated on mainnet. The response window from acknowledgment to deployed soft fork was two days and fifteen hours.
The first soft fork attempt failed. A missed peer-to-peer DoS banning rule caused nodes unaware of the soft fork to be prematurely banned from the network. ZODL prepared a second release with a soft fork height set 60 blocks later, and that one held.
Orchard was re-enabled at block 3,364,600 on June 2 after the NU6.2 release restored the circuit with the corrected copy_advice() calls replacing the unconstrained assign_advice() ones. The fix forces the first base value in the incomplete addition loop to equal the correct base through a circuit copy constraint, which then propagates to all subsequent iterations through the existing q_mul_2 constraint.
No unauthorized value creation was confirmed. The Zcash Foundation said it found no evidence of exploitation. But the privacy architecture of Orchard makes that statement structurally limited. ZEC moved inside the pool before any suspicious transaction would reach the public ledger, and zero-knowledge proofs do not leave signatures distinguishing honest spending from exploitation. Hornby had Claude run statistical analysis on Orchard transaction arities in the Opus 4.8 exposure window. The results were inconclusive.
What the Community is Still Arguing About
The disclosure triggered a thread on the Zcash community forum that most coverage did not touch.
The proposed Ironwood network upgrade introduces a turnstile mechanism requiring all Orchard funds to migrate into a new pool. Sean Bowe, writing in response to forum questions, explained why this step is structurally necessary. As conradoplg of the Zcash Foundation summarized from Bowe’s response on X:
“Forcing users to leave Orchard through the turnstile is necessary, or else there is no coherent definition of a supply cap. If people can trade and value ZEC within the Orchard pool as though nothing changed, then people can theoretically transact with more funds than are supposed to exist.”
That framing resolved one question and opened another. Forum user fivelittleducks pushed back on whether the scenario was ever likely, given the evidence. The total supply across the turnstile remained intact, the Foundation reported no unauthorized creation, and the exploit pattern would have required either a detectable mass drawdown or complete inaction by any attacker holding a working exploit. No such drawdown appeared. The statistical analysis of arity-4 transactions in the Opus 4.8 window matched a similar anomaly from a month prior, which could be explained by calendar-linked behavior patterns unrelated to exploitation.
The structural risk the community is still working through is loss socialization. If any counterfeit ZEC did exist inside Orchard and migrated undetected, whoever migrated last would absorb the shortfall when the turnstile bounded total exit to the real pool value. Forum user pjv raised this as a genuine structural dynamic worth addressing in advance. Fivelittleducks agreed the mechanism was real but argued the most likely current state of Orchard is that no counterfeit balance exists to socialize.
A ZEC holder deciding whether to migrate early or late is navigating that exact ambiguity.
Daira Emma’s Parallel Effort
While the emergency response was underway, Daira Emma Hopwood was already working on a separate but related problem: formal mathematical verification of Orchard from the ground up.
In a post on the Zcash community forum, Hopwood described work on CompElliptic, a computable elliptic curve library for the Lean proof assistant. Lean’s existing Mathlib library was not suited to direct computable use for this purpose, so the work involves building from scratch. Hopwood said formal models of the Pallas and Vesta curves, the curves underlying Orchard, were verified with bridges to Mathlib within a couple of days of starting. The encoding API being added, covering the abst and repr functions from the Zcash Protocol Specification, is intended to tag representations of curve points with their intended encoding and record whether they have been checked for canonical form.
Hopwood noted that tracking this manually in the Rust code has historically been a significant source of bugs.
CompElliptic is being built for eventual integration into the ArkLib/CompPoly ecosystem so that maintenance can be shared across projects. The Zcash-specific formalization is planned to eventually migrate to a dedicated zcash-lean repository.
The AI-discovered bug and the formal verification effort now run in parallel. One found what years of human review missed. The other is building the infrastructure to make missing it impossible.
