Zcash Sets July 18 Node Deadline as Zebra Patches Four Security Bugs

Zcash Sets July 18 zcashd-to-Zebra Transition

The immediate task is software coordination. The Foundation said every node operator must be running software capable of handling NU6.3 before the next network upgrade. Operators already using Zebra were told to update to version 6.0.0, while teams leaving zcashd can use Zebra or the new Zakura implementation, depending on their operational setup.

That distinction is important. Zebra is an independent, Rust-based Zcash node maintained by the Foundation, not a new token or a different blockchain. Zcashd is the legacy client being phased out, while Z3 describes a broader collection of node, wallet and indexing tools. A missed upgrade could affect an operator’s ability to follow the correct chain, but it does not mean the Zcash network itself is shutting down.

The Foundation did not publish a comprehensive list of organizations that had finished the switch or a live percentage of infrastructure running Z3. It also did not say whether every large exchange had completed testing. Providers may therefore set their own maintenance windows, and the Foundation’s guidance is for users to ask their wallet or exchange when it will support the new infrastructure.

The timing follows June’s emergency response to an Orchard shielded-pool vulnerability. That incident was patched through NU6.2, and Zcash Foundation said there was no known exploitation or total-supply impact. Our earlier coverage of the Orchard bug and emergency upgrade explains why the ecosystem is now placing unusual emphasis on independently verifiable supply and implementation readiness.

Zcash Foundation also urged operators that adopt Zakura to keep a Zebra instance running as an independent consensus check. The recommendation is not a requirement, but it reflects a familiar operational principle for networks where several implementations validate the same rules: diversity can expose a software-specific failure before it spreads across all infrastructure.

Zebra 6.1.0 Adds Four Node Security Fixes

The operational deadline arrived alongside a fresh software release. The Foundation’s July 17 Zebra 6.1.0 release note added a getstandardfee RPC, which lets wallet and other clients query the ZIP-317 marginal fee, and described four security fixes affecting block verification, node liveness and mining.

The release did not change Zcash consensus rules. That separates it from a network upgrade, where every participant must accept a new set of rules at a specific block height. Still, the Foundation encouraged all node operators to upgrade because the fixes address ways a peer or a malformed workload could make a node less reliable.

One fix prevents a miner from building an oversized block template that other nodes would reject. Another closes an attribution gap for directly pushed transactions that failed verification, allowing the existing peer-scoring system to identify the sender. The remaining fixes address a transparent-value verification path that could become excessively expensive and a stale in-memory entry that could cause a node to stall.

Those descriptions do not establish that any issue was exploited in the wild. The Foundation said the affected cases did not involve a consensus divergence, state corruption or a loss of funds. The practical takeaway is narrower: a node release can matter even when the protocol’s rules do not change, especially when operators are already migrating software under time pressure.

It is also a reminder that upgrades are layered. Protocol rules, node binaries, wallets, indexers and service-provider procedures can all have separate release schedules. The same coordination challenge appears in other networks facing long-horizon security changes, including the debate around Bitcoin’s quantum-wallet migration paths, though Zcash’s current work has its own implementation and supply-verification design.

Ironwood Upgrade Puts Services on a Second Deadline

The next fixed point is Ironwood, also called NU6.3. Zebra 6.0.0 set mainnet activation at block 3,428,143, expected around July 28, and the Foundation said all operators should update before that block. The scheduled height, rather than a wall-clock estimate, is the controlling event.

Ironwood adds a new shielded pool and a version 6 transaction format. It reuses parts of Orchard’s proving system but has its own note-commitment tree, nullifier set, chain value pool and chain-history metadata, according to the Foundation’s July 10 Zebra 6.0.0 release.

For wallet users, the key difference is that Ironwood will seal the older Orchard pool. Existing Orchard funds will be able to leave through the network’s turnstile mechanism, which is designed to ensure no more ZEC exits than entered. Wallet providers are still building migration support, so the Foundation said some funds may be temporarily unavailable in a particular wallet until that provider is ready.

The project has been careful not to frame this as evidence that counterfeit ZEC exists. Its July 18 update said the Ironwood design lets a node operator independently verify supply constraints whether or not the earlier Orchard flaw was ever exploited. That is a stronger and more limited claim than saying the historical question has been conclusively answered.

The broad Crypto Fear and Greed Index was 25, or Extreme Fear, when checked. The Bitcoin-focused measure does not assess Zcash software risk, but it places a sharply moving privacy-coin market in a cautious wider backdrop.

What remains unclear is how many service providers have completed both the zcashd transition and their Ironwood preparation, and which maintenance windows users will encounter. The next observable tests are provider status updates, node-version adoption and the planned NU6.3 activation at block 3,428,143, not a price target or a new token event.