We are pleased to announce the release of Zebra 7.0.0, the first stable release with support for NU7 on Mainnet. NU7 brings blocks every 25 seconds instead of every 75, a Network Sustainability Mechanism that recycles part of every transaction fee into future block rewards, and new shielded limits that protect wallets from spam. It activates on Mainnet at height 3,543,405, planned for around November 5 as per the NU7 timeline. This release also brings faster, more reliable syncing near the chain tip and fixes seven security advisories. All Mainnet node operators must upgrade before NU7 activates to stay on the consensus chain.
NU7 Comes to Mainnet
Faster Payments
Today a Zcash user waits 75 seconds on average for a first confirmation. Under ZIP 218, NU7 cuts the target block spacing to 25 seconds, so the average wait users see is about three times shorter. The amount of ZEC issued per day stays the same: block rewards are divided by three, the remaining halving intervals are tripled, and funding stream periods are adjusted to match. (#11529)
Adjusted Issuance
Block rewards shrink with every halving, and one day the network will rely on fees to pay for its security. NU7 starts preparing for that now. Under ZIP 235, 60% of each block’s transaction fees are removed from circulation and placed in a reserve, while miners keep the other 40% so they still have every reason to include transactions. Under ZIP 237, blocks will later reissue a small, predictable portion of that reserve on top of their normal reward; on Mainnet that starts at height 8,939,664, as set out in ZIP 259. The four year halving schedule and the 21 million ZEC supply cap are both unchanged. (#11454, #11487, #11530)
More Shielded Capacity, Lighter Wallet Sync
NU7 adds per block limits on Orchard, Ironwood and Sapling activity, and no new Sprout JoinSplits. As specified in ZIP 218, these limits more than double Orchard throughput (2.9 to 6.6 transactions per second) while cutting the worst case sync bandwidth a spammer can push onto light wallets by about 37%. Zebra applies the same limits when it builds block templates and when it admits transactions to the mempool, so oversized transactions are turned away early. (#11529)
Tested on Testnet First
NU7 has been live on public Testnet since height 4,465,026, activated by Zebra 7.0.0-rc.0. Testnet also showed us that bursts of competing blocks could leave a node stuck on a losing branch, which this release fixes. Thank you to everyone who ran the release candidate and told us what they saw.
Breaking Changes
If you are upgrading from Zebra 6.x, please also read the 7.0.0-rc.0 release notes, which include breaking configuration and RPC changes that now apply on Mainnet.
Mainnet Node Operators
Upgrade before height 3,543,405. After activation, NU7 nodes disconnect peers that run older versions, and nodes that have not upgraded will follow a different chain. Zebra 7.0.0 migrates your state database to a new format the first time it starts, see State Database Format below. This release is supported for 8 weeks instead of the usual 12. (#11830)
Miners and Pools
Zebra 7.0.0 lists only time as mutable in getblocktemplate, because the required coinbase commits to the fees of the selected transactions and to the block subsidy. Request a new template instead of changing the transaction set or the previous block yourself. From NU7, as specified in ZIP 235, 60% of each block’s fees are removed from circulation, so coinbases claim only the miner’s 40% share. (#11487, #11530)
Wallets, Exchanges and Other Services
Once NU7 activates, version 4 transactions are no longer valid, as set out in ZIP 2003 and ZIP 259. Version 5 and version 6 transactions remain valid. Because Sprout transfers can only use version 4, funds left in the Sprout pool become unspendable. (#11830)
The address RPCs now have limits: getaddresstxids and getaddressutxos return an error instead of doing unbounded work when a query matches more than 100,000 results, and these methods accept at most 10,000 addresses per call. (#11662)
getaddressbalance, getaddressutxos and getaddresstxids, and the lightwalletd gRPC address methods, now return an error for TEX addresses instead of an empty result, because the address index only records the underlying P2PKH address. Query the P2PKH address the TEX address was derived from instead. (#11823)
Tools that read Zebra’s state database directly, including Zallet’s Zebra backend and Zaino’s Zebra read state backend, must be upgraded to a v29 compatible build at the same time as the node.
Monitoring and Alerting
Peer metrics no longer carry per peer addr, remote_ip or user_agent labels, and RPC metrics label unknown method names as unknown. Some log lines changed too: a fatal error that stops Zebra is now logged at error level, and the genesis wait message appears once a minute. Update dashboards and alerts that use these labels or lines; the bundled dashboards are already updated. (#11837, #11850)
zcashd Compatibility Mode
Zebra no longer publishes zcashd compatibility Docker images, so the Docker options for that mode are removed. Use the installer’s split-binary, supervised or build-from-source modes instead. The pinned sidecar moves to zebra-compat-v1.3.0; earlier sidecar builds cannot follow Mainnet past NU7. (#11869, #11871)
Library Users
Expect breaking API changes in zebra-chain, zebra-consensus, zebra-network, zebra-rpc and zebra-state, including updates to the NU7 releases of the shared Zcash libraries. (#11614, #11784)
Security Advisories
GHSA-9hq5-pfgc-cx5h: Forged Checkpoint Block Stalls Initial Sync (High)
During initial sync, a peer that served a forged body for a checkpoint block could stop Zebra from downloading the honest block again until the node was restarted. After a checkpoint block fails to commit, Zebra now forgets the blocks above the finalized tip so they can be fetched again. (#11877)
Thanks to @saxenism for reporting this issue via coordinated disclosure, and to @x15-eth, @manus-pi, @ouicate and @Nathanbyarugaba for independently reporting it.
GHSA-2w9f-9wx8-f5c8: Checkpoint Verifier Left Ahead of the State (High)
Related to the issue above: a forged checkpoint block body followed by an invalid block could leave the checkpoint verifier ahead of the state, so Zebra rejected the honest block until restart. The verifier now resets its progress to the state tip after any failed checkpoint commit. (#11877)
Thanks to @SphereDonout (Xifeng Jin, CertiK) for reporting this issue.
GHSA-6v36-c42v-v98p: Panic When Disconnecting a Busy Peer (Medium)
Zebra could panic and stop if it disconnected a peer while still waiting for that peer to accept a request. The request now fails with the connection’s error instead. (#11877)
Thanks to @SphereDonout (Xifeng Jin, CertiK) for reporting this issue.
GHSA-jq45-ghw5-v37x: No Penalty for Invalid Transparent Scripts (High)
A peer could keep Zebra’s transaction and block verification busy with transactions whose transparent scripts fail, without ever being banned. Script failures now carry the full misbehavior score, so such peers are banned. (#11877)
Thanks to @x15-eth for reporting this issue and @ouicate for independent rediscovery.
GHSA-j4cw-58mj-7w6v: Quadratic Cost of Signature Hashes (High)
A single 2 MB transaction with tens of thousands of stub signed inputs could keep a node’s CPU busy for minutes, because each input’s signature hash was computed from scratch. Zebra now computes these hashes from digests cached once per transaction, so the cost grows linearly with the number of inputs. (#11877)
Thanks to @asafmod for reporting this issue and @x15-eth and @janneh2000 for independent rediscovery.
GHSA-7jp4-mq53-4cvq: Mempool Coinbase Maturity Check Pins Verification Threads (High)
Any connected peer could make Zebra spend tens of seconds of CPU on one transaction with many transparent inputs and outputs, because the mempool’s coinbase maturity check rebuilt the transaction’s output list once per input. The transaction was rejected without a misbehavior score, so the peer could keep repeating it and, on nodes with few cores, stall block verification and sync while it did. Zebra now runs the check once per transaction. This regression appeared in Zebra 6.4.0; 6.3.0 and earlier are not affected. (#11877)
Thanks to @janneh2000 for reporting this issue.
GHSA-5h3r-fpmj-483w: Honest Peers Banned Over Lock Time Rejections (Medium)
A node one block behind a peer could ban that peer for relaying a valid transaction whose lock time is only satisfied at the next block: for 24 hours on 6.4.x, and until restart on 4.5.0 through 6.3.x. Anyone could trigger this on purpose to cut a node off from its best connected peers. Lock time rejections no longer count against peers, though the transaction is still rejected until it becomes valid. (#11627)
Thanks to @SphereDonout (Xifeng Jin, CertiK) for reporting this issue and @sangsoo-osec for independently reporting it.
Other Security Improvements
- A peer supplied byte count can no longer force a large memory allocation before any data arrives. (#11420)
- The per peer limit on inbound mempool downloads now applies per IP address, so one host cannot get around it by connecting from several ports. (#11233)
- Zebra caps how many transaction IDs it looks up for each peer request, matching the existing cap for blocks. (#11722)
- Banned, outdated and stuck peer connections no longer stop Zebra from trying other peers, and stuck connections are dropped to free their slots. (#11750)
- Updated rustls,
rustls-webpkiandwebpki-rootsfor RUSTSEC-2026-0346 to 0349 and to distrust compromised eMudhra certificate keys. Zebra’s peer and RPC connections do not use TLS, so only outbound HTTPS clients such as Sentry and OpenTelemetry were affected. (#11725, #11825)
New Features
z_converttex
Wallets and services can now ask Zebra to convert a transparent P2PKH address to a ZIP 320 TEX address. (#11823)
Clearer Crash and Health Reporting
Operators who use Sentry now get release health for each zebrad run, events tagged with the network, chain tip height and network upgrade, and panic reports titled with the actual panic message, so different crashes show up as different issues. Nodes without Sentry configured no longer pay a per span tracing cost for it. (#11850, #11849)
zcashd API Migration Guide
A new Zebra book page lists every RPC method zcashd registers and says whether Zebra or Zallet provides it, what replaces it, or why it was retired. It is written for exchanges, wallets and services planning their move off zcashd. (#11329)
Bug Fixes
Nodes That Stopped Near the Chain Tip
Some Mainnet nodes running Zebra 6.4.x stopped syncing near the top of the chain, as first reported on a 6.4.1 node. Zebra now waits for a busy peer that can serve the next block instead of giving up, spreads its search for new blocks across peers that actually serve them, stops asking a peer that already failed to deliver a block, and keeps a second download going when the first one fails. (#11521, #11515, #10910, #11532, #11525, #11737, #11781)
Mined Blocks Reach the Network Promptly
Block announcements now reach busy peers without waiting behind ordinary requests, and broadcasts no longer stall when peers disconnect. Previously the gossip task could stall with no ready peers, and submitblock could then return errors for blocks that had in fact been committed. Peers also get an immediate reply when the mempool is empty, which removes relay delays of up to 6 seconds on single peer links. (#11839, #11838, #11477, #11786)
No More Losing Branches
When many competing blocks arrived at once, as in Testnet minimum difficulty bursts, Zebra could get stuck on a losing branch. Fork handling now keeps the chain it just committed and the best chain, and test networks keep more forks. Thanks to @tuan-phan and @SphereDonout. (#11582)
Shared Outputs Stay in the UTXO Caches
When two queued or sent blocks contained the same transaction, removing one of them could drop their shared outputs from Zebra’s UTXO caches. Zebra now keeps those outputs until the last block that creates them is removed. Thanks to @ouicate for the report. (#11787)
RPC Fixes
getinfo, getnetworkinfo and getpeerinfo no longer stall other RPC requests while the node handles a large batch of peer addresses. Requests with an explicit "id": null are now answered, errors for invalid parameters keep their original data field, invalidateblock returns an error instead of exiting when it targets the only non finalized chain root, and Rust clients that use Zebra’s RPC types can now read every ZEC amount Zebra reports. (#11702, #11625, #11733, #11562, #11457)
State Database Format
Zebra 7.0.0 uses state database format v29. The first time it starts, Zebra migrates an existing v28 database to v29 automatically, so no resync is required. If you already run 7.0.0-rc.0, this has already happened. Zebra 6.x cannot read the v29 database, so going back to 6.x after upgrading means a full resync. If you want a way back, back up the state/v28 directory in your state.cache_dir before upgrading.
Upgrading
You can find the release on GitHub, crates.io, and Docker Hub as zfnd/zebra:7.0.0. The release notes list every change in full technical detail. All Mainnet node operators should upgrade before height 3,543,405 to remain on the correct chain after NU7 activates.
Thank You to Our Contributors
This release was made possible by the work of @alchemydc, @andres-pcg, @arcayne, @arya2, @conradoplg, @DrVelvetFog, @gustavovalverde, @idky137, @jiehuo100net, @mpguerra, @natalieesk, @nuttycom, @oxarbitrage, @robustfengbin, @upbqdn, @vbar, and @zmanian. 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.