AI found a bug hidden in Zcash, and that changes how crypto code gets audited

A hidden flaw inside privacy software is the kind of problem that keeps protocol engineers awake. The Zcash bug at the center of this story matters not just because of what was found, but because of who, or rather what, helped point humans toward it: an independent researcher working alongside Anthropic's Claude Opus 4.8 model.

Why did the Zcash bug get so much attention?

Zcash is not a meme coin and it is not a toy network. Since its 2016 launch, it has been one of crypto's most ambitious privacy projects, built around zero-knowledge proofs, which are famous for being powerful and hard to implement correctly. The specific flaw sat in Orchard, the newest shielded pool, and had been live since May 2022, so it survived roughly four years and multiple expert audits before anyone caught it.

That is why the phrase "AI found a bug in Zcash" travels so fast. If an AI-assisted review can help surface a problem in a codebase this dense, readers immediately ask the obvious question: what else can these tools catch in other open-source systems, from clients to smart contract code? The market reaction was just as sharp, with ZEC falling more than 25% in the 24 hours after disclosure.

If you want a quick backgrounder on the asset itself, AhoraCrypto keeps a simple profile for ZEC. The bigger story, though, is about software assurance, not price.

What exactly was found, and what did AI actually do?

The discovery is credited to Taylor Hornby, an independent security researcher engaged by the nonprofit Shielded Labs in April 2026 to probe the protocol for vulnerabilities. On 29 May he flagged the issue and disclosed it that evening to engineers at the Zcash Open Development Lab (ZODL), who confirmed it within hours.

What he found was a soundness bug in the Orchard zero-knowledge proof circuit, specifically an under-constrained element in the halo2_gadgets code. In plain terms, mathematically invalid inputs could pass an elliptic-curve check that was supposed to reject them. The practical risk: an attacker could forge counterfeit ZEC inside the shielded pool, and because Orchard hides amounts by design, those coins would be effectively undetectable. Notably, the flaw did not let anyone inflate Zcash's headline total supply directly, but the prospect of undetectable counterfeiting within the pool is exactly why it was treated as critical.

The key distinction is easy to miss. AI did not magically secure Zcash on its own, and it did not replace an auditor. Hornby used Anthropic's Claude Opus 4.8 model, released just a day before, alongside a custom AI tool to run a highly targeted review of the Orchard circuit. The model acted more like an aggressive code reviewer, scanning for suspicious logic, odd edge cases, or places where assumptions no longer held.

That matters because a code audit is usually slow, expensive, and limited by human attention. A model can inspect huge amounts of text and code without getting tired, but humans still did the decisive work: Hornby wrote a complete proof-of-concept exploit that generated counterfeit ZEC in a local test environment, engineers reproduced and confirmed it, and the team decided how to patch it safely.

So the useful headline is not "AI replaces security teams." It is closer to this: AI can be a fast first-pass reviewer for ugly, complex code, especially where the cryptography is subtle and the room for human error is large.

Why is Zcash such a hard place to find bugs?

Because privacy systems hide data by design. Zcash does not work like a plain public ledger where every amount and address is easy to inspect. Pools like Orchard rely on shielded transactions, meaning transactions protected by advanced cryptography (Orchard uses the Halo2 proving system) so outsiders cannot trivially read the details.

That makes debugging harder. Engineers are not only reviewing ordinary payment logic, they are also reviewing mathematical proofs, circuit constraints, and the boundaries between trusted assumptions and real-world software. This bug lived in exactly that seam, a single under-constrained check inside the proof circuit, which is why it slipped past years of human review.

For comparison, you can read the general project overview at Zcash and the public repository at the Zcash GitHub. Open code helps, but open code does not make hard code easy.

Does this mean AI is better than human auditors?

No, and that is where the story often gets distorted. AI is good at pattern matching, summarising large codebases, and flagging inconsistencies. It is much worse at understanding economic incentives, deployment context, and whether a theoretical issue matters on a live network. Worth remembering: the Orchard circuit had been reviewed by expert cryptographers for four years before an AI-assisted pass narrowed in on the flawed constraint.

A human reviewer can ask the messy questions. Could an attacker chain this bug with another one? Does the patch break wallet compatibility? Will users need a network upgrade, or a hard fork if the fix changes consensus rules? In this case the answer was yes, which is why the response ran through both a soft fork and a hard fork.

You have already seen a version of this in other ecosystems. Developers around use static analysis tools, fuzzing, formal verification, and layered reviews for the same reason: no single method catches everything.

What does this change for privacy coins and open-source security?

First, it lowers the stigma around saying software needs more review, even when the project is mature. Zcash has been studied for years, and that is exactly why this episode lands so hard. A long-lived codebase can still contain old assumptions, brittle edges, or forgotten interactions. The response itself shows how seriously the team took it: an emergency soft fork on 2 June (around 02:00 UTC, at block height 3,363,426) temporarily disabled all Orchard transactions, then the NU6.2 hard fork on 3 June (block height 3,364,600) re-enabled Orchard with a corrected circuit. Sapling and transparent transactions kept working throughout.

Crucially, developers say there is no evidence the bug was exploited on mainnet, but because the pool hides amounts, this cannot be fully proven cryptographically. That is why Shielded Labs has proposed a further network upgrade that would let anyone verify ZEC's supply has not been secretly inflated, an honest acknowledgement that "no observable harm" is not the same as "provably no harm."

Second, it may change how teams budget security work. Instead of paying only for periodic audits, projects may run AI-assisted review continuously between releases, then escalate suspicious findings to specialists. If you follow broader security guidance, AhoraCrypto's page on security is a useful companion read.

Third, it sharpens the case for open source. A closed codebase might also benefit from AI, but the crypto ecosystem works best when outsiders can inspect, challenge, and verify what maintainers claim. That is part of why Zcash keeps attracting serious technical attention rather than pure speculation.

What should you remember when a headline says AI found a crypto bug?

Start with three checks. One, was the issue confirmed by maintainers or independent researchers? Here, ZODL engineers confirmed Hornby's finding within hours. Two, was it a theoretical flaw or something exploitable on mainnet? In this case it was a working exploit in a test environment, with no confirmed mainnet abuse. Three, did the team explain the fix in public, with enough detail for outsiders to evaluate the response? Shielded Labs and the Zcash Foundation published the disclosure, the two-stage fork response, and a follow-up supply-verification proposal.

Then remember the broader lesson. Strong cryptography is not the same thing as flawless software. Whether you use privacy coins, read about cryptos, or just watch the sector from the edge, trust should come from transparent processes, not from slogans about perfect tech.

That is the real significance of the Zcash bug story. AI may help find the crack, but people still have to decide whether the wall is sound.