Zcash’s June 2026 Orchard emergency upgrade was not a story about zero-knowledge cryptography failing. It was a sharper and more important lesson: a proof can verify perfectly while attesting to the wrong statement. The incident exposed the narrow seam between cryptographic soundness, circuit design and protocol-level accounting. For any builder working on private payments, the question is not merely whether a verifier accepts a proof. It is whether the proof, the chain’s state rules and the public accounting together rule out every invalid way to create or reuse value.
A privacy pool asks a blockchain to accept an unusual bargain. The chain must confirm that money was authorized, conserved and not spent twice, while learning neither the payer, the recipient nor the amount transferred within the pool.
That bargain is made possible by zero-knowledge proofs. But a proof system only proves the statement encoded in its circuit. If the circuit omits a relationship, or fails to bind two values that were meant to be the same, the prover may be able to produce a valid proof for a transaction that violates the protocol’s intended economics.
That is the core of the Orchard incident.
On May 29, 2026, security researcher Taylor Hornby found a critical soundness flaw in the Orchard shielded pool’s proof circuit during research for Shielded Labs. Zcash developers responded by temporarily disabling Orchard activity, then restoring it with a corrected circuit through the NU6.2 network upgrade. The Zcash Foundation said it found no evidence of exploitation, unauthorized value creation or user privacy loss. Yet the privacy properties that make Orchard valuable also mean the chain cannot offer a complete retrospective proof that no counterfeit shielded value was ever created while the bug existed.
The result is a useful case study for a broader industry moving toward confidential stablecoins, private settlement layers and zero-knowledge rollups. A proof that verifies is necessary. It is not sufficient. The system must also prove the right facts, connect them to the right public state, and make every economic invariant enforceable somewhere that honest nodes can check.
The sentence a shielded proof is supposed to make true
At a high level, an Orchard transaction contains one or more Actions; each Action consumes one existing shielded note and creates one new shielded note. A note is the private analogue of a coin or an unspent transaction output. It represents a claim to a value, but its amount, recipient and spending authority are hidden from the public chain.
The protocol cannot simply write, “Alice spent 4 ZEC and sent 3 ZEC to Bob.” That would defeat the purpose of a shielded pool. Instead, it publishes cryptographic objects that let every node verify a different set of claims:
A note being spent was previously committed to the shielded pool.
The spender knows the secret authority needed to spend that note.
The note has not already been spent.
The values entering and leaving the transaction balance, after accounting for fees, transparent inputs or outputs, and transfers between pools.
New output notes are correctly formed and committed to the pool.
The proof was generated under the exact circuit and verification key that consensus rules require.
A concise way to state the intended claim is this:
“I know private inputs consistent with the public transaction data, and those inputs describe an authorized, unspent, value-conserving state transition.”
The word “consistent” carries almost all of the security burden. Every required connection between secret witness data and public chain data must be constrained. A private note must be tied to a commitment. The secret must be tied to the authorized spending key. The nullifier must be tied to that exact note and authority. Value commitments must be tied to the values whose conservation the transaction claims. The transaction must be tied to a real commitment-tree root and a never-before-seen nullifier.
If any one of those bindings is absent, the proof can still verify. It just verifies a weaker statement than the protocol designers thought they had specified.
From hidden note to public state transition
To see why Orchard’s bug mattered, start with the normal lifecycle of a shielded note.
A wallet creates a note for a recipient. The note includes a value and cryptographic material associated with the recipient’s shielded address, alongside note-specific randomness. The wallet then produces a note commitment, a short cryptographic digest that hides the note’s contents while binding the sender to them.
That commitment enters Orchard’s commitment tree. The tree is a public, append-only structure. Anyone can see its root, but nobody looking only at the root can tell which notes belong to which people or what values they carry.
Later, when the recipient spends the note, their wallet uses the note’s private details and a secret spending key to derive a nullifier. The nullifier is public, but it is designed not to reveal the note itself. Its job is narrow and crucial: it is the public marker that says, “This private note has now been consumed.”
Every full node tracks the set of nullifiers already seen. A transaction that repeats one is rejected.
The spending wallet also constructs a zero-knowledge proof. The proof lets a verifier check that the wallet knows a note whose commitment appears in a tree represented by an accepted root, that the note is spendable by the prover, and that the published nullifier and other public commitments correspond to the hidden witness in the way the circuit prescribes.
The transaction’s value logic is deliberately more subtle than the visible balance equation in a transparent chain. A shielded pool cannot reveal its inputs and outputs, so it uses cryptographic commitments to values. These commitments enable the circuit and consensus rules to establish that no value has appeared from nowhere, without exposing individual amounts.
In practical terms, the system needs a zero-sum accounting identity. The sum of hidden input values, plus any value entering from outside the pool, must equal the sum of hidden output values, plus any value exiting the pool and any fee. The chain need not learn each term. It needs confidence that the committed terms satisfy the equation.
This is why privacy-pool security is not just about hiding data well. It is about proving a state transition correctly.
A commitment tree alone cannot prevent counterfeiting. It only records that commitments were added. A nullifier set alone cannot prevent counterfeiting. It only rejects the same public nullifier twice. A value-balance equation alone cannot prevent counterfeiting. It can show that one transaction balances internally even if the protocol has accidentally allowed the same hidden input to be used more than once.
The guarantees emerge only when these systems are connected correctly.
Where each invariant actually lives
It is helpful to separate three layers that are often collapsed into the phrase “the proof verifies.”
The first layer is the circuit. This is the arithmetic program represented inside the zero-knowledge system. It defines which private witness values are allowed for a given set of public inputs. It should constrain membership, authorization, nullifier derivation, value commitments, ranges and every required internal relationship.
The second layer is host consensus logic. Full nodes enforce rules outside the circuit. They confirm that a referenced tree root is valid, reject nullifiers already present in the global nullifier set, enforce transaction format and signatures where applicable, apply fee rules, and update the chain’s public state.
The third layer is system-level accounting. This includes the economic invariants created by transfers between transparent and shielded domains. A protocol may have public accounting controls at pool boundaries, where money entering or leaving a private pool can be measured even if activity inside the pool remains confidential.
The key design question is not whether an invariant exists in a specification document. It is whether every route to violating it hits an enforcement point.
Consider the anti-double-spend rule. It is divided across the circuit and the chain.
Inside the circuit, the protocol must prove that the nullifier was properly derived from the specific note being spent and the right secret authority. Outside the circuit, nodes must verify that the published nullifier has never appeared before.
Neither half can replace the other.
If the circuit derives nullifiers correctly but nodes do not store nullifiers, a spender can submit the same transaction repeatedly. If nodes store nullifiers but the circuit does not correctly bind a nullifier to a particular note, then an attacker may be able to produce multiple distinct nullifiers for what is economically the same private input. Each new nullifier looks unused to host logic, even though the intended note has already been consumed.
This is the category of failure that makes an under-constrained circuit so dangerous. The chain may faithfully enforce every public rule it can see. It may still accept invalid private state transitions because its view of private consistency comes entirely from the proof.
What went wrong in Orchard, conceptually
Reporting on the incident described the Orchard flaw as an under-constrained relation in a variable-base scalar multiplication component of the proof circuit. Cointelegraph reported that the issue involved using assign_advice where the stricter copy_advice was required in the Halo 2 gadget. The distinction matters because a circuit must not merely place values into witness cells. It must constrain every cell that is meant to represent the same value or follow from another value.
That may sound like a minor implementation detail. In a zero-knowledge circuit, it is not.
A circuit is not ordinary application code. In conventional software, a programmer might assign a variable and later assume it refers to the same object or value. In a proof circuit, that sameness needs a mathematical constraint. If two witness positions are supposed to contain identical values, or if one is supposed to be the cryptographic result of another, the circuit must explicitly establish that relation.
Without it, the prover may be free to choose values independently where the designer believed they were linked.
The failure is not that the underlying elliptic-curve cryptography was defeated. It is not that an attacker learned someone’s secret spending key. It is not that zero-knowledge proofs broadly became unreliable.
Instead, the circuit could accept a witness that satisfied its implemented equations while violating the protocol’s intended relationship between a note, its spending authorization and its nullifier behavior. The Block reported that the weakness could let an attacker spend the same shielded note multiple times while presenting a distinct nullifier for each spend, effectively creating counterfeit ZEC within the Orchard pool.
This is the most important distinction in the story:
A cryptographic break means an attacker defeats an assumed-hard mathematical problem or defeats the proof system’s fundamental security. A circuit-specification bug means the proof system faithfully proves the wrong, incomplete or insufficiently constrained statement.
In the first case, the cryptographic primitive has failed. In the second, the primitive may be functioning exactly as designed. The verifier receives a proof and correctly concludes that the circuit was satisfied. The problem is that the circuit did not encode all the conditions that the protocol required.
That is why phrases such as “the proof was valid” can be misleading. A proof can be valid under a defective verification relation. The meaningful security claim is not, “Did the verifier return true?” It is, “Does verifier acceptance imply that the intended ledger transition was valid?”
For Orchard, the answer was temporarily no.
Why conservation can fail without a visibly broken balance equation
The Orchard incident also corrects a common intuition: counterfeit value does not always require a transaction with an obviously false arithmetic balance.
Suppose a private note represents 10 ZEC. A correctly designed system allows its owner to consume it once, creating perhaps a 7 ZEC recipient note and a 2.999 ZEC change note, with 0.001 ZEC paid as a fee. The hidden values add up. The note’s nullifier appears once. The note is gone.
Now imagine a flaw that lets the same economic note be spent again, but with a fresh public nullifier that passes the global uniqueness test. The second transaction can still satisfy a local value-balance equation. It can create another set of shielded outputs whose total equals 10 ZEC, plus or minus the relevant fee.
Each transaction looks internally balanced. The fraud appears only when the system fails to enforce the global fact that the 10 ZEC input was available exactly once.
This is why a privacy-pool audit must distinguish local conservation from global conservation.
Local conservation asks whether the commitments and equations in a particular action balance. Global conservation asks whether all accepted actions together consume each spendable resource no more than once, and whether the total value leaving a pool can be justified by value that actually entered it.
Nullifiers bridge these two levels. They turn a private resource into a one-time public marker. But that bridge works only if the proof circuit ensures the nullifier is the unique, correct marker for the note.
The broader lesson for zero-knowledge application developers is that every private object needs a public replay-defense handle, and the proof must bind the two securely. This applies not only to shielded coins but also to private voting credentials, anonymous reputation scores, private order books, proof-carrying identities and rollup withdrawal rights.
A protocol can hide the object. It cannot leave ambiguity about whether the object was already consumed.
Why pausing Orchard was the right emergency move
When Zcash developers learned of the flaw, the first priority was not to produce a perfect public explanation. It was to remove the exploitable path before disclosure created a race between defenders and attackers.
The response used two stages. Zebra 4.5.3 temporarily disabled Orchard actions. Zebra 5.0.0 then activated NU6.2, which restored Orchard using a corrected circuit and a replacement verification key. Cointelegraph reported that the permanent upgrade activated at block 3,364,600, following the temporary mitigation near block 3,363,426.
The pause was not an admission that exploitation had occurred. It was recognition that “no evidence of exploitation” is not the same as “the bug is harmless.”
In a transparent system, an exploit often leaves visible traces. Investigators may identify a suspicious account, an abnormal mint transaction or a balance discrepancy. In a shielded pool, the privacy design deliberately limits that forensic visibility. The network can see proof verification, commitments, nullifiers and public boundary flows. It cannot inspect every private note and reconstruct every hidden economic history.
CoinDesk later summarized the uncomfortable result: the corrected circuit could close the vulnerability, but it could not retroactively prove that no counterfeit ZEC had been created during the years the flaw was live. A proof verifies only that the relevant circuit was satisfied at the time. If the circuit was wrong, historical proof acceptance does not become evidence that the intended rule was met.
That asymmetry explains the conservatism of the emergency response. Continuing to process Orchard actions while preparing a fix would have extended the period in which an attacker could potentially exploit the flaw. Freezing the affected action type narrowed the risk, even at the cost of disrupted service and temporary confusion among users, miners and infrastructure providers.
The incident also showed that shielded protocol upgrades are operationally different from a routine wallet release. The verifying key is effectively part of consensus. Nodes must agree on the circuit whose proofs are accepted. Changing that circuit means changing the network’s definition of validity.
What NU6.2 changed, and what it could not change
Operationally, NU6.2 did four essential things.
First, it replaced the flawed Orchard circuit with a corrected one. That changed the mathematical relation future proofs had to satisfy.
Second, it introduced a replacement verifying key, described in reporting as FixedPostNu6_2. Because a zk proof is checked against a particular verification relation and key, this step was central, not cosmetic. A node using the old key would still accept proofs for the old circuit.
Third, it re-enabled Orchard actions after the temporary safety pause. This restored private-pool functionality under the new rules.
Fourth, it aligned node operators, miners, exchanges, wallet providers and infrastructure services around the repaired consensus rules. Reports at the time described a brief period of instability as miners upgraded and converged, which is a reminder that a secure patch only works when the economically relevant network adopts it.
What NU6.2 could not do was rewrite historical privacy-preserving data into an audit trail. It could not inspect every past Orchard transfer and announce with certainty whether the flaw had ever been used. It could not transform proofs generated under the old circuit into proofs of a stronger statement after the fact.
That is not a shortcoming unique to Zcash. It is a structural feature of confidential systems. Privacy protects honest users from surveillance, but it also constrains retrospective inspection when a circuit-level soundness risk emerges.
The longer-term answer has been to strengthen public accounting at the pool boundary. Later reporting on Zcash’s Ironwood work described a turnstile mechanism that caps withdrawals from Orchard according to verifiable deposits, limiting how much value can leave the legacy pool. That is a system-level control, rather than a replacement for the repaired proof circuit. It addresses the residual uncertainty that a patch alone cannot erase.
For builders, this suggests an important design principle: do not rely on one perfect proof circuit as the sole line of defense for an irreversible economic invariant. Where privacy allows it, add public boundary accounting, supply caps, migration controls or other independent checks that can limit damage if a hidden-state rule is ever specified incorrectly.
A practical audit framework for privacy-pool designs
A reader does not need to inspect Halo 2 source code to ask useful security questions about a private ledger. Start with the invariants.
First, write down what must never happen. For a payment pool, the list usually includes unauthorized spending, double spending, negative values, value creation, value destruction outside explicit rules, invalid asset conversion and spending notes that were never committed.
Second, identify the witness and the public state for each invariant. A private note, a secret spending key and a Merkle path live with the prover. A commitment-tree root, nullifier set, transaction fee and pool entry or exit amount are visible to the chain.
Third, map the enforcement location. Is the rule proved in-circuit, checked by node software, or enforced through a public accounting mechanism? If the answer is “the protocol assumes it,” that is not enough. There must be a concrete verifier check.
Fourth, examine every binding. Ask whether the note commitment is tied to the membership path, whether the nullifier is tied to the exact note and authority, whether value commitments are tied to the values used in the balance relation, and whether output commitments are tied to the recipient and value the sender intended.
Fifth, test composition. A transaction can be locally valid while a sequence of transactions violates a global invariant. Does the protocol ensure an input can be consumed once across all time? Does it cap withdrawals from a private pool by known inflows? Does it handle multi-asset balances and cross-pool conversion without creating a gap?
Sixth, separate proof validity from protocol validity. The verifier returning “true” means only that the proof satisfied the implemented circuit and public-input checks. The audit question is whether that acceptance logically implies the intended business rule.
This distinction is becoming commercially important. Enterprises considering confidential settlement do not only need fast proof generation and strong privacy. They need assurance that confidential liabilities cannot silently exceed confidential assets. Stablecoin issuers need confidence that private transfers preserve reserve-backed supply rules. Rollups need confidence that withdrawal proofs cannot be replayed or detached from the state root they were meant to reference.
The Orchard incident is therefore larger than one blockchain’s emergency upgrade. It is a warning about the product reality of zero-knowledge systems: code that expresses policy inside a circuit is not auxiliary plumbing. It is the policy.
The durable lesson: verification is not the finish line
Zcash’s response was fast, coordinated and technically appropriate to the risk. Orchard actions were paused, the circuit was corrected, the verification key was replaced and the network resumed under NU6.2. The available reporting found no evidence that the flaw was exploited, and the Zcash Foundation said user privacy was unaffected.
But the deeper contribution of the episode is educational.
Zero-knowledge proofs can make a public blockchain accept private state transitions with extraordinary efficiency and privacy. They do not make protocol design automatic. The verifier is only as strong as the statement it verifies. The circuit is only as secure as its constraints. Host logic is only as effective as its connections to the circuit. And economic safety depends on the whole composition.
A shielded-pool proof must prove more than “someone knows some secret values.” It must prove that one specific, authorized, unspent economic object is being consumed exactly once, that hidden values obey conservation rules, that new commitments are legitimate, and that the public state will move forward without opening a second path to the same value.
That is the standard. Anything less can still produce a valid proof.