# Zebra 7.0.0 Release **URL:** \ **Category:** Zcash Foundation\ **Created:** [October 22, 2026, 4:52pm UTC](https://forum.zcashcommunity.com/t/zebra-7-0-0-release/58442 "2026-10-22T16:52:12Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![ZcashFoundation](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcashfoundation/32/21548_2.png) [@ZcashFoundation](https://forum.zcashcommunity.com/u/ZcashFoundation)\ **Post date:** [October 22, 2026, 4:52pm UTC](https://forum.zcashcommunity.com/t/zebra-7-0-0-release/58442/1 "2026-10-22T16:52:12Z")
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](https://forum.zcashcommunity.com/t/nu7-timeline/57655). 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](https://zips.z.cash/zip-0218), 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](https://github.com/ZcashFoundation/zebra/pull/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](https://zips.z.cash/zip-0235), 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](https://zips.z.cash/zip-0237), 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](https://zips.z.cash/zip-0259). The four year halving schedule and the 21 million ZEC supply cap are both unchanged. ([#11454](https://github.com/ZcashFoundation/zebra/pull/11454), [#11487](https://github.com/ZcashFoundation/zebra/pull/11487), [#11530](https://github.com/ZcashFoundation/zebra/pull/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](https://zips.z.cash/zip-0218), 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](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/releases/tag/v7.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](https://github.com/ZcashFoundation/zebra/releases/tag/v7.0.0-rc.0), 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](https://github.com/ZcashFoundation/zebra/pull/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](https://zips.z.cash/zip-0235), 60% of each block’s fees are removed from circulation, so coinbases claim only the miner’s 40% share. ([#11487](https://github.com/ZcashFoundation/zebra/pull/11487), [#11530](https://github.com/ZcashFoundation/zebra/pull/11530)) ### **Wallets, Exchanges and Other Services** Once NU7 activates, version 4 transactions are no longer valid, as set out in [ZIP 2003](https://zips.z.cash/zip-2003) and [ZIP 259](https://zips.z.cash/zip-0259). 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](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11837), [#11850](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11869), [#11871](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11614), [#11784](https://github.com/ZcashFoundation/zebra/pull/11784)) ## **Security Advisories** ### **[GHSA-9hq5-pfgc-cx5h](https://github.com/ZcashFoundation/zebra/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](https://github.com/ZcashFoundation/zebra/pull/11877)) Thanks to [@saxenism](https://github.com/saxenism) for reporting this issue via coordinated disclosure, and to [@x15-eth](https://github.com/x15-eth), [@manus-pi](https://github.com/manus-pi), [@ouicate](https://github.com/ouicate) and [@Nathanbyarugaba](https://github.com/Nathanbyarugaba) for independently reporting it. ### **[GHSA-2w9f-9wx8-f5c8](https://github.com/ZcashFoundation/zebra/security/advisories/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](https://github.com/ZcashFoundation/zebra/pull/11877)) Thanks to [@SphereDonout](https://github.com/SphereDonout) (Xifeng Jin, CertiK) for reporting this issue. ### **[GHSA-6v36-c42v-v98p](https://github.com/ZcashFoundation/zebra/security/advisories/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](https://github.com/ZcashFoundation/zebra/pull/11877)) Thanks to [@SphereDonout](https://github.com/SphereDonout) (Xifeng Jin, CertiK) for reporting this issue. ### **[GHSA-jq45-ghw5-v37x](https://github.com/ZcashFoundation/zebra/security/advisories/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](https://github.com/ZcashFoundation/zebra/pull/11877)) Thanks to [@x15-eth](https://github.com/x15-eth) for reporting this issue and [@ouicate](https://github.com/ouicate) for independent rediscovery. ### **[GHSA-j4cw-58mj-7w6v](https://github.com/ZcashFoundation/zebra/security/advisories/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](https://github.com/ZcashFoundation/zebra/pull/11877)) Thanks to [@asafmod](https://github.com/asafmod) for reporting this issue and [@x15-eth](https://github.com/x15-eth) and [@janneh2000](https://github.com/janneh2000) for independent rediscovery. ### **[GHSA-7jp4-mq53-4cvq](https://github.com/ZcashFoundation/zebra/security/advisories/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](https://github.com/ZcashFoundation/zebra/pull/11877)) Thanks to [@janneh2000](https://github.com/janneh2000) for reporting this issue. ### **[GHSA-5h3r-fpmj-483w](https://github.com/ZcashFoundation/zebra/security/advisories/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](https://github.com/ZcashFoundation/zebra/pull/11627)) Thanks to [@SphereDonout](https://github.com/SphereDonout) (Xifeng Jin, CertiK) for reporting this issue and [@sangsoo-osec](https://github.com/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](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11233)) - Zebra caps how many transaction IDs it looks up for each peer request, matching the existing cap for blocks. ([#11722](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11750)) - Updated rustls, `rustls-webpki` and `webpki-roots` for 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](https://github.com/ZcashFoundation/zebra/pull/11725), [#11825](https://github.com/ZcashFoundation/zebra/pull/11825)) ## **New Features** ### `z_converttex` Wallets and services can now ask Zebra to convert a transparent P2PKH address to a [ZIP 320](https://zips.z.cash/zip-0320) TEX address. ([#11823](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11850), [#11849](https://github.com/ZcashFoundation/zebra/pull/11849)) ### **`zcashd` API Migration Guide** A new [Zebra book page](https://zebra.zfnd.org/user/zcashd-api-migration-guide.html) 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](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11521), [#11515](https://github.com/ZcashFoundation/zebra/pull/11515), [#10910](https://github.com/ZcashFoundation/zebra/pull/10910), [#11532](https://github.com/ZcashFoundation/zebra/pull/11532), [#11525](https://github.com/ZcashFoundation/zebra/pull/11525), [#11737](https://github.com/ZcashFoundation/zebra/pull/11737), [#11781](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11839), [#11838](https://github.com/ZcashFoundation/zebra/pull/11838), [#11477](https://github.com/ZcashFoundation/zebra/pull/11477), [#11786](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/tuan-phan) and [@SphereDonout](https://github.com/SphereDonout). ([#11582](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ouicate) for the report. ([#11787](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/pull/11702), [#11625](https://github.com/ZcashFoundation/zebra/pull/11625), [#11733](https://github.com/ZcashFoundation/zebra/pull/11733), [#11562](https://github.com/ZcashFoundation/zebra/pull/11562), [#11457](https://github.com/ZcashFoundation/zebra/pull/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](https://github.com/ZcashFoundation/zebra/releases/tag/v7.0.0), [crates.io](https://crates.io/crates/zebrad), and [Docker Hub](https://hub.docker.com/r/zfnd/zebra) as `zfnd/zebra:7.0.0`. The [release notes](https://github.com/ZcashFoundation/zebra/releases/tag/v7.0.0) 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](https://github.com/alchemydc), [@andres-pcg](https://github.com/andres-pcg), [@arcayne](https://github.com/arcayne), [@arya2](https://github.com/arya2), [@conradoplg](https://github.com/conradoplg), [@DrVelvetFog](https://github.com/DrVelvetFog), [@gustavovalverde](https://github.com/gustavovalverde), [@idky137](https://github.com/idky137), [@jiehuo100net](https://github.com/jiehuo100net), [@mpguerra](https://github.com/mpguerra), [@natalieesk](https://github.com/natalieesk), [@nuttycom](https://github.com/nuttycom), [@oxarbitrage](https://github.com/oxarbitrage), [@robustfengbin](https://github.com/robustfengbin), [@upbqdn](https://github.com/upbqdn), [@vbar](https://github.com/vbar), and [@zmanian](https://github.com/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](https://github.com/ZcashFoundation/zebra)._ ---
**Author:** ![strahncryptography](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/strahncryptography/32/46464_2.png) [@strahncryptography](https://forum.zcashcommunity.com/u/strahncryptography)\ **Post date:** [October 22, 2026, 5:44pm UTC](https://forum.zcashcommunity.com/t/zebra-7-0-0-release/58442/2 "2026-10-22T17:44:26Z")
As we mentioned in [Ahead of the 10th anniversary.... programmability\* comes to shielded Zcash!](https://forum.zcashcommunity.com/t/ahead-of-the-10th-anniversary-programmability-comes-to-shielded-zcash/58423/1) , is it possible to enforce locktimes across the whole transaction regardless of transparent inputs’ presence or not? It doesn’t really make sense and feels like a stubbon, nitpicky relic from Bitcoin, where developers probably went “eh, locktimes are a transparent thing, so why bother if there are no transparent inputs” Thanks