Zebra 6.0.0 Release – Zcash Foundation

Zebra 6.0.0: NU6.3 “Ironwood” Mainnet Activation

We are releasing Zebra 6.0.0 today. This is the first stable release with support for the NU6.3 “Ironwood” network upgrade on Mainnet, setting the Ironwood activation height at 3,428,143. It promotes the work first shipped in 6.0.0-rc.0 to a stable release, and adds a mempool-verification security fix, several networking and read-state fixes, and a new build-time dependency (libclang) made since the release candidate. All node operators should upgrade before NU6.3 activates on Mainnet.

NU6.3 “Ironwood” Support

Zebra 6.0.0 activates the NU6.3 “Ironwood” shielded pool and v6 transaction format on Mainnet at height 3,428,143 (expected around 13:00 UTC on July 28, 2026), alongside the Testnet activation height of 4,134,000 introduced in the release candidate. (#10938) Ironwood adds a new shielded pool that reuses Orchard’s Action and Halo2 proof system while adding its own note commitment tree, nullifier set, chain value pool, and chain-history metadata, delivered through a new v6 transaction format.

The z_gettreestate, z_getsubtreesbyindex, and verbose getblock RPCs expose the Ironwood note commitment tree and its subtree roots from NU6.3 activation, and the getblockchaininfo and getblock valuePools fields include the Ironwood pool. (#10762, #10888)

This stable release also updates the zcash_* and orchard crates from the pre-release versions used in the release candidate to their released NU6.3 versions.

For the full set of features first introduced in the release candidate (signed pre-built zebrad binaries, the block-notify command, resumable indexer streaming, and the two security fixes GHSA-x6v8-c2xp-928m and GHSA-m9xx-8rcj-vmgp), see the 6.0.0-rc.0 release notes.

Security Advisories

GHSA-84j3-rw4c-gqmj: High-Signature-Operation P2SH Mempool Verification (Moderate)

Zebra ran full script verification on a mempool transaction before the cheap policy checks that would reject a non-standard, high-signature-operation P2SH script, so a peer sending transactions that are cheap to produce but expensive to verify could occupy the bounded verification capacity and degrade the responsiveness of mempool and block verification while the load persisted. The impact is availability degradation only, with no crash, consensus fault, invalid-block acceptance, or loss of funds, and it clears once the load subsides. Zebra now rejects mempool transactions with non-standard transparent inputs before script verification, and script verification now runs on the shared Rayon thread pool rather than blocking an async runtime worker; block (consensus) validation still runs full script verification.

Thanks to ouicate for reporting this issue, supplying a proof of concept, and refining the analysis during triage.

This is the latest in a series of mempool peer-fairness and resource-accounting hardening fixes, following the per-peer download cap (GHSA-4fc2-h7jh-287c) and the direct-push accounting fix shipped in 6.0.0-rc.0 (GHSA-m9xx-8rcj-vmgp).

Bug Fixes Since the Release Candidate

Mempool Stays Active Through Sync Noise

Once the mempool has started, Zebra no longer clears it or cancels its queued transaction verification when a transient signal (which lower-work forks or stale peers can trigger) reports the node is far from the tip. Initial mempool activation still waits until Zebra is near the chain tip. (#10929)

Peer Connections at the Chain Tip

Zebra no longer disconnects from peers that return empty FindBlocks or FindHeaders responses when the local node is at or near the chain tip. (#10732)

Read-State Syncer Startup Hang

Fixed a read-state syncer startup hang where a co-located consumer whose finalized state had caught up past the node’s non-finalized root would re-subscribe endlessly instead of syncing, advancing only one block per newly mined block. (#10841)

Syncer Restarts

Fixed syncer restarts caused by incorrect error downcasting; wrapped state-commit duplicate errors are now correctly classified as duplicate requests. (#10916)

Build and Compatibility Changes

• New build dependency: rocksdb was updated to 0.24, and the bundled librocksdb-sys now always runs bindgen, so libclang is required at build time (in addition to protoc and a C++ compiler), even when linking a system RocksDB via ROCKSDB_LIB_DIR. Install libclang-dev (Debian/Ubuntu), clang (Arch), or the equivalent for your platform. (#10922)
• The workspace (libraries) minimum supported Rust version is raised from 1.85.1 to 1.88. The zebrad binary MSRV is unchanged at 1.91. (#10927)

State Database Format

Zebra 6.0.0 uses state database format 28.0.0, introduced in the release candidate for the Ironwood shielded pool. This is a major-version bump that migrates in place from the previous major format, so no resync is required. Note that downgrading is not supported, so if you want to ensure you can rollback to an older version of Zebra if something goes wrong, then backup the state before upgrading Zebra.

Upgrading

You can find the release on GitHub, crates.io, and Docker Hub. Because this release sets the NU6.3 Mainnet activation height, all node operators should upgrade before Ironwood activates to remain on the correct chain.

Thank You to Our Contributors

This release was made possible by the work of @conradoplg, @Cosmos-Harry, @dannywillems, @jvff, and @upbqdn. Thank you for your continued contributions to Zebra.

Zebra is the Zcash Foundation’s independent, Rust-based implementation of the Zcash protocol. Learn more at github.com/ZcashFoundation/zebra.