Opus 4.8 Helped Find Zcash's Orchard Forgery Bug

Zcash Foundation said on June 3, 2026 that Taylor Hornby, an independent security researcher auditing the protocol for Shielded Labs, found a critical soundness vulnerability in the Orchard zero-knowledge proof circuit on May 29 and disclosed it to Zcash Open Development Lab engineers that evening. Zebra 4.5.3 temporarily disabled Orchard actions, and Zebra 5.0.0 activated NU6.2 on June 3 to re-enable Orchard with a corrected circuit.

The Opus 4.8 detail matters, but it should be stated carefully. Reporting on Shielded Labs' disclosure says Hornby used Anthropic's newly released Opus 4.8 model and a custom AI tool to write a working local exploit that could generate unlimited counterfeit ZEC inside Orchard. Zcash Foundation's narrower public framing says the bug could permit invalid state transitions and double-spending within Orchard, but not inflation of total ZEC supply because turnstile accounting tracks value moving between pools. The remaining trust problem is auditability: privacy protects user amounts, but it also makes a simple public all-clear harder.

The official Zcash Foundation account of the incident is direct. On Friday, May 29, Hornby found a critical soundness vulnerability in the Orchard zero-knowledge proof circuit while conducting an ongoing protocol audit for Shielded Labs. He responsibly disclosed the issue to ZODL core engineers that evening. Daira-Emma Hopwood, Kris Nuttycombe, and Jack Grigg confirmed the issue within hours and began evaluating remediation options.

The response had two stages. First, Zebra 4.5.3 implemented an emergency soft fork that temporarily rejected Orchard-containing transactions and blocks at mainnet block height 3,363,426, around 02:00 UTC on June 2. Then Zebra 5.0.0 activated NU6.2 at mainnet block height 3,364,600 on June 3, re-enabling Orchard with a corrected circuit and a new verifying-key path.

The vulnerability lived in the implementation of the Orchard zero-knowledge proof circuit in the halo2_gadgets crate. In a ZK system, soundness is the property that a verifier should accept only valid statements. When soundness fails, the verifier can be convinced that an invalid transaction or state transition is valid. That is close to the worst kind of bug for a shielded cryptocurrency pool because the system's public chain is supposed to rely on the proof rather than visible transaction amounts.

Zcash Foundation describes the impact as possible invalid state transitions and double-spending within Orchard. It also lists affected versions across halo2_gadgets, orchard, zcash_primitives, zcashd, and zebrad. The Foundation says the vulnerability did not allow total ZEC supply inflation because Zcash's turnstile mechanism tracks value balances across transparent, Sapling, Orchard, Sprout, and lockbox pools.

The Defiant's report on Shielded Labs' disclosure says Hornby used Opus 4.8 and a custom AI tool to build a complete exploit that generated unlimited counterfeit ZEC in a local regtest environment. According to that report, Shielded Labs said running the same tool on mainnet would have produced unlimited, undetectable counterfeit ZEC inside Orchard. The reported root cause was an under-constrained part of the Orchard circuit that could allow false inputs to pass an elliptic-curve check.

That framing is sharper than the Foundation's public writeup, and both should be kept separate. The Foundation's claim is about protocol-wide supply and observed evidence after the emergency response. Shielded Labs' claim is about what could happen inside the affected shielded pool if the exploit were run. Those are not identical risk statements. The difference is exactly why supply-proof work is now part of the story.

Zcash's privacy design hides transaction amounts in shielded pools. That is the feature users want. It also means the public cannot simply sum every Orchard balance and compare it with expected issuance after a soundness bug. Zcash turnstiles provide a pool-level accounting boundary: value cannot leave a pool beyond what entered it, so they limit blast radius and protect the broader cap. They do not necessarily prove that no invalid value ever existed inside the private pool before the fix.

Shielded Labs is reportedly exploring a further network upgrade that would deploy a new shielded pool and route coins leaving Orchard through turnstile accounting so anyone could verify that no counterfeit ZEC remains. That proposal has not yet gone through Zcash governance. The important point for Protocol Report readers is architectural: privacy systems need explicit audit primitives. Otherwise the best post-incident statement becomes a careful mix of evidence, assumptions, and residual uncertainty.

Anthropic released Claude Opus 4.8 on May 28, one day before Hornby found the bug. Anthropic describes the model as an upgrade for coding, agentic skills, reasoning, tool use, and long-running work. None of that proves the model independently understood Zcash or found the flaw by itself. The public evidence supports a more sober conclusion: a skilled auditor used a stronger model inside a purpose-built audit harness and turned a subtle circuit flaw into a working local exploit.

That still changes the economics of protocol security. Frontier models can help auditors search large codebases, generate hypotheses, compare constraints against specifications, write tests, and turn suspicious behavior into proof-of-concept exploit code. The same capability will not stay reserved for defenders. Crypto projects using ZK circuits, bridges, custom consensus code, and complex wallet logic should assume that old audits age faster when AI-assisted review becomes normal.

For node operators, the immediate instruction is simple: run fixed software. Zcash Foundation strongly urged operators to upgrade to Zebra 5.0.0, or to Zebra 4.5.3 only if unable to move to 5.0.0 before NU6.2 activation. Exchanges, wallet services, infrastructure operators, and explorers should confirm they followed the NU6.2 chain and did not rely on stale nodes during the transition.

For users, the public record does not show stolen funds or broken message privacy. The risk is confidence in the shielded pool's historical integrity, not a need to rotate a password. Users moving meaningful amounts should still check their wallet and exchange providers' upgrade status, understand whether Orchard sends are fully restored, and watch for the promised supply-proof proposal before treating the issue as fully closed.

ZK projects should review circuit constraints as security-critical code, not just mathematical artifacts. Every optimized gadget, custom curve operation, witness path, and verifying-key transition deserves adversarial tests that try to prove false statements. Independent audits should be repeated after major model improvements, compiler changes, dependency updates, and protocol upgrades.

The incident also argues for response planning before a bug exists. Zcash could move quickly because responsible disclosure paths, engineers, miners, exchanges, and node operators could coordinate under pressure. That kind of coordination has centralization tradeoffs, but a privacy protocol with a live soundness bug has no perfect emergency option. The better answer is to make the next response more transparent, more rehearsed, and easier to verify after the fact.