Zcash locks Ironwood upgrade for July 28 to close Orchard shielded pool
NU6.3 forces an accounting checkpoint during migration that could surface evidence of counterfeit ZEC tied to the “infinity” bug.
Zcash has set Ironwood (NU6.3) to activate at block height 3,428,143, estimated around July 28 at 8AM EST, closing the current Orchard shielded pool and standing up a new private pool. The forced migration includes an accounting checkpoint that is framed as potentially producing evidence of any counterfeit ZEC linked to the Orchard “infinity” bug.
Key Takeaways
- Ironwood (NU6.3) is scheduled to activate on Zcash mainnet at block height 3,428,143, with an estimated activation time around July 28 at 8AM EST.
- The upgrade shuts the current Orchard shielded pool to new activity and introduces a new private pool under Ironwood.
- Funds exiting Orchard must pass an accounting checkpoint before entering the new pool, a mechanism described as potentially producing evidence of counterfeit ZEC tied to the “infinity” bug.
- ZEC sold off from $602.68 to $299.25 after the June 3 bug disclosure and later traded around $492.61, showing sensitivity to supply-integrity headlines.
Ironwood Activation Height Is Set: July 28 Target for NU6.3
Ironwood now has a hard activation coordinate traders can anchor to. Zcash core developer Sean Bowe said the Ironwood mainnet activation height has been “set and tagged,” with “all of the major organizations” committed to activating NU6.3 at height 3,428,143, which he estimated as approximately July 28 at 8AM EST.
That estimate is inherently block-time dependent, but the market structure point is simpler. A named block height turns this into a defined event window rather than an open-ended “sometime late July” upgrade risk.
The other operational detail that matters is the slip. Bowe’s comment also confirmed Ironwood will proceed one week later than an earlier July 21 target. That one-week move is not just calendar noise. It is an explicit acknowledgment that readiness and coordination were live constraints, even if the network is still pushing ahead.
Orchard Pool Closure and the New Migration Rules
Ironwood is not a routine parameter tweak. It is a forced lane change for Zcash’s shielded flow.
The upgrade closes the current Orchard pool, prevents new activity in it, and establishes a new private pool under Ironwood. The key mechanism is the migration rule. Funds leaving Orchard must pass through an accounting checkpoint before they can enter the new Ironwood pool.
What stands out here is the asymmetry it creates. Users can still move, but they cannot move in a way that bypasses the checkpoint. That design choice is the whole point of making the upgrade a “tradeable” event. The network is not leaving the old pool open-ended while hoping activity naturally migrates. It is shutting the door and forcing an audited choke point for exits.
Shielded Labs framed the migration dynamic in adversarial terms. “As users migrate funds from the existing Orchard pool to the new pool, any hypothetical counterfeiter faces a choice: attempt to move counterfeit funds and risk exposing their existence, or leave them behind and risk being unable to move them in the future.”
For traders, that reads like engineered pressure. The protocol change is designed to make certain behaviors costly or revealing during the transition.
Counterfeit-ZEC Risk: What the Checkpoint Can Reveal
The counterfeit-ZEC question is the catalyst risk, and it is also where the story is most explicitly uncertain.
Ironwood is positioned as the fix for an “infinity” bug discovered in May on Orchard, Zcash’s main shielded transaction pool. The accounting checkpoint is described as something that “could produce evidence” about whether counterfeit ZEC was produced through the Orchard bug.
That wording matters. “Could produce evidence” is not the same as “will prove” and it is not the same as “counterfeit coins exist.” There is no confirmation in the disclosed facts that the vulnerability was exploited or that counterfeit ZEC is in circulation.
The pattern worth noting is how the market has already priced the narrative once. After the bug disclosure on June 3, ZEC fell about 50% to $299.25 from $602.68. By the time of writing on July 10, ZEC was trading around $492.61, a partial recovery that still leaves the asset anchored to the bug timeline.
That price path sets a precedent. New information tied to supply integrity has already produced a large repricing, and the checkpoint is explicitly framed as a mechanism that might generate more information.
There is also a broader supply context that can amplify sensitivity. A ruZCASH post stated Zcash supply reached 16,806,723 ZEC, putting issuance above 80% of the 21 million maximum supply. That does not answer the counterfeit question, but it does underline why “supply integrity” headlines hit harder when the issued supply is already well advanced.
Signals Traders Should Track Into Activation Week
The first signal is mechanical. Track block-height progress toward 3,428,143 and any updated estimates for the approximate July 28, 8AM EST activation time. If block production runs faster or slower than expected, the real-world timing shifts, and so does the window for operational pauses.
Second is ecosystem readiness messaging. Shielded Labs previously warned that exchanges, mining pools, and wallets might not have enough time to prepare for a late-July activation and floated delaying the upgrade. Even with the one-week slip from July 21 to July 28, readiness remains a live variable. Watch for exchange and wallet communications around upgrade support, and especially any deposit or withdrawal pauses around the activation height.
Third is the post-activation information flow tied to the accounting checkpoint. The market is likely to treat any disclosure about whether evidence of counterfeit ZEC was observed during Orchard-to-Ironwood migration as the real headline, not the fact that the upgrade executed.
Finally, keep ZEC’s spot reaction in context. The June 3 disclosure coincided with a move from $602.68 down to $299.25, and the later trade around $492.61 shows the market has already been whipsawed by this theme. That history raises the odds of volatility clustering around new checkpoint-related headlines.
Upgrade Risk Premium vs. Supply-Integrity Relief
I’m treating Ironwood as two events layered on top of each other. One is the protocol upgrade at a known height. The other is the possibility that the accounting checkpoint produces evidence tied to counterfeit ZEC. The first is scheduled. The second is explicitly unconfirmed.
Scenario one is clean execution with no meaningful post-activation disclosure beyond “upgrade successful.” In that case, the market is left with a resolved operational risk and an unresolved narrative risk. The upgrade risk premium should compress because the chain did what it said it would do at height 3,428,143, and the one-week slip would look like normal coordination friction rather than a deeper issue. Confirmation for this scenario is straightforward: major venues keep deposits and withdrawals stable through the activation window, and there are no follow-on statements pointing to anomalies at the checkpoint.
Scenario two is operational friction that becomes the headline. Shielded Labs already warned that exchanges, mining pools, and wallets might not have enough time to prepare. If activation week brings widespread pauses, delayed support, or fragmented readiness, the market can end up trading microstructure instead of fundamentals. Liquidity thins when venues pause rails, and thin liquidity makes every incremental headline hit harder. Confirmation here is a wave of readiness notices and extended deposit or withdrawal halts around the activation height.
Scenario three is the one that actually re-rates the asset. If the checkpoint produces evidence consistent with counterfeit ZEC, the market has a precedent for violent repricing because it already sold off roughly 50% on the June 3 disclosure alone. The key is that this scenario requires new, concrete disclosure tied to the checkpoint process, not just renewed debate about the original bug. Confirmation would be explicit post-activation communication that evidence was observed during migration. Invalidation is equally clear: no such disclosure emerges after activation, and the narrative gradually loses urgency as Orchard is closed and activity shifts to the new pool.
My base case, given only the facts in hand, is that the tradeable edge is the defined event window created by a forced Orchard shutdown and checkpointed migration, with the real catalyst being whether the checkpoint produces evidence of counterfeit ZEC rather than the upgrade mechanics themselves. The thesis is confirmed if post-activation disclosures explicitly address what the accounting checkpoint did or did not reveal about counterfeit ZEC during Orchard-to-Ironwood migration.
