Zcash Orchard Vulnerability

In June 2026, Zcash disclosed a critical bug in Orchard, its newest shielded transaction pool, that could have let an attacker create counterfeit ZEC without anyone being able to detect it. This page is not a referendum on Zcash. It uses the incident as a concrete lens on a design choice every cryptocurrency makes: how much of the ledger to make publicly verifiable, and what privacy you trade to get there. Bitcoin and Zcash sit at opposite ends of that choice, and the Orchard bug is where the consequences of each end become visible.

What happened

On 29 May 2026, security engineer Taylor Hornby found a soundness flaw in Orchard's zero-knowledge proof circuit during an audit for Shielded Labs; the discovery was, by the authors' account, assisted by an AI model.1 The bug had been present since Orchard activated in 2022, meaning it sat latent for roughly four years. Once it was understood, Zcash's contributors moved quickly: the Zcash Open Development Lab describes a coordinated network upgrade launched on 1 June 2026 that paused Orchard transactions while a fix was built and tested, with remediation reported complete within days.2 The disclosure itself followed on the heels of the patch, and ZEC's market price fell sharply over the following day as the news spread.1

The bug: when the proof is the only check

To spend shielded ZEC, a user submits a zk-SNARK — a zero-knowledge proof that the transaction follows the rules (the inputs exist, the amounts balance, nothing is created from nothing) without revealing the sender, receiver, or amount. The property that makes this safe is soundness: the circuit must accept only genuinely valid transactions. The Orchard bug broke soundness. An under-constrained step in the circuit — part of an elliptic-curve point calculation that failed to fully pin down its inputs — could let a crafted, invalid transaction pass verification anyway, which in principle would let an attacker mint ZEC inside the shielded pool.1

Wei Dai, reviewing the disclosed flaw, noted that it "looks obvious in retrospect" yet was missed by highly capable protocol designers, cryptographers, and auditors — his point being that this class of error is genuinely hard to catch by inspection.3 The deeper problem is structural, not a single oversight. In a fully shielded design, every ordinary signal that would otherwise flag an invalid transaction — the amounts, the balances, the linkage between inputs and outputs — is encrypted by design. As Blockstream put it in its analysis, "the proof is the only check there is."5 When the proof system has a soundness bug, there is no second line of defense, and no way to look back through the shielded history to tell whether the bug was ever exploited.

Bitcoin's opposite choice: a publicly verifiable supply

This is where the design contrast sharpens. Bitcoin keeps its ledger fully transparent: every transaction's amounts are public, and every full node independently re-checks the emission schedule and the 21-million-coin cap on every block. A coin minted from nothing would not be a hidden flaw — it would be an immediate, visible consensus violation that every node would reject.5 Bitcoin gets this auditability precisely because it gives up the on-chain privacy that Orchard provides.

Bitcoin's own history shows the difference in failure mode. It has shipped supply-affecting bugs of its own — the 2010 "value overflow" incident briefly created roughly 184 billion BTC,6 and the 2018 CVE-2018-17144 bug could have allowed inflation or double-spends.7 But in both cases the transparency of the ledger is what made the problem tractable: the 2010 overflow was a glaring anomaly that was diagnosed and undone within hours,6 and the 2018 flaw was caught and patched before anyone exploited it, with the public UTXO set available to confirm afterward that supply was intact.7 In a transparent system you can verify, after the fact, that the books still balance. In a fully shielded pool you cannot — which is why, even after Orchard was patched, the question of whether fake notes were ever minted remains open by construction.5

A spectrum, not a binary

It would be a mistake to read this as "transparency good, privacy bad." Orchard's shielding is not an accident to be apologized for; it is the feature Zcash exists to provide, hiding sender, receiver, amount, and the links between transactions. The honest framing is a spectrum of trade-offs:

• Full privacy (Orchard): hide everything. Strongest confidentiality, but supply integrity rests entirely on the correctness of one complex circuit.
• Selective privacy (for example, Liquid's Confidential Transactions): hide the amounts while still letting the network publicly verify that inputs and outputs balance, so total emission stays independently checkable.5
• Full transparency (Bitcoin): hide nothing on-chain; anyone can audit the entire supply continuously, at the cost of financial privacy.

Blockstream — which builds Bitcoin and Liquid infrastructure and so argues from a clear vantage point — frames the lesson as a general principle: a system whose supply soundness depends on "an exotic, highly complex zk-SNARK circuit will always have a longer tail of latent failure modes than a protocol where the supply is enforced by a simple public balancing check."5 That is a real engineering observation about complexity and attack surface. It is also an argument made by an interested party, and it does not weigh the privacy that the shielded design buys — which users who choose Zcash value precisely because Bitcoin does not offer it. Whether the two goals can be reconciled, or trade off against each other irreducibly, is the genuinely open question.

Restoring a verifiable supply without giving up privacy

Zcash's proposed answer tries to have both. Shielded Labs, with the Zcash Foundation and the Zcash Open Development Lab, proposed Ironwood, an upgrade that migrates funds out of the compromised Orchard pool into a new shielded pool through a "turnstile" — an accounting boundary that exposes the aggregate amount crossing between pools without revealing individual transactions. After the migration, any user running the software could sum balances across pools and check that the total ZEC supply has not been secretly inflated, rather than trusting a team's assurance.4 The aim is to re-introduce an independently verifiable supply bound while keeping transaction-level privacy intact — in spectrum terms, edging from "full privacy" toward a more "selective" position where supply, but not individual payments, becomes auditable.

The lesson still being argued

Beyond Zcash specifically, the incident reopened a methodological debate. Wei Dai's reaction frames it directly: if a soundness bug this consequential could be written by expert designers, survive expert audits, and live for four years, then human review may not be a sufficient guarantee for circuits of this complexity, and formal verification — machine-checked mathematical proof that a circuit is constrained correctly — may be necessary rather than optional.3 That argument applies wherever soundness rests on a single complex proof system, which is an increasingly common design well beyond Zcash.

The throughline is that Bitcoin and Zcash made deliberate, opposite bets about what to make public. Each bet buys something real and gives up something real. The Orchard bug did not prove one bet wrong; it made the cost of the privacy bet concrete, and the cost of the transparency bet — the lack of on-chain privacy — is the one Zcash set out to avoid in the first place.