An AI found a bug in Zcash hidden for 4 years

An artificial intelligence found in two days a cryptographic flaw that four years of human review failed to detect in the Zcash privacy circuit. On May 29, 2026, security engineer Taylor Hornby, contracted by Shielded Labs, discovered a soundness vulnerability (the guarantee that a cryptographic proof is only accepted if the statement it proves is actually true) in the Orchard circuit, the heart of the Zcash shielded pool. The flaw allowed for the unlimited and undetectable minting of fake ZEC within the private pool, leaving no trace on the chain. Hornby credited Claude Opus 4.8, the Anthropic model released the previous day, as the tool that enabled him to write the functional exploit. The bug had been there since May 2022. This article is not just another hack report: it is an explanation of why a zero-knowledge circuit can hide a flaw that breaks nothing visible—there is no crash, no suspicious transaction, no way to know a posteriori if it was exploited—and why that is especially devastating for a coin whose only product is privacy. We will reconstruct the exact timeline, explain what a ZK proof does and does not guarantee, and break down the question that no patch can close: is the ZEC supply (total circulating supply) intact?

What exactly failed in the Orchard circuit?

Orchard is Zcash's latest-generation shielded pool, activated in the NU5 network upgrade in May 2022. When someone holds ZEC "in the shadows"—in the private pool, without addresses or amounts being visible—those funds live within Orchard. For that concealment to be secure, every private transaction is accompanied by a zero-knowledge proof: a mathematical demonstration that the operation is valid (the sender has the funds, money is not created out of thin air, the accounts balance) without revealing any specific data. The network does not see the amounts; it only verifies the proof and, if it passes, accepts the transaction.

The problem lay in how that proof is constructed. According to the Shielded Labs technical advisory, the Orchard circuit contained an under-constrained element: an internal multiplication operation on an elliptic curve that accepted false inputs as valid. In other words, it was possible to input arbitrary and false values into that multiplication and still have the check pass them as good.

The final fix was tiny—a missing constraint in the circuit logic—and that disproportion is precisely what is unsettling: a minute detail separated a privacy system considered robust from a money-counterfeiting machine. The flaw was not in the node software, nor in the wallets, nor in the underlying Zcash cryptography. It was in the circuit implementation, in the library of components that translates Zcash's accounting rules into verifiable mathematical constraints.

What does it mean for a flaw to be one of "soundness" and not a normal hack?

It is useful to distinguish between two properties that every zero-knowledge proof must fulfill, because the difference is at the heart of this story.

Think of the access control of a building with a turnstile (the rotating cylinder that only lets people through one by one with a valid card). The first property you expect is that whoever has a valid card can always enter: in ZK cryptography, this is called completeness. The second, more important property, is that whoever does not have a valid card can never enter, not even by manufacturing a forgery good enough to fool the reader: that guarantee is called soundness.

A soundness failure is exactly that: the turnstile lets someone through with a fake card. The mathematical proof accepts a statement that is a lie as true. In the case of Orchard, the false statement was "I have this ZEC and I am not creating it out of thin air." With the circuit broken, an attacker could construct a proof saying "these funds are legitimate" when they had actually just invented them, and the network would accept it without objection.

The practical consequence is what separates this case from a conventional hack. In a normal exploit—a contract drain, a compromised bridge—there is a trail: transactions moving funds to an address, an anomalous spike, a balance being emptied. Not here. Since the counterfeiting occurs inside the shielded pool, where by design amounts and addresses are not visible, the fake ZEC is indistinguishable from the legitimate. There is no crash, no alert, no transaction flagged as suspicious. The system works exactly as well manufacturing fake money as it does moving real money, because its job is to tell you nothing about what happens inside.

Why did an AI find it when four years of human review did not?

Taylor Hornby is no newcomer: he is an experienced security engineer, hired by Shielded Labs in April 2026 to audit the protocol. On May 28, Anthropic released Claude Opus 4.8. The following day, Hornby put it to work on the Orchard circuit with a custom harness of prompts and tools—a set of instructions and chained utilities to direct the model—focusing it on a targeted review of the circuit logic. In less than 48 hours, the system pointed out the inconsistency in the elliptic curve multiplication. Hornby then wrote a full exploit that, in a local test environment, generated unlimited and undetectable fake ZEC, confirming the flaw was real and exploitable.

Why wasn't it seen before? A ZK circuit is not readable code like a normal program. It is a system of algebraic constraints: thousands of equations that, together, must close the door to any invalid state. Verifying that no constraint is missing is radically harder than checking that the existing ones work. The code "does the right thing" in all test cases; the flaw is in the case that no one wrote, in the constraint that no one added. It is an error of omission, not commission, and errors of omission are almost invisible to human reading, tests, and classic audits, which tend to check that what is written works, not that everything that should be written is there.

This is where a language model with sufficient reasoning capacity over mathematics and code provides something that the human eye cannot scale: the patience to exhaustively traverse the space of what should be constrained and is not. It is not magic, nor does it replace the engineer—it was Hornby who directed the search and wrote the exploit—but it sets a precedent: the first critical cryptographic vulnerability of this class, in production for years, publicly attributed to the use of a frontier AI.

How was the 50-hour emergency response?

What followed the private disclosure was a two-stage surgical operation, executed in just over two days, and designed with unusual care not to give away the flaw while it was being fixed.

The problem with patching a bug of this severity in the open is one of transparency: Zcash code is public. If developers had directly uploaded the circuit fix, anyone with access to the commit could have read the fix, deduced the vulnerability it covered, and exploited it on networks that had not yet updated. A patch, to an attentive attacker, is a map of the flaw.

The solution was to decouple containment and correction in two moves:

1. Containment (soft fork). On June 2 around 02:00 UTC, at block 3,363,426, an emergency soft fork (Zebra 4.5.3) was activated that simply rejected any transaction touching Orchard. The shielded pool was frozen: no one could exploit what could no longer be used, and the patch did not reveal what was being fixed because, technically, it didn't fix anything—it just closed the door.
2. Correction (hard fork). One day later, on June 3 around 04:05 UTC, at block 3,364,600, the NU6.2 hard fork (Zebra 5.0.0) reactivated Orchard with the circuit already corrected.

The hard fork was inevitable for a technical reason: fixing a bug in a zero-knowledge circuit requires updating the fixed verification key (the cryptographic parameter against which the network validates every proof). That parameter is embedded in the consensus rules, and changing it cannot be done with a node software patch—it requires the entire network to jump to a new set of rules at the same time. Hence the network upgrade.

What does a ZK proof guarantee and what does it never guarantee?

The incident exposes a widespread misunderstanding about zero-knowledge proofs: that a "mathematically verified" proof is equivalent to an absolute truth. It is not. A ZK proof only guarantees as much as the constraints the circuit imposes. If the circuit is well-constructed, the proof is as reliable as the underlying mathematics. If a constraint is missing, the proof certifies a lie with total conviction, and it does so with the same firmness with which it would certify a truth. The cryptography is not broken; what is broken is the model of what is being demonstrated.

The following table separates what the system continued to guarantee from what it stopped guaranteeing while the flaw was live.

The right-hand column is the true extent of the damage. And the last row defines the open question of the entire case.

Why can no one know if the ZEC supply is intact?

Zcash has a mechanism called a turnstile, designed precisely to monitor accounting between pools. Every time value crosses the border between the transparent (visible) and shielded (hidden) supply, the turnstile checks that no more comes out than went in in aggregate. It is a safety net that detects gross inflation: if someone tried to take more ZEC out of the private pool than should mathematically exist, the turnstile would catch it at the border.

Here is the nuance that almost all coverage simplified. The turnstile monitors transit between pools, not what happens inside one. As long as the counterfeited ZEC remained inside Orchard, without crossing to the outside, it would be invisible to the turnstile. And if an attacker had been taking it out little by little, mixed with legitimate funds and below any conspicuous threshold, there is no cryptographic way to distinguish that exit from a normal withdrawal.

This is why two statements that seem contradictory coexist. On one hand, the turnstile confirms that no unauthorized value creation has been detected at an aggregate level, and there is no evidence of exploitation on mainnet. On the other, Shielded Labs explicitly acknowledges that, due to Orchard's privacy properties, there is no definitive way—using only cryptography—to determine if exploitation occurred. Both things are true at once: there is no proof it was exploited, and there can be no proof it was not exploited. The privacy that protects the user is the same that prevents auditing the counterfeiting.

For a privacy coin, this is existential in a way it wouldn't be for Bitcoin or Ethereum, where anyone can sum the supply by looking at the chain. Zcash's entire product is the trust that what is not seen, balances. When that trust can no longer be cryptographically verified, it remains an act of faith.

How did the market react and what is Shielded Labs proposing now?

The market reaction was immediate. Following the public disclosure on June 5, ZEC plummeted: CoinDesk reported a drop of around 38% in 24 hours, with a low near $442. Measured over a 48-hour window, other sources placed the correction close to 50%. The exact range depends on the timeframe and the exchange, but the order of magnitude—a loss of between one-third and one-half of the value in two days—is consistent across all coverage.

The real unknown is not the price, but the long-term plan. Since it cannot be cryptographically proven that the supply is clean, Shielded Labs has proposed a network upgrade more ambitious than a simple patch: creating a new shielded pool and forcing turnstile accounting on all funds migrating from the old Orchard. In practice, this would mean requiring every shielded ZEC to "pass through customs" when moving to the new pool, where its existence can be checked against the auditable supply. It is the only way to reconstruct, in a verifiable manner, an accounting truth that the flaw left in suspense. It is also a delicate operation that reopens governance debates about who decides and how such a massive change is executed in a decentralized network.

The pattern recalls other recent incidents where the problem was not cryptography itself, but the gap between what the code should guarantee and what it actually guaranteed in production. We analyzed this in the case of the Gnosis Pay ghost patch, where a fix existed in the repository but never reached the deployed contract. The shared lesson is uncomfortable: "audited" and "verified" do not mean "correct."

What lessons does this leave for ZK privacy and the role of AI in security?

The first lesson is sobering: zero-knowledge proofs are only as strong as the correctness of their circuits, and verifying that correctness is one of the most difficult open problems in applied cryptography. Every protocol that stacks privacy or scalability on ZK circuits—and there are more every day, from private stablecoins to rollups—inherits this risk surface. On-chain privacy is not a switch that is flipped; it is a property that depends on thousands of algebraic constraints all being present and correctly placed.

The second lesson points to the immediate future. That a frontier AI detected in 48 hours what years of review did not see cuts both ways. On one hand, it is a powerful defensive tool: teams that integrate models capable of reasoning about circuits into their audits will find flaws sooner. On the other hand, the same power is available to the attacker, and not everyone who finds a soundness bug will disclose it responsibly as Hornby did. The window between "a new model can find this" and "someone finds it with malicious intent" shortens with each generation.

For the privacy ecosystem—from coins like Zcash to new privacy stablecoins on ZK networks and institutional privacy roadmaps on Ethereum (2025-2029)—the episode sets a standard: auditing ZK circuits with AI assistance will no longer be optional. The case closed without verified losses and with an exemplary technical response in terms of speed, but it leaves a question that no hard fork resolves: in a system designed to tell nothing, how do you prove that nothing has broken?

Sources and links: Zcash Community Forum — The Orchard Counterfeiting Vulnerability · Zcash Foundation — Zebra 4.5.3 and 5.0.0 · CoinDesk · Decrypt · BitMEX Blog