Zcash Ironwood Activation: What the Sealed Orchard Pool Means for Your ZEC Today

Zcash's Ironwood (NU6.3) hard fork activates at block 3,428,143 on July 28, 2026, permanently sealing the legacy Orchard shielded pool and routing roughly 3.76 million ZEC through a turnstile checkpoint that caps outflows at the amount that legitimately entered. The upgrade closes a verification gap left by a four-year-old circuit flaw found in May, which developers patched but could not prove was never exploited. Ordinary holders face no deadline and should enable Tor or Nym before migrating, while node operators must upgrade to Zebra 6.0.0 or Zakura before activation.

 

 

The Zcash network is crossing block height 3,428,143, marking activation of the Ironwood upgrade, formally designated NU6.3. The hard fork represents one of the most consequential structural transitions in the history of zero-knowledge privacy systems: the permanent sealing of Zcash's flagship Orchard shielded pool and the deployment of a fresh pool built on the corrected circuit, backed by formal verification and independent audits. Funds can leave the old pool only through a mathematical accounting gate known as the turnstile.

For ordinary ZEC holders, the headline is reassuring but comes with an important sequencing instruction. The upgrade does not confiscate, burn, or automatically move funds sitting in Orchard, and there is no protocol deadline forcing migration. Your existing Orchard addresses continue to work, because the new pool reuses them, and payments sent to those addresses after activation route automatically into Ironwood. What core developers do stress is order of operations: enable network-level privacy through Tor or the Nym mixnet before you migrate, then wait for your wallet provider to confirm its migration flow is ready. Node operators are the exception to the relaxed timeline, since anyone running Zebra must be on version 6.0.0, or on the newly released Zakura client, before the activation height or risk following a minority chain.

 

The most important takeaway for holders is that Ironwood does not touch the balances sitting inside Orchard. Your coins remain spendable through the exit turnstile whether you migrate this week, next month, or considerably later, and the pool reuses your existing addresses so there is no need to coordinate new receiving details with counterparties. What changes at activation is the pool's operating mode. As of block 3,428,143, Orchard becomes withdrawal-only: you can no longer receive new deposits into it, and internal transfers between users inside the legacy pool are disabled. The pool now functions strictly as a one-way exit route into Ironwood or out to a transparent address. Core developers and Zcash founder Zooko Wilcox have explicitly advised holders against rushing, on the reasoning that a hurried migration raises the risk of operational error and of falling for opportunistic fraud. Wilcox's published guidance is direct on the sequence: get network-level privacy in place first, then wait until your wallet provider says its migration path is ready.

 

 

To understand Ironwood, holders need to look back to May 29, 2026. Security researcher Taylor Hornby, working on an ongoing protocol audit for Shielded Labs, identified a four-year-old soundness flaw in Orchard's Halo 2 proof circuit: an under-constrained element in the Orchard Action circuit that allowed a check to appear to validate transaction inputs without actually enforcing the rule it seemed to enforce. The flaw had been present since Orchard went live in May 2022 and had survived multiple professional audits.

The discovery drew as much attention as the bug. Hornby found the flaw using Anthropic's Claude Opus 4.8, one day after that model's public release on May 28, and went on to build a working proof-of-concept in Zcash's local regtest environment, where the exploit repeatedly doubled the value of a shielded note until the test balance exceeded 10 million ZEC. The exploit was never broadcast to mainnet or testnet, but regtest applies identical validation rules, which established that the attack was practical rather than theoretical. Core engineers at the Zcash Open Development Lab confirmed the issue within hours, disabled new Orchard actions through a soft fork around June 1, and restored full functionality on June 3 via the NU6.2 hard fork carrying a corrected verifying key. Transparent and Sapling transactions ran uninterrupted throughout.

Zcash's pre-existing turnstile accounting, specified in ZIP 209, tracks the total value entering and leaving each shielded pool and showed no signs of unauthorized minting, which means chain-wide supply beyond the 21-million cap was never the primary exposure. The genuine danger was internal to Orchard: an attacker could have spent the same shielded note repeatedly while producing different nullifiers, inflating balances inside the pool and potentially rendering it insolvent. In that scenario, legitimate shielded holders would be diluted as counterfeit claims competed against real ones for a finite pool balance. Orchard's privacy architecture, which hides sender, recipient, and amount by design, also erases any forensic trace of exploitation. Developers found no evidence the bug was ever used, but no cryptographic method exists to prove a negative. Ironwood was built to close that verification gap.

 

 

When Orchard sealed, it held roughly 3.76 million ZEC, worth approximately $1.89 billion and representing around 22% of circulating supply, down from a recent peak near 4.2 million tokens. Every coin leaving that pool must now pass through the turnstile, which enforces a single rule: no more ZEC may exit Orchard than verifiably entered it across the pool's entire history. As core developer Sean Bowe framed it, the mechanism bounds circulating supply so that the amount anyone can transact with is no greater than the amount that is supposed to exist.

Three outcomes are possible. If no exploitation ever occurred, total Orchard exits will match net historical deposits, every holder migrates without incident, and Zcash will have produced live on-chain proof that its supply integrity held throughout the vulnerable window. If counterfeit ZEC was created but never spent out of the pool, those fake notes simply cannot pass the turnstile cap and remain permanently locked inside a dead pool while legitimate funds exit normally. The third case is that counterfeit ZEC was minted and already withdrawn before Ironwood, which would leave the pool short of what legitimate holders collectively expect to withdraw. In that event the turnstile stops paying out once the pool balance is exhausted, and holders who migrate last would bear the shortfall.

Shielded Labs, ZODL, and core protocol engineers assess that third scenario as unlikely based on turnstile records and pool accounting, and Grayscale's chief legal officer Craig Salm has argued publicly that an attacker sophisticated enough to find the flaw before the entire core development team would have been unlikely to then resist draining the pool during a historic bull run. There is no protocol deadline, and the theoretical race dynamic in the unlikely third scenario is the one argument for moving sooner. Weighed against it are two concrete, present-tense risks: migrating without network-level privacy exposes your IP address, and migrating in a hurry through unfamiliar tooling exposes you to the scams already circulating.

In March 2018, cryptographer Ariel Gabizon found a comparable counterfeiting bug in Sprout, Zcash's original shielded pool, which was quietly fixed through the Sapling upgrade that October and publicly disclosed in February 2019. Eight years later, 22,747 ZEC still sit in Sprout, and the turnstile has never been broken. Eight years of unbroken turnstile accounting is the strongest available evidence that nothing was ever forged. Ironwood applies the same logic prospectively, with the difference that holders can now watch the accounting resolve in real time through ZODL's public dashboard tracking funds leaving Orchard block by block.

 

Start with network-level privacy, because this is the step developers rank above all others. Zero-knowledge proofs protect on-chain transaction data, but the act of syncing notes or submitting a migration transaction through a lightwallet server can expose your IP address and link it to your Zcash activity. Configure your wallet to route through Tor or the Nym mixnet before you initiate any migration.

Next, wait for your wallet provider's guidance. Wallets are rolling out dedicated migration features at different paces, with Zodl and Zkool among those that have published detailed migration documentation, and some are layering additional privacy protections into the process. Update to the latest official release of whichever wallet you use, confirm how it handles migration and whether it requires a rescan or fresh backup, and then follow its native flow.

Node operators and infrastructure providers are on a different clock entirely. If you run a node, you must be on Zebra 6.0.0 or the newly released Zakura client before block 3,428,143, or your node will follow a minority chain that does not enforce NU6.3 consensus rules. Zcash is simultaneously retiring zcashd, whose end-of-support falls at block height 3,417,100, in favor of a stack comprising Zebra for node operation, Zaino for blockchain data services, and Zallet for wallet functions. Some zcashd functions have no direct replacement, so operators should expect to adapt their systems, not simply swap binaries.

Finally, expect friction at the boundary and verify everything through official channels. Many exchanges and custodial services will briefly pause ZEC deposits and withdrawals around the activation window while they confirm their systems are synchronized with the new consensus rules, so avoid time-sensitive transfers right at the activation edge. Take migration instructions only from official developer repositories, the Zcash Community Forum, or verified wallet support portals, keep signing environments clean, use hardware wallets where possible, and never import a seed phrase into unfamiliar software.

 

 

The discovery demonstrated that a frontier AI model, in the hands of an expert auditor, surfaced within a day a cryptographic flaw that had survived four years of scrutiny by world-class reviewers. How many production zero-knowledge systems have never been tested against tooling of that capability is now an open question. Aztec Labs chief executive Joe Andrews has noted that insufficient elliptic curve constraint checks are not unusual in production-grade circuits, suggesting the exposure is unlikely to be unique to Zcash.

There is also a collective-action dynamic embedded in the migration itself that holders should understand. Because moving funds through the turnstile publicly records the amount and timing of the transfer, migration carries a modest privacy cost, and the anonymity set in the new pool depends on how many people move and how quickly. If holders migrate slowly, a substantial pool of private ZEC sits unusable for an extended period; if everyone moves simultaneously, the supply verification resolves faster but individual transfers stand out more against a thinner crowd. Developers judge the privacy impact of migration to be limited and further reducible through wallet-level implementation choices, but the tradeoff is real. Zcash is conducting a live, public audit of its shielded supply without exposing a single user's transaction history. If the accounting resolves cleanly, the network will have restored trustless supply verification at the protocol level for the first time since 2022, and it will have done so through mathematics.

 

What is the Zcash Ironwood upgrade? Ironwood, formally NU6.3, is a Zcash hard fork activating at block 3,428,143 on July 28, 2026. It permanently seals the legacy Orchard shielded pool, launches a replacement pool built on the corrected circuit with formal verification and independent audits, and routes all outgoing Orchard funds through a turnstile that caps withdrawals at the amount that legitimately entered the pool.

Do I need to migrate my ZEC right now? No. There is no protocol deadline for ordinary holders, and your balance remains spendable through the turnstile regardless of when you move it. Developers explicitly advise against rushing. Enable Tor or Nym for network-level privacy first, then migrate once your wallet provider confirms its migration feature is ready.

Is my ZEC safe after the Orchard pool is sealed? Your funds are not confiscated, burned, or moved by the upgrade, and your existing Orchard addresses continue to work because the new pool reuses them. Orchard becomes withdrawal-only: no new deposits and no internal transfers, with the turnstile as the sole exit route into Ironwood or to a transparent address.

What was the Zcash Orchard bug? On May 29, 2026, researcher Taylor Hornby, using Anthropic's Claude Opus 4.8, found an under-constrained element in the Orchard Action circuit that had existed since May 2022. It could have allowed an attacker to spend the same shielded note repeatedly while generating different nullifiers, inflating balances inside the pool undetectably. Developers patched it via an emergency soft fork around June 1 and the NU6.2 hard fork on June 3, and found no evidence of exploitation.

How does the Zcash turnstile work? The turnstile is an accounting constraint, specified in ZIP 209, that tracks value entering and leaving each shielded pool. Because amounts crossing a pool boundary are public even when transactions inside are private, the turnstile can enforce that no more ZEC exits Orchard than verifiably entered it, trapping any counterfeit notes inside the sealed pool.

Could I lose my ZEC if the bug was exploited? Only in the scenario that developers consider unlikely, where counterfeit ZEC was both minted and withdrawn before Ironwood, leaving the pool short. In that case the turnstile would stop paying out once the balance was exhausted, and the last holders to migrate would bear the shortfall. Turnstile records and pool accounting show no evidence of unauthorized minting, and the 2018 Sprout precedent, where a comparable bug was never shown to have been exploited, offers some reassurance.

Do I need to update my Zcash node or wallet? Node operators must upgrade to Zebra 6.0.0 or the Zakura client before block 3,428,143 or risk following a minority chain, and zcashd is being retired with end-of-support at block 3,417,100. Ordinary wallet users should run the latest official release of their wallet and follow its native migration flow when available.