Skip to main content

Zcash Foundation

Back to Blog

September 24, 2026

Foundation News

Zebra 6.4.0 and 6.4.1: Security Fixes, Light Client Serving, and NU7 Preparation

Zebra 6.4.0 is a security release that also adds an experimental lightwalletd-compatible gRPC server, lowers the ZIP 317 conventional fee, speeds up block template delivery for miners, and moves the end-of-support halt earlier in preparation for NU7, which is tentatively scheduled for November 5, 2026. Zebra 6.4.1, released the same day, fixes a potential sync stall near the chain tip.Node operators are strongly encouraged to upgrade straight to version 6.4.1. Before 6.4.1 halts around November 2, operators should also prepare to update to the upcoming release planned for next week, which will feature NU7 support.

Security Advisories

GHSA-3c94-hf7p-g5mf: Forged Block Bodies Could Stall Sync

A peer could serve a block with a canonical hash but a forged body whose authorizing data did not match the header commitment. Zebra treated this as an ordinary invalid block, so it canceled the whole sync round, paused the syncer for its restart delay, and dropped the block hash instead of requesting it again, letting a malicious peer repeatedly stall a node’s sync. Zebra now continues the sync round and re-requests the body from another peer, up to a bounded number of retries, and re-requests blocks rejected only because they were queued behind a forged body without penalizing the peers that served them (#11502).

Thanks to @ouicate for reporting this issue.

GHSA-4f6v-mj46-gxg3: Coinbase scriptSig Rewrite Not Penalized on the Inbound Path

Peers relaying blocks with a rewritten coinbase scriptSig on the inbound path were not penalized. Zebra now scores misbehavior for peers that do this (#11502).

Thanks to @craftsoldier (Julian Abraham) for reporting this issue.

GHSA-jhpp-8h75-7pv5: Peer Limits and Bans Apply Per IPv6 /64

Connection limiting under network.max_connections_per_ip and peer bans now apply to a whole IPv6 /64 subnet rather than to each individual address, so a single machine can no longer bypass the limit or evade a ban by connecting from many addresses in the same allocation. IPv4 connections are still limited per address (#11256).

Other Security Improvements

Peer Bans Expire After 24 Hours

Bans now expire after 24 hours instead of lasting until Zebra restarts, so a peer banned by mistake, or one that shares an IPv6 /64 with a misbehaving peer, is not shut out permanently (#11256).

Misbehavior Scoring for Blocks With Duplicate Transactions

Peers that advertise a block containing duplicate transactions are now scored for misbehavior, matching how Zebra treats other definitive block-validity violations (#11157).

Breaking Changes

Earlier End-of-Support Halt Ahead of NU7

The end-of-support window is now 12 weeks instead of 15, so Zebra 6.4.x halts in early November 2026, around November 2, ahead of NU7’s tentative November 5 activation. We recognize that shortening the window is not ideal and do not intend to make it a common practice, but it ensures nodes move to the NU7-supporting release in time. Operators can check their node’s exact halt height and estimated time with the getdeprecationinfo RPC (#11491).

RPC Response Body Size Limit

rpc.max_response_body_size is now limited to 4,294,967,295 bytes. Configurations with larger values must be reduced; they are now rejected when the configuration loads instead of causing an RPC server panic at startup (#11259).

New Features

Experimental Lightwalletd-Compatible gRPC Server

Zebra can now serve Zcash light clients directly. A new experimental gRPC server implements the lightwalletd CompactTxStreamer interface and is enabled by setting rpc.lightwalletd_listen_addr in the config (#10953).

Lower ZIP 317 Conventional Fee

Following zcash/zips#1352, the mempool now accepts transactions paying at least 1,000 zatoshis per ZIP 317 logical action instead of 5,000 (2,000 instead of 10,000 for a minimal transaction), and getstandardfee reports 1,000. Block template construction follows the new conventional fee and raises the fee weight ratio cap from 4 to 10, widening the priority lane for transactions that pay more than the conventional fee (#11290).

Precomputed Block Templates for Miners

When a miner address is configured and the RPC server or internal miner is enabled, Zebra now precomputes block templates, refreshing them on chain tip changes and every few seconds, so getblocktemplate can respond immediately. A template can trail the mempool by a few seconds, but each one is checked against the committed tip (#11371).

Shielded Verification Cache

Zebra now caches Orchard, Ironwood, and Sapling bundle verification results, so proofs and signatures verified when a transaction enters the mempool aren’t verified again when the block that mines it arrives. The cache is reported through new zebra.consensus.cache.* metrics (#11380).

Value Pool Metrics

New zcash.pool.value.zatoshis and zcash.pool.notes.created metrics, labeled by pool, report value pool balances and note commitment counts at the chain tip (#11391).

Bug Fixes

Sync Stall After a Restart Near the Tip (Fixed in 6.4.1)

Zebra could stall permanently after a sync restart near the chain tip, repeatedly logging “queued download of hash behind our chain tip” until the node was restarted. Zebra 6.4.1 fixes this (#11510).

Sync Restart Loop on Transient Timeouts

The syncer no longer restarts when a transparent input lookup times out near the tip, or when the short post-checkpoint verification timeout fires. Both are transient races, and restarting canceled the in-flight parent block, which could cause a restart loop (#11377).

Chain Selection on Equal-Work Ties

When two competing chains have equal cumulative work, Zebra now prefers the chain whose tip it received first, as the Zcash protocol specifies, instead of the chain with the greater tip hash (#11341).

Mempool Peer Slots Freed on Timeout

The mempool now frees a peer’s download slot when one of its transactions times out during verification. Previously, each timeout permanently used a slot until the mempool rejected all further transactions from that peer (#11229).

Consistent z_gettreestate During Reorgs

z_gettreestate no longer returns null commitments for a block that a concurrent reorg moves onto a side chain (#10820).

zcashd-Compat Sidecar Handles Deeper Reorgs

The embedded zcashd-compat sidecar is now pinned to zebra-compat-v1.2.0, which raises its reorg limit from 99 to 1,000 blocks to match Zebra. The previous sidecar shut itself down on reorgs deeper than 99 blocks. Wallets holding shielded notes should expect the witness cache and wallet.dat to grow roughly tenfold, gradually over about 900 blocks. The installer’s split-container Docker mode also now prints a working zcashd container command (#11413).

Other Changes

Dependency and Build Cleanups

Zebra drops the unmaintained ordered-map crate along with its legacy dependencies (#11321), updates nix to 0.31 (#11267), and builds librocksdb-sys so libclang loads correctly when more than one bindgen version is present (#11444).

Upgrading

Zebra 6.4.1 is available from GitHub, crates.io, and Docker Hub as zfnd/zebra:6.4.1. Library consumers should note that zebra-rpc and zebra-state include breaking API changes in this release.

Thank You to Our Contributors

This release was made possible by the work of @alchemydc, @andres-pcg, @aphelionz, @arya2, @Bortlesboat, @CodeMongerrr, @conradoplg, @craftsoldier, @evan-forbes, @gustavovalverde, @jiehuo100net, @john-lawniczak, @LarryRuane, @mpguerra, @natalieesk, @oxarbitrage, @questfever, @robustfengbin, @str4d, @syszery, 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.