On June 5, 2026, a nonprofit developer Shielded Labs disclosed that a security researcher found a critical soundness bug in Zcash’s Orchard pool's zero-knowledge proof circuit.
The bug had been live since Orchard activated four years earlier. Exploited on mainnet, it would have allowed an attacker to mint arbitrary counterfeit ZEC inside the shielded pool, with no on-chain signal that the supply was inflated. By the time the disclosure was public, the Zcash community had already executed an emergency soft fork to disable Orchard, then a hard fork to re-enable it with the circuit patched.
ZEC fell ~60% from around $629 to a $254 low in just over 24 hours.
Soundness, in Plain Language
A zero-knowledge proof is a kind of math-based proof. It lets the network confirm that a Zcash transaction is valid (meaning the sender had the funds—nothing was created from thin air) without revealing who sent what to whom. Zcash supports two transaction types:
- Transparent: The sender, receiver, and amount are visible to anyone
- Shielded: All three are hidden
In Orchard, every shielded transaction comes with one of these proofs. The chain checks the proof; the actual details stay encrypted. The system works only if every proof the network accepts comes from a real, balanced transaction. Cryptographers call this property soundness.
The Orchard bug broke this soundness. A specific step inside the proof's math, governing how points are added together on an elliptic curve, was incomplete. Under the right conditions, an attacker could produce a proof that the network would accept even though the underlying transaction failed to balance. The attacker would walk away with counterfeit ZEC inside the shielded pool, and from the outside, the new units would be indistinguishable from real ones.
In a transparent system like Bitcoin, a bug like this would show up immediately. Every full node verifies that the total supply matches the emission schedule by reading the chain directly. In Orchard, the proof is the only check there is. Every other signal that would normally catch an invalid transaction is hidden by design: the amount, the sender, the receiver, and the link between inputs and outputs.
Shielded Labs has said directly that the bug was probably never exploited before the patch, but that cannot be proved one way or the other. Bitquery's post-mortem made the same point: if fake notes were minted and never withdrawn, "they are still sitting in the Orchard pool, and no one can detect them." A patient attacker could have withdrawn counterfeit ZEC across multiple days while blending into normal volume, and the on-chain record would look ordinary. Best evidence is that nothing like that happened, but that is not the same as proof.
Shielded Labs has proposed a new pool with turnstile accounting on every Orchard withdrawal as a forward-looking remedy, but that pool does not exist yet, and rolling it out will require a network upgrade, custody migration, and time.
More Complexity, More Problems
Independent researcher Taylor Hornby discovered the bug using Anthropic's Claude Opus 4.8 in a targeted review of the Orchard circuit. The bug had survived four years of expert cryptographic review.
The audit lesson is about complexity: A protocol where the soundness of the supply rests on the correctness of 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.
Approaching Privacy Design
The first approach to privacy is to hide everything: inputs, outputs, amounts, addresses, and the links between them. The proof system asserts that the hidden transaction is valid. The supply of the asset is hidden from outside observers. Supply integrity is delegated entirely to the soundness of the proof circuit. When the circuit is correct, the user gets very strong privacy, but when the circuit has a soundness bug, the user has no recourse, because there is no public check that would have caught the discrepancy.
The second approach is to hide selected fields while keeping a public balance enforcement. The protocol may hide amounts, asset types, or the link between specific inputs and outputs, but it does not hide the fact that the supply balances. An auditor running a node can verify that the total supply is consistent with the emission schedule. A bug in any one component shows up immediately as a balance failure.
Why Bitcoin and Liquid Are Better
Bitcoin reflects the second approach in its purest form. Every unspent transaction output (UTXO) is public. The total supply at any block height can be summed directly from the chain state and compared against the publicly known emission schedule. There is no privacy in the default protocol, and there is also no possible question about the supply. A bug that minted bitcoin out of thin air would show up as an immediate violation of the emission schedule, visible to every full node.
Liquid is the example of the second approach with an additional privacy layer on top. Liquid's Confidential Transactions hide the amounts and asset types in every transaction. They do not hide whether the math balances. There are three components at play here:
- Pedersen commitments enable the network to add hidden amounts together without revealing what those amounts are.
- Range proofs (Bulletproofs in Liquid's current implementation) ensure no negative amounts can be smuggled in.
- Issuance and burn events for LBTC and other Liquid assets are public, so the total emission is independently tracked. An auditor can prove the supply is correct without knowing a single individual amount.
These guarantees rest on the discrete logarithm assumption. Classical attackers cannot break it; a sufficiently advanced quantum computer could. Pedersen commitments can be made quantum-safe by upgrading to a switch-commitment construction that also commits to a hash of the value, and Blockstream researchers have proposed paths for that transition on Liquid. Until then, Liquid's supply auditability carries the same long-horizon quantum exposure as every other discrete-log-based system on Bitcoin.
If a comparable soundness bug existed in Liquid's CT implementation, the failure mode would be different. A failed range proof shows up as a block-validity error, immediately, on every node. A broken balance shows up as a sum that does not zero, immediately, on every node. There is no scenario where invalid value sits in the pool indefinitely waiting for the next withdrawal to detect it, because the public balance is checked on every transaction. A circuit bug can’t bypass the public check because there is no circuit between the public check and the chain state.
What Bitcoin’s Verifiable Supply Guarantees
Verifiable supply means that the user who runs a node and downloads the chain can prove to themselves that the total amount of money in the system matches what the protocol says it should be. Custodians can satisfy auditors without privileged access to anyone's books, and turns the question "Was the supply ever inflated?" into something answerable, definitively.
In Bitcoin, verifiable supply is free, because the ledger is open. In Liquid, verifiable supply costs the additional cryptography of Pedersen commitments and range proofs, which let the network add the hidden amounts together to confirm their balance. In Zcash's Orchard pool, verifiable supply was traded for stronger transaction-level privacy, and the cost of that trade is being itemised now.
Takeaways
The privacy design space expands much further than merely transparent vs. shielded. Liquid’s approach to privacy via commitment schemes with public balance enforcement is in its own novel category, enabling strong privacy without giving up supply verifiability.
Protocol designers must approach complexity with caution. A zk-SNARK circuit is a powerful tool, but a piece of code containing a single under-constrained element, missed by four years of expert review, is able to undermine trust of a multi-billion-dollar asset's integrity overnight. On the other hand, protocols that pair the circuit with a simple public balance check are taking a smaller bet and retain a recoverable position if any one component fails.
For allocators, an asset whose supply correctness cannot be independently verified after a four-year-undetected bug carries an entirely more dangerous risk profile than an asset whose supply correctness is a node-side check that thousands of participants perform every block.
Bitcoin Is the Only Strong Foundation
Bitcoin solves the supply-auditability problem by making the ledger fully public. Every full node can confirm the 21 million cap at every block, every 10 minutes. No circuit has to be correct for that property to hold. No researcher has to find the bug for it to be ruled out. The check is plain summation, so it does not rest on any computational hardness assumption that a future attacker could break. Privacy can be layered on top of this foundation in ways that preserve the guarantee: Liquid demonstrates how.
To take action for yourself or your organization:
- Get Blockstream Jade for robust self-custody storage.
- Build on Liquid for privacy-preserving applications with publicly verifiable supply.
- Contact Blockstream Enterprise for institutional custody on the same architecture.