On May 29, 2026 an auditor reported a soundness vulnerability in the circuit underpinning Zcash's current shielded protocol. Four days later the network had disabled that protocol entirely by consensus rule rather than by request, and Orchard stayed disabled for 1,174 blocks before a corrected circuit restored it.
The incident is unusually well documented, which is what makes it worth reconstructing: a Final ZIP records the deployment retrospectively, the Foundation published its own account, and the corrected circuit is visible in a public crate release.
It is also documented inconsistently on the one question readers actually care about, which is whether anybody's money was ever in danger. Two authoritative sources scope that risk differently, and both are correct.
What was found, and by whom
The discovery was neither an accident nor an attacker. It came out of a commissioned audit, which matters for how everything after it is read: the project was already looking, it found something, and the finding arrived through a channel built to receive it rather than through a balance that had already moved.
The specification documenting the deployment is precise about the circumstances. On May 29, 2026, ZIP 257 records that "security researcher Taylor Hornby, who had been tasked with an AI-assisted security audit of the Orchard shielded protocol, reported a soundness vulnerability in the Orchard Action circuit implementation" (source: ZIP 257).
The Zcash Foundation's own account of the emergency adds the commissioning party, describing Hornby as an independent security researcher conducting an ongoing protocol audit on behalf of Shielded Labs.
Two details in those sentences deserve attention. The audit was ongoing rather than one-off, so the review was a standing process rather than a reaction to suspicion, and the finding therefore represents the process working rather than an anomaly being chased.
The second is the ZIP's phrase "AI-assisted", which is the project's own characterization of the audit methodology, recorded in a consensus document rather than in marketing material. That is a notably early instance of the description appearing in the deployment record of a live protocol, and it is worth registering without drawing conclusions from it.
A third detail is worth stating because its absence is what makes everything below possible: there was no attacker. The record describes a finding, not a breach, and every subsequent decision was made with the flaw still private.
Our guide to how a blockchain's rules get changed covers the mechanism the response below depends on.
What the bug actually was
The vulnerability was a soundness failure, which is a specific category and not a synonym for a bug. A proof system is sound when a proof that verifies implies the statement it claims is true. A soundness failure means a proof can verify for a statement that is false, so the verifier accepts something it should reject.
ZIP 257 names the component. The corrected version fixes "the Orchard Action circuit's variable-base scalar multiplication gadget", and that correction "changes the Orchard verifying key".
Both halves of that sentence matter. The defect was in a gadget deep inside the arithmetic circuit rather than in the surrounding node software, so no configuration change or client patch could route around it while leaving the protocol intact. And because fixing it changed the verifying key, the old and new circuits are not interchangeable: proofs produced under one do not verify under the other.
The public API records that split without euphemism. The orchard crate exposes an enumeration selecting the circuit version, with the two variants named InsecurePreNu6_2 and FixedPostNu6_2, shipped in version 0.14.0 on June 2, 2026 (source: orchard changelog).
Naming the insecure variant in a public API rather than deprecating it quietly is a deliberate choice, and it is necessary rather than merely honest: historical proofs still have to verify under the original key for the chain's own history to validate, so the insecure circuit cannot simply be deleted.
What these circuits are proving in the first place is assumed here rather than explained; the privacy article in this series carries it, and our guide to public and private keys covers the key vocabulary underneath it.
Whether funds were ever at risk
This is the question the node exists to answer, and answering it honestly takes two parts rather than one. The two authoritative accounts scope the danger differently, both are correct, and reading either one alone produces a conclusion the record does not support in that form.
The consensus document states the severity flatly. ZIP 257 records that the vulnerability "could have allowed balance violation and theft of funds. Therefore, it was imperative to immediately disable use of Orchard, until a corrected Orchard Action circuit could be deployed".
The Foundation's account bounds the same danger more narrowly. Exploitation "could have allowed the Orchard pool to accept invalid state transitions, potentially permitting double-spending of funds within Orchard, though with no ability to inflate the total ZEC supply, which is protected by Zcash's turnstile mechanism" (source: Zcash Foundation).
Read together rather than separately, the two say: theft from inside the pool was possible in principle, inflation of the total supply was not. The turnstile is an accounting constraint that tracks value across pools, so a forged Orchard state transition could have moved value that was already inside Orchard without conjuring value that never existed.
And the same source reports the outcome: the turnstile mechanism "confirmed that the total supply remained intact throughout". No source claims the vulnerability was exploited, and this article does not either.
The turnstile itself, what it counts and why it exists, belongs to the shielded-pools article in this series. The safety article places this incident next to the project's earlier disclosure.
How the network responded, in two deliberate stages
The response is the most instructive part of the record, because the sequencing was a deliberate choice rather than an accident of timing, and the specification explains the reasoning in writing rather than leaving it to be inferred by anyone reading the commit history afterwards.
Stage one disabled the affected protocol without fixing it. The consensus rule reads that from block height 3363426 on Mainnet, "until the activation of NU6.2", transactions of version 5 and later "MUST NOT contain any Orchard Action descriptions", and ZIP 257 records that the mitigation "was deployed as an emergency hotfix in zcashd v6.12.5 and zebra v4.5.3". In practice that prohibited "both the creation of new Orchard outputs and the spending of existing Orchard funds" (source: ZODL).
Stage two replaced the circuit. NU6.2 "successfully activated at block 3,364,600 on June 3, 2026" and "permanently patched a critical vulnerability in the Orchard zero-knowledge proof circuit while restoring full shielded functionality" (source: Zcash). Subtracting the two heights gives 1,174 blocks between disablement and restoration, which is arithmetic on the record rather than a measured duration.
Why not do both at once? The specification answers directly: combining them "was ruled out due to the risk of revealing the vulnerability before it had been mitigated, and in order to close the vulnerability window more quickly, while the fix was still being prepared and reviewed".
That is a real trade recorded in a consensus document rather than reconstructed afterwards. Shipping a fix reveals the flaw to anyone who reads the diff, so the project chose to freeze first and repair second, accepting that users lost access to shielded functionality throughout the interval between the two stages.
Our guide to what proof of work is covers why the operators in the next section have to act at all, and our guide to nodes, miners and wallets covers who those operators are.
The mining pools that missed the first attempt
One detail in the record is easy to skip past, and it is the most practically interesting line in the whole incident, because it shows what an emergency consensus change actually costs to coordinate among operators who answer to nobody in particular.
The first attempt did not take. ZIP 257 records that an earlier release "had used a Mainnet activation height of 3363366, 60 blocks earlier. Some mining pools failed to upgrade in time, so the activation was re-attempted successfully at the height given above".
The Foundation's account fills in what those two attempts looked like from the outside. Private coordination with miners and exchanges began on the evening of Sunday May 31, a first activation attempt "encountered coordination challenges during patch deployment", and a second patch targeting height 3,363,426 activated at approximately 02:00 UTC on June 2. ZODL's own write-up adds that a brief period of instability followed while mining power upgraded and converged on the new rules, with stability restored a little over an hour later.
Sixty blocks of margin was not enough for every pool to deploy a hotfix, so the height was moved and the soft fork activated on the second attempt. Nothing about that is a failure of the protocol. It is the ordinary friction of getting independent operators, in different time zones and on different release schedules, to run new software on a weekend at short notice.
It is also the part that generalizes beyond this incident. The cryptography was corrected within days by a small number of people who understood the circuit in detail. The coordination took two attempts, and coordination is the constraint that does not improve with better mathematics or with a larger security budget.
Any protocol that can be repaired by consensus rule inherits this cost, because the repair is only as fast as the slowest operator whose participation the rule requires.
The deployment's discussion record is public in the specification repository, filed as the issue the ZIP names for discussion (source: zcash/zips issue 1293). Our guide to how mining works covers what those pools do the rest of the time.
What this incident leaves unshown
Four conclusions the record does not support, each of them a reasonable thing to infer from a headline about a critical vulnerability in a privacy protocol, and each of them contradicted by something specific in the documentation rather than merely unproven.
Taking them in the order a reader is likely to reach them.
It does not show that funds were stolen. No source in the record claims exploitation, and the turnstile evidence points the other way. The severity language describes what was possible, not what occurred.
It does not show that the proof system is unsound as a design. The protocol specification's own disclosure note draws that line explicitly: the pre-NU6.2 circuit "had a soundness bug in its variable-base scalar multiplication gadget", and "the bug is in the circuit implementation only; the Action statement specified above is as intended" (source: Zcash Protocol Specification). The specified statement was correct and the implementation of it was not, which is a distinction with real consequences for how much of the system a reader should distrust.
It does not show that shielded value can be inflated. That specific outcome was excluded by an accounting mechanism that operates outside the circuit, which is why the two sources scope the risk differently without contradicting each other.
And it does not show that a disabled protocol is a broken one. Orchard was switched off deliberately, by consensus rule, with the off-switch itself shipped as a soft fork, and then switched back on with a corrected circuit 1,174 blocks later. That sequence is what a working incident response looks like, and it is more informative about the project than the bug is. Our guide to reading a block explorer covers how any of these heights can be checked independently.
Why an unexploitable-looking flaw still mattered
The most misunderstood part of this episode is why the response was so drastic when no funds were lost. The answer is about what could not be established rather than about what happened.
A soundness flaw in a shielded circuit permits creating value that does not exist. On a transparent chain, that would be visible: anyone could total the outputs and find the discrepancy. On a shielded pool, the amounts are not published, so the same discrepancy is invisible from the outside by design.
The chain does track value crossing into and out of each pool, which means counterfeiting cannot be extracted from a pool without exceeding what legitimately went in. That is the property that bounded the damage. But it does not reveal whether counterfeit value was created and is still sitting inside.
So the honest position after the disclosure was that exploitation was believed unlikely and could not be ruled out by inspection. That is an uncomfortable place for a monetary system to be, and it explains both the speed of the disabling change and the design of the eventual fix, which sealed the affected pool behind a gate rather than asking anyone to accept the assessment.
The general lesson applies to every privacy system. Confidentiality and public auditability trade against each other directly, and a design that chooses confidentiality accepts that certain classes of failure cannot be diagnosed by looking. The mitigation is not more careful looking; it is architecture that bounds the damage regardless.
What the response demonstrated about the process
Three things worth recording, because they are the evidence a reader can use when weighing protocol risk generally.
The flaw was found by an audit rather than by an attacker. That is the outcome the whole practice of auditing exists to produce, and it is worth noting that it worked here after several years of the flaw being present.
The response was staged deliberately rather than rushed. Disabling came first because it is a smaller and more reviewable change than correcting under pressure, and the correction followed once it could be reviewed properly.
And the first activation attempt failed, publicly, because some operators had not upgraded in time. That is the part most accounts omit, and it is the most informative: a decentralized network moves at the speed of its slowest large participant, and no amount of urgency changes that.
What a holder should take from it
Four conclusions the record supports, and one it does not.
Protocol risk on this chain is real and has materialized once. That is a more useful statement than any general reassurance, and it is checkable against the public record rather than resting on anyone's judgment.
The response behavior was good. Disclosure carried dates, the fix was staged, the eventual architecture removed the need to trust an assessment, and all of it was published in enough detail to reconstruct years later.
The failure that reached individuals was software abandonment rather than cryptography. Holders running maintained wallets experienced a period of unavailability. Holders running abandoned software had a genuinely difficult time, and that pattern repeats on every chain.
Availability is a risk in its own right. For a period, funds that were entirely safe could not be moved, and for some holders that mattered more than the theoretical exposure did.
What the record does not support is any conclusion about whether this chain is more or less defect-prone than alternatives. One incident is one data point, and comparing defect records across projects with different audit intensities and different disclosure norms is not a comparison at all.
Frequently asked questions
Was any ZEC actually stolen in the 2026 Orchard incident?
No source in the public record claims that it was. ZIP 257 describes what the vulnerability could have permitted, which is balance violation and theft of funds, and severity language of that kind describes capability rather than events. The Zcash Foundation reports that the turnstile mechanism, which tracks total ZEC across value pools, confirmed the total supply remained intact throughout. That is evidence about supply rather than a full audit of every transaction, and it is the strongest statement the record supports.
Why was Orchard disabled before the fix was ready?
Because shipping a fix would have disclosed the flaw. The specification states that disabling the vulnerable circuit and enabling the corrected one simultaneously was ruled out due to the risk of revealing the vulnerability before it had been mitigated, and in order to close the vulnerability window more quickly while the fix was still being prepared and reviewed. Freezing first cost users access to shielded functionality for 1,174 blocks, and the alternative was a longer exposure window with the flaw publicly visible.
What does a soundness vulnerability in a circuit mean?
Soundness is the property that a proof which verifies implies the proven statement is true. A soundness failure means a verifier can accept a proof for a false statement. In this case the defect sat in the Orchard Action circuit's variable-base scalar multiplication gadget, and correcting it changed the verifying key, so proofs created under the original circuit do not verify under the corrected one. The public crate names the two versions explicitly rather than hiding the distinction.
Could the same class of bug affect the shielded pools again?
Nothing in the record rules it out, and the incident is evidence about process rather than about future immunity. What the record does show is that a commissioned, ongoing audit found the defect, that the network could disable an entire shielded protocol by consensus rule within days, and that the coordination step needed two attempts because some mining pools did not upgrade in time. The safety article in this series carries the project's wider disclosure history.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash Improvement Proposals repository, the Zcash project's upgrade documentation, the Zcash Foundation's incident account and the orchard crate's published changelog. All facts independently verified against cited documentation current as of August 2026. This article makes no claim that the vulnerability was exploited and contains no price figure.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Do your own research before making any decision.