Zcash forces hard fork to contain counterfeiting risk exposed in Orchard flaw
Zcash's Ironwood upgrade, live 28 July, isolates a flawed shielded pool after a bug raised unprovable counterfeiting concerns.
Zcash is set to activate its NU6.3 “Ironwood” network upgrade on 28 July, a hard fork designed to contain the fallout from a flaw discovered in the network’s Orchard shielded pool that developers say could theoretically have allowed the creation of counterfeit ZEC without leaving a detectable trace. The episode has renewed scrutiny of how privacy-preserving blockchains can verify their own supply integrity when transaction details are, by design, hidden from public view.
According to reporting by crypto.news, the upgrade will activate at block height 3,428,143, with the Zcash Foundation’s Zebra 6.0.0 client release estimating the fork will land at around 13:00 UTC. Node operators have been told to upgrade before that point, as older software will not follow the correct chain once the fork occurs.
A bug developers could patch but not fully disprove
The vulnerability, discovered in the older Orchard pool, was addressed through emergency patches in June. Developers have said they found “no evidence” that the flaw was exploited on mainnet, but Zcash’s own privacy architecture — which conceals transaction amounts and balances — means they cannot definitively rule out that hidden inflation occurred before the fix.
Zcash founder Zooko Wilcox described the flaw as “unlikely to have been exploited,” while adding that users should not need to rely on that assessment alone. That distinction between plausibility and proof is central to why the project has pushed ahead with a full hard fork rather than treating the June patch as sufficient.
A new shielded pool and a supply “turnstile”
Ironwood introduces a new shielded transaction pool alongside a v6 transaction format. Per the Zebra 6.0.0 release notes, the new pool reuses Orchard’s underlying Action structure and Halo2 proof system, but maintains its own note commitment tree, nullifier set, chain value pool and chain-history data, allowing nodes to track it independently of the legacy pool.
The centrepiece of the remediation is a mechanism the project calls a “turnstile” between Orchard and the new pool. Once Ironwood activates, Orchard will stop accepting new outputs and internal transactions, becoming exit-only. An accounting rule then prevents more ZEC from leaving Orchard than legitimately entered it, giving the network a public, verifiable check on circulating supply without exposing individual balances or transaction contents. In effect, any illegitimately created value would remain permanently trapped inside the now-sealed pool.
Quantum-recovery groundwork, but not quantum security today
Ironwood also alters how shielded notes are constructed so they can potentially be recovered under a future post-quantum protocol, a feature formalised in the ZIP 2005 specification as “quantum recoverability.” The change binds additional data into notes at creation, but developers have been clear that Ironwood does not itself make Zcash quantum-secure — it is preparatory infrastructure for a later recovery system, not a present-day safeguard against quantum attacks.
For a network whose value proposition rests on the ability to make strong, verifiable claims about privacy and monetary soundness simultaneously, the Orchard episode is a reminder of the trade-off inherent in shielded architectures: the same opacity that protects users’ transaction data also makes it harder to prove, rather than merely assert, that a flaw was never exploited. Institutional counterparties assessing privacy coins for custody or compliance purposes are likely to treat the turnstile mechanism, and how transparently it is documented, as a test case for how such networks handle supply-integrity incidents going forward.
Read more: Lido’s stETH yield glitch revives questions over self-audited oracle data
