The Zcash Orchard Bug and the New Economics of Vulnerability Discovery
written by: Tiago Assumpcao
For just over four years, a subtle flaw sat inside the Orchard shielded pool — one of the most sensitive parts of Zcash. Anyone who understood the relevant zero-knowledge proof circuit deeply enough could have used it to inflate ZEC inside the shielded pool with no on-chain signature, no observable trace, and no reliable cryptographic way to prove after the fact whether exploitation had occurred.
The most important part of this story is not the bug itself. It is how the bug was found.
The vulnerability was reportedly discovered in late May 2026 by security researcher Taylor Hornby using a custom AI-assisted auditing framework built around Anthropic’s Opus 4.8 model. The framework identified a missing constraint in the Orchard circuit, helped reason through the exploit path, and supported proof-of-concept development within hours. The same researcher had run earlier automated audits of the same codebase using the same framework with the prior-generation model, Opus 4.7. Those audits did not find the bug. The model changed. The finding changed.
The Zcash case is a concrete illustration of how AI is changing vulnerability discovery. The work can move faster, reach deeper, and give skilled researchers a new capability to find bugs that survived years of traditional review. It is also a reminder that the same capability is available to anyone — including adversaries who have no obligation to disclose what they find.
What Happened
Zcash is designed to support privacy-preserving transactions. Its Orchard shielded pool uses zero-knowledge proofs to let users transact privately while the network still enforces the rules of the system. The proof system lets the network verify that a transaction is valid without revealing the transaction details publicly.
The bug came down to a missing constraint in the proof-building code. Zcash’s underlying cryptography and consensus rules were doing their job, but one circuit constraint that should have bound a critical value to its correct input was absent.
To understand why that matters: Orchard’s circuit must enforce a diversified-address integrity condition. In simple terms, the prover must demonstrate that the incoming viewing key they supply is the correct one for the address being spent. This binding is what forces the prover to use the correct nullifier-deriving key and reveal the note’s true nullifier. The nullifier is the mechanism that prevents the same note from being spent more than once. Break that binding, and an attacker can generate fresh nullifiers for the same note and spend it repeatedly.
The technical root of the problem was in how halo2’s variable-base scalar multiplication gadget handled an intermediate computation. The gadget uses a double-and-add algorithm to compute the scalar multiplication at the heart of the integrity check. For performance, an intermediate stage of that algorithm uses incomplete elliptic-curve addition formulas. The base point for that stage was supplied to the circuit using assign_advice(), which witnesses a private value without generating a circuit constraint that binds it to the correct base. A separate constraint — q_mul_2 — ensured that the base values used across the loop were internally consistent with each other. But nothing tied those values to the base the algorithm was actually supposed to use.
That gap gave a malicious prover the freedom to choose a different internal base value — one calculated to make the proof pass while bypassing the intended integrity check. Given target values for the public key, generator, and viewing key, the attacker can solve for exactly what unconstrained base value is needed to make the computed result equal the desired output, effectively circumventing the check entirely. The result is the ability to spend the same note repeatedly by generating a fresh random nullifier key each time, with each wrong key revealing a unique nullifier that the network treats as valid.
The exploitability was confirmed in a local test environment enforcing the same Orchard consensus and proof-validation rules as mainnet: the researcher demonstrated that a wallet’s regtest Orchard balance could be inflated past 10 million ZEC. The practical ceiling on extractable value was the turnstile accounting that restricts how much value can leave a shielded pool relative to what entered it, but the underlying flaw was real, confirmed, and repeatable.
The fix was straightforward once identified: replace the unconstrained assign_advice() call in the first iteration of the loop with copy_advice(), which generates a constraint binding the base to the correct value. The existing q_mul_2 constraint then propagates that binding across the rest of the loop.
The timeline of response was notable. The flaw had been present since Orchard activated in May 2022 — an exposure window of over four years. It was discovered approximately four days after Opus 4.8’s release. After acknowledgement, the Zcash ecosystem prepared and activated a soft fork disabling Orchard within roughly two and a half days, and the pool was re-enabled after the fix was deployed. No funds are known to have been lost. However, because Orchard is privacy-preserving by design, prior exploitation cannot be ruled out with complete certainty. That irreducible uncertainty is itself one of the most important lessons in this case.
Privacy Systems Face a Different Kind of Incident Response
In most blockchain incidents, investigators can look at public transactions, trace flows, inspect contract calls, and reconstruct what happened. Privacy-preserving systems are structurally different. Their goal is to protect transaction details, and that same property can make certain forms of exploitation impossible to prove after the fact.
If a system is compromised and the compromise leaves no reliable on-chain trace, post-mortem analysis hits a hard limit. The question “Was it exploited?” may not have a satisfying answer no matter how thorough the investigation.
This changes what security investment is worth making before an incident occurs. For systems where post-hoc detection is limited, the only reliable option is raising the bar proactively: formal verification, supply-integrity mechanisms, turnstile-style accounting bounds, emergency disablement paths, and repeatable audit processes designed to find problems before adversaries do.
Why This Case Is Different
Serious bugs in complex software are not new. The crypto ecosystem has seen smart contract exploits, bridge failures, wallet vulnerabilities, consensus issues, and protocol-level bugs before.
What makes the Orchard case different is the discovery mechanism — and specifically what the discovery reveals about how that mechanism is changing.
The vulnerability survived years of expert review, multiple pre-activation audits, and scrutiny from some of the strongest cryptographers in the field. It was found by a skilled researcher who built a custom audit framework around the Zcash codebase and ran it with a frontier AI model. The model helped work through the circuit logic, identify the weak point, reason through the exploit algebra, and validate exploitability. The researcher noted that Opus 4.8 worked out the exploit algebra entirely autonomously, with only minor human guidance on engineering details.
The operator still had to build the framework, point it at the right code, understand the system, interpret the finding, and drive the disclosure process. The hard parts of security research — knowing what to look for, understanding the system, validating that a finding is real — remained human work. What AI changed was the distance between a suspicion and a proof. In this case, it compressed that journey significantly.
AI-Assisted Auditing Is Not Push-Button Security
It would be easy to read this story as "AI found a critical bug humans missed." That framing is incomplete in a way that matters. The discovery did not come from a generic prompt. It came from a custom audit framework that gathered all relevant code, specifications, security properties, and failure modes, then deployed specialized agents against structured checklists. The model was a powerful component of a deliberately engineered process.
That distinction matters because many AI-assisted security tools in the market today still struggle with application context, business logic, and domain-specific risk. General-purpose agent wrappers — products that layer orchestration over commodity AI models — can surface issues, but the highest-value vulnerabilities in crypto often live in the relationship between code, protocol assumptions, economic incentives, and cryptographic invariants. Finding those requires a harness that understands the domain, not just a model that understands code.
The Orchard case is better read as a demonstration of what is possible when a skilled operator builds a purpose-built, domain-aware harness and runs it with a frontier-capable model. The right auditing model for organizations now is human-directed, AI-assisted, and repeatable.
New Model Releases Are Security Events
One of the most operationally significant elements of the Orchard timeline is the gap between the flaw’s existence and its discovery. The bug lived in the codebase for over four years. It was found approximately four days after Opus 4.8 was released.
The data point that sharpens this is the Opus 4.7 comparison. The researcher had previously run the same audit framework against the same codebase with Opus 4.7. That run did not find the bug under generic prompting — Opus 4.7 could find it only when directed very specifically at the scalar multiplication gadget. Opus 4.8 surfaced the bug in roughly one in four runs under generic prompting. The harness did not change. The operator did not change. The model did. That delta is what makes frontier model releases a security event, not just a product update.
If a new model is better at code reasoning, formal logic, cryptographic relationships, or long-context analysis, it changes what is discoverable — for defenders running structured audits and for adversaries scanning public repositories, protocol specifications, audit reports, and circuit libraries. Both have API access. Only one has an incentive to disclose.
For teams responsible for critical crypto infrastructure, major frontier model releases should prompt targeted review of high-risk components. Teams do not need to restart every audit from scratch on each release, but they can maintain repeatable review workflows that can be re-run against consensus-critical code when capability jumps occur. They can also plan for heightened vigilance — across security, engineering, communications, and incident response — in the period following major releases.
What Crypto Teams Can Do Now
The Orchard case is the optimistic version of AI-assisted vulnerability discovery. A defender found the bug first, disclosed it responsibly, and the ecosystem responded quickly. The more likely version in the next incident is an attacker finding the same class of bug first and never telling anyone.
Crypto teams can take several practical lessons from this case:
Treat frontier model releases as security triggers. If your team maintains consensus-critical code, ZK circuits, bridges, wallets, L2 infrastructure, or cryptographically sensitive systems, major AI model releases should prompt targeted review of high-risk components.
Reassess previously audited code. A past audit does not mean a system is permanently safe. Tooling changes, model capabilities change, threat models change, and certain bug classes become significantly easier to search for as AI capabilities improve.
Systematically hunt under-constrained logic. Teams building ZK circuits should identify security-critical values and verify they are explicitly constrained. Any value that is witnessed privately but assumed to be correct deserves scrutiny — the Orchard bug is the clearest possible example of what happens when that assumption goes unchecked.
Use AI and formal methods together. AI can generate hypotheses and expand review coverage, but formal verification, SAT solving, fuzzing, and human review remain essential for validating whether a finding is real and understanding its full impact.
Build emergency response paths before they are needed. The Zcash response moved quickly because there was a pre-existing path to disable and later restore the affected component. Teams should know in advance how they would pause, disable, upgrade, or isolate critical functionality during a high-severity incident.
Do not dismiss AI skepticism about its own findings. In this case, the model was repeatedly skeptical that it had found a genuine bug, assuming heavily audited upstream code was likely correct. That skepticism nearly caused the finding to be dismissed. AI findings involving under-constraint, soundness, or invariant violations in well-audited code deserve human follow-through, not reassurance-based dismissal.
The Orchard vulnerability is a marker of a new phase in security competition. AI-assisted tooling is making deep vulnerability discovery more accessible, more repeatable, and faster. The defensive advantage that comes from getting there first is real — but it is not permanent, and it does not accrue passively. It has to be actively claimed.
About the Author:
Tiago Assumpcao is the Technical Director of Threat Intelligence Engineering at Crypto ISAC. With over 25 years in cybersecurity, his career demonstrates a clear trajectory: from pioneering exploit defenses in the early 2000s to shaping the security posture of today’s crypto ecosystem. He has contributed to foundational memory protection mechanisms, served as an editor at Phrack, and led security initiatives at BlackBerry, IOActive, and Coinspect. His work spans from pioneering exploit defenses to securing digital asset ecosystems against systemic risks and nation-state threats. He recently participated as a panelist at Upbit D Conference and DeFi Security Summit.
About Crypto ISAC
The Crypto ISAC is a member-driven, not-for-profit organization that works together to curb malicious actors, address vulnerabilities, share intelligence, and move security forward to protect the crypto ecosystem. We are founded by leading crypto organizations and designed for cryptosecurity experts to address the security and trust challenges that face crypto today and shape the crypto ecosystem of tomorrow.
