The Zcash Foundation has released Zebra v6.2.3, an optional node update focused on strengthening peer connectivity and synchronization behavior. The July 28 release is intended primarily for operators experiencing unstable peer sets or seeking to reduce the risk of future connectivity problems, rather than introducing new consensus rules or a broad Zcash network upgrade.
Zebra is the Foundation’s independent, Rust-based implementation of the Zcash protocol, supporting block validation, transaction relay and peer-to-peer network participation. Version 6.2.3 concentrates on how nodes discover, select and retain useful peers, making its immediate impact operational for exchanges, infrastructure providers and independent node administrators.
Synchronization Logic Prioritizes Block-Serving Peers
During an initial blockchain synchronization, Zebra will now require outbound peers to advertise the NODE_NETWORK service, indicating that they can provide historical block data. Outbound slots could previously become occupied by non-serving peers, potentially leaving a fresh node unable to advance from genesis. The new selection rule reduces the likelihood that unusable connections consume the limited outbound capacity needed for synchronization.
Once a node reaches or approaches the network tip, Zebra can again connect to non-serving participants such as pruned nodes. The release also changes the peer crawler so that it attempts to replace every dropped outbound connection when a suitable address is available. Zebra will continue dialing until its configured outbound connection limit is restored, rather than waiting until its ready-peer pool is exhausted or all outbound links have disappeared.
Peer discovery has also been expanded through larger getaddr responses. Zebra can now share as much as half of its address book with a requesting peer, up from one quarter in earlier builds. Providing a larger sample of reachable addresses should help nodes discover more of the Zcash network through each peer interaction, although connection quality will still depend on the availability and behavior of those endpoints.
The update makes stall detection more tolerant when a node is within 1,000 estimated blocks of the chain tip. Empty FindBlocks or FindHeaders responses will no longer automatically trigger a disconnection in that range, where normal gaps between new blocks can resemble an unresponsive peer. The adjustment is designed to prevent healthy connections from being discarded during ordinary periods of limited block activity.
Ironwood Transition Receives Additional Compatibility Protection
Zebra v6.2.3 also avoids penalizing peers for temporary disagreements between the NU6.2 and NU6.3 consensus branch identifiers within 40 blocks on either side of the Ironwood activation height. Short-lived chain-tip differences can occur as nodes transition between protocol versions. The revised relay behavior prevents those expected mismatches from producing unnecessary peer bans during the upgrade boundary.
Operators using Zebra’s experimental supervised zcashd compatibility mode face a more specific upgrade requirement. The embedded release manifest now uses the zebra-compat-v1.1.0 sidecar, which can follow mainnet beyond Ironwood’s activation at block 3,428,143. The previous embedded sidecar stops following the chain at that height, so affected deployments must install the newer Zebra release or configure a current sidecar binary manually.
The release additionally retains the final block hash returned through FindBlocks synchronization responses and updates several librustzcash dependencies to their production NU6.3 versions. The Foundation states that the dependency changes do not alter node behavior. These refinements align Zebra’s supporting libraries and synchronization logic with the current Zcash protocol environment without introducing a separate network activation.
Zebra v6.2.3 remains a proactive maintenance update rather than an emergency deployment. Its practical value will be most visible on nodes experiencing incomplete outbound sets, stalled initial synchronization or false disconnections near the chain tip. The release confirms availability through GitHub, crates.io and Docker Hub, while broader deployment levels have not been disclosed.
