For financial institutions, privacy is only valuable if auditability is preserved. Banks, exchanges, and asset managers must be able to independently verify the integrity of the assets they hold and transfer. The recent disclosure of a critical bug in Zcash's Orchard shielded pool shows why: when supply verification depends entirely on a complex cryptographic system, institutions inherit risks that cannot be independently audited after the fact.
What Happened
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. The wider the implementation surface, the more places an under-constrained element can hide for four years before anyone notices.
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. This still depends on the cryptographic implementation being correct; a bug that allows forged commitments to pass the balance check could allow undetectable inflation, the same general failure mode that affected Orchard.
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 two things holding: the discrete logarithm assumption, and the correctness of the implementation that enforces the balance check (libsecp256k1 for the curve operations, the rangeproof code, the consensus rules). Classical attackers cannot break discrete log; a sufficiently advanced quantum computer could. An implementation bug in any of these components could allow undetectable inflation, the same class of failure as the Orchard bug. 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.
The Orchard bug is a useful reminder that this class of system carries real cost. The Liquid stack carries the same shape of risk that Zcash does. The argument for confidential transactions over shielded transactions is that the smaller, more battle-tested codebase of Pedersen commitments and Bulletproofs is less likely to harbor a four-year-undetected bug than a fast-evolving zk-SNARK circuit. The difference is quantitative, in the amount of code and the maturity of the primitives.
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, at the cost of new implementation surface. 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 enables strong privacy without giving up supply verifiability (conditional on cryptographic assumptions and correctness of implementations).
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 Bitcoin’s, 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, and it does not rest on the correctness of any cryptographic implementation.
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.