Zcash is expected to activate its NU6.3 “Ironwood” network upgrade at block height 3,428,143 on July 28.
Summary
- Ironwood activates at block 3,428,143, replacing Orchard with a separately tracked shielded transaction pool system.
- The turnstile blocks more ZEC leaving Orchard than entered, strengthening public supply verification after migration.
- Quantum-recoverable notes support future recovery, but Ironwood does not make Zcash quantum-secure today by itself.
The Zcash Foundation’s Zebra 6.0.0 release places the estimated activation near 13:00 UTC and tells every node operator to upgrade before the fork.
The upgrade introduces a new shielded pool and a v6 transaction format. It follows the disclosure of a flaw in the older Orchard pool that could have allowed an attacker to create counterfeit ZEC without an obvious public record.
Developers patched the flaw through emergency upgrades in June. They said they found “no evidence” of exploitation, but Zcash’s privacy design prevents them from proving that hidden inflation never occurred.
Ironwood creates a separately tracked shielded pool
According to the Zebra 6.0.0 release notes, Ironwood reuses Orchard’s Action structure and Halo2 proof system. However, it adds a separate note commitment tree, nullifier set, chain value pool and chain-history data. These records let nodes track the new pool independently from Orchard after activation.
Zebra also updates several node commands so operators can inspect the pool’s value and commitment-tree state. The Zcash Foundation’s GitHub release labels the upgrade critical for operators because older software will not follow the correct chain after the activation height.
Turnstile limits value leaving Orchard
Ironwood’s main supply safeguard is a turnstile between Orchard and the new pool. After activation, Orchard will stop accepting new outputs and internal transactions. Funds can move out, but the accounting rule prevents more ZEC from leaving Orchard than the amount that legitimately entered it.
The Ironwood design explanation says the mechanism gives users a public check on circulating supply without exposing private balances or transaction details. Instead, it would leave any excess hidden value trapped inside Orchard once the pool becomes exit-only.
As crypto.news previously reported, Zcash scheduled the July 28 hard fork after developers concluded that the patched bug still left a supply question they could not answer with certainty. Zcash founder Zooko Wilcox said the flaw was “unlikely to have been exploited,” while also stating that users should not need to rely on that assessment.
Notes gain a future quantum-recovery path
Ironwood also changes how shielded notes are created so they may be recovered through a future post-quantum protocol. The official ZIP 2005 specification calls the feature quantum recoverability. It binds more note data into the note construction, allowing a later recovery system to verify ownership without relying only on cryptography that a powerful quantum computer could break.
The change does not make current Zcash transactions quantum-secure. The specification says a separate recovery protocol must still be designed and activated later. Funds that remain in Sprout, Sapling or Orchard would not gain this recovery option. Wallets must move them into Ironwood notes to receive the new protection.
The same specification says existing Orchard addresses can receive Ironwood notes, reducing changes for users. Wallet developers must still add migration support. Users whose wallets do not update may face delays when moving Orchard funds, while exchanges may briefly pause deposits or withdrawals around the fork.
Zebra becomes mandatory as zcashd support ends
The upgrade also completes Zcash’s move away from the older zcashd node software. The network set zcashd’s end-of-support halt at block 3,417,100, before Ironwood activation. The official deprecation schedule says zcashd will not support NU6.3, leaving Zebra as the required node implementation for the new rules.
Zebra 6.0.0 includes a separate mempool security fix. The issue allowed peers to send expensive-to-check, non-standard transactions that could reduce node responsiveness while the traffic continued. The fix rejects those inputs before the costly verification step. The Foundation said the flaw affected availability only and did not allow invalid blocks, lost funds or consensus failure.
Related crypto.news coverage detailed Zcash’s two-step response to the Orchard vulnerability. Developers first disabled Orchard activity, then activated the NU6.2 hard fork with corrected code before restoring the pool. Ironwood now adds a separate accounting boundary rather than another patch inside the same pool.
The upgrade remains tied to block production, so its exact clock time may shift. If the chain reaches block 3,428,143 as expected, Ironwood will activate on July 28 and begin the Orchard-to-Ironwood transition.
