The Zcash Orchard bug, explained — what a zero-knowledge soundness flaw means for privacy coins

What happened, in order

Zcash's Orchard pool is its newest shielded pool — activated in May 2022 (network upgrade NU5), built on the Halo 2 proving system, and designed specifically to remove the trusted-setup risk that haunted Zcash's earlier pools. In late May 2026, security researcher Taylor Hornby — hired by Shielded Labs for exactly this kind of proactive audit — found a soundness bug in the Orchard circuit. The day after Anthropic released Claude Opus 4.8, he used it inside a custom auditing harness and produced a working proof-of-concept: in a local regtest environment running the same rules as mainnet, he repeatedly doubled a note's value until a wallet held more than 10 million ZEC. The proof verified. The network would have accepted it.

From discovery to permanent fix: about five days, no chain split, and an unusually candid public write-up. Keep that response quality in mind — it matters for how you read the rest.

The bug in plain terms

A zero-knowledge proof lets you convince a verifier that a statement is true — "this transaction is valid" — without revealing the secrets behind it (amounts, sender, receiver). For that to be safe, the proof system must have soundness: it must be impossible to produce a valid-looking proof for a false statement.

The Orchard flaw was an under-constrained gadget — specifically in the variable-base elliptic-curve scalar-multiplication code that the circuit relies on. In plain language: the circuit forgot to fully pin down one of the mathematical relationships it was supposed to enforce. That left a gap a prover could drive arbitrary secret values through and still satisfy every check the verifier ran. Soundness broke. The proof system would accept invalid state transitions — phantom notes, inflated balances, in-pool double-spends — as if they were legitimate.

One precision note for credibility: this was not a hole in the high-level protocol spec but a gadget-level bug in the underlying proving library — a common and notoriously subtle class of zero-knowledge implementation error. Scalar-multiplication gadgets are some of the hardest things in a circuit to constrain completely, which is exactly why top cryptographers and prior audits missed it for four years.

Why "no inflation" and "serious" are both true

The headline reassurance was accurate: total ZEC supply was never inflated, and no user funds were stolen. But the more careful framing — "the bug created no extractable inflation, yet balance integrity inside the Orchard pool became briefly unprovable" — is the part that actually moved the market, and it is worth understanding.

• What the bug could do: create invalid state transitions inside the shielded pool — fake notes, inflated internal balances. Because the pool is private by design (amounts and participants hidden, proofs zero-knowledge), there is no way after the fact to cryptographically prove or disprove that anyone exploited it during the four-year window.
• What the bug could not do: pull that phantom value out of Orchard into transparent ZEC or expand the visible monetary base. That is the turnstile's job (next section), and it held.

So for a coin that markets itself as private sound money, the residual problem isn't "someone drained the treasury." It is that the integrity of the private pool's internal accounting rested entirely on a circuit that turned out to be broken — and you can't audit a private pool by summing it. That unknowability, not a confirmed theft, is what holders sold. Shielded Labs has since said it is exploring a new shielded pool with enforced migration accounting so that supply integrity becomes publicly verifiable going forward, plus formal verification of the circuit.

The turnstile: the unsung hero

Zcash's turnstile is a consensus-level accounting invariant between its value pools (transparent, the legacy Sprout and Sapling shielded pools, and Orchard). The rule is simple and brutal: every shielded transaction reveals the net amount entering or leaving a pool, the chain tracks each pool's running balance, and any block that would drive a pool's balance negative is rejected.

This is defense-in-depth layered on top of the zero-knowledge proofs, and it is precisely what contained this bug. An attacker minting fake notes could inflate balances inside Orchard, but the moment they tried to deshield that value out, the transaction's declared pool outflow would exceed everything that had ever legitimately entered — and consensus would reject it. The turnstile acts like a blast door: a soundness failure in one pool can't leak into the global supply. That is why every credible report could honestly say "no supply inflation, no funds stolen," while still being unable to certify the pool's internal history.

The deeper lesson: circuit soundness vs Monero's model

It's tempting to read this as "zero-knowledge bad, Monero good." That's not the honest takeaway. The honest takeaway is about where each design concentrates its risk.

Orchard was itself a response to a valid earlier criticism of Zcash: its first pools used a proving system requiring a trusted setup, where a compromised setup ceremony could enable undetectable counterfeiting forever. Halo 2 removed that trusted setup. But this incident shows the cost of that trade: with no trusted setup, the implementation of the circuit must be perfectly sound — every gadget, every constraint, every elliptic-curve operation. A single under-constrained relation anywhere breaks the entire guarantee, and those gadgets are extraordinarily hard to get exactly right.

Monero makes a different bargain. It has no single circuit that must encode the whole validity relation. Its privacy comes from more direct algebraic machinery: Pedersen commitments plus range proofs hide amounts (RingCT), ring signatures provide signer ambiguity against decoy outputs, stealth addresses make every output a one-time key, and key images prevent double-spends. Fewer abstraction layers sit between "the transaction is valid" and "the math checks out," which means a smaller surface for this specific class of "forge value via a broken circuit" bug.

• Zcash shielded (Orchard): strong theoretical privacy — amounts, sender, receiver, and memo fully concealed, a growing in-pool anonymity set — at the cost of having to keep a very complex constraint system 100% correct and re-audited on every change. Privacy is also optional, with a transparent fallback.
• Monero: mandatory, default-on privacy with practical strong unlinkability, at the cost of larger transactions and a different risk profile centred on decoy quality, output-selection heuristics, and ongoing primitive hardening (e.g. the in-progress FCMP++ upgrade).

Both ultimately rest on correct implementation and continuous review. ZK buys "mathematical privacy" by demanding circuit perfection; RingCT buys usable mandatory privacy with more explicit checks but its own engineering trade-offs. Neither is magic.

What Zcash got right — and what to keep honest

A neutral guide has to say this plainly: Zcash's handling was a model of responsible disclosure. The team hired a researcher specifically to hunt these bugs before attackers could; they coordinated privately with miners and exchanges; they shipped a two-phase fix in days; and they disclosed fully, explicitly refusing to claim exploitation was impossible. They said, in effect, "we cannot cryptographically rule out that this was used — don't rely on 'probably fine.'" That candour is rare and correct.

And the counterpoints that keep Monero advocates honest:

• "Simpler is always safer" is too strong. Monero has had its own historical scrutiny and its share of wallet and node bugs over the years, and its mandatory model means all value rides on its design choices with no opt-out.
• Gadget and constraint bugs are a recurring challenge across the entire ZK industry, not a Zcash-specific failing.
• The turnstile and the rapid response are genuinely impressive engineering. The market punished unknowability, amplified by leverage and at least one large public holder (Arthur Hayes) exiting with the line that privacy narratives demand "perfection, not 'probably fine.'" Monero saw only mild sympathy selling.
• Fringe "intentional backdoor" claims circulated. They are low-credibility; a neutral reader should discount them.

What this means for you

If you hold or use either coin, the practical reading:

• This is a case study in defense-in-depth, not a death notice for ZK. The turnstile did its job; the proofs didn't, and a backstop caught it. Systems that assume their own components can fail age better than ones that don't.
• "Soundness" is existential for any private money — whether it's a circuit's soundness or RingCT's algebraic soundness. Treat audit cadence and formal verification as features, not overhead.
• Mandatory vs optional privacy is a real axis. Monero's no-opt-out model is a different bet from Zcash's multi-pool, mostly-transparent reality — pick based on whether you want privacy to be the default or a choice.
• The AI-audit era cuts both ways. A defender with the right harness found in a day what four years of expert review missed. So could an attacker. Proactive, AI-assisted auditing is now table stakes for privacy protocols.

New to non-KYC privacy and trying to decide where to start? See How to buy Monero without KYC and the vetted wallet list. The point of this guide isn't to crown a winner — it's to make sure you understand what you're actually trusting in each design.