We are pleased to announce the release of Zebra 7.0.0-rc.0, the first release candidate for NU7, the next Zcash network upgrade. NU7 brings blocks every 25 seconds instead of every 75, a new 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 public Testnet at height 4,465,026, expected around October 6. Testnet operators should upgrade before then to stay on the NU7 chain and help us test it under real conditions. Mainnet operators do not need to do anything yet: no Mainnet activation height has been set, and this is a release candidate, not a stable release.
Why NU7 Matters
Payments That Confirm Three Times Faster
Today a Zcash user waits 75 seconds on average for a first confirmation. That is a real obstacle at a point of sale, for exchange deposits, and for cross chain bridges. Under ZIP 218, NU7 cuts the target block spacing to 25 seconds, so the average wait for a first confirmation drops to 25 seconds. The amount of ZEC issued per day stays exactly the same: Zebra triples the remaining halving intervals and divides each scheduled block reward by three, and adjusts funding stream periods to match. (#11529)
A Security Budget That Outlasts 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, each block then reissues a small, predictable portion of that reserve on top of its normal reward. The familiar four year halving schedule and the 21 million ZEC supply cap are both unchanged. The public reserves start out seeded with the historical shortfall from before NU6. (#11454, #11487, #11530)
More Shielded Capacity, Lighter Wallet Sync
Faster blocks also mean more room for shielded transactions. NU7 adds per block limits: 330 Orchard or Ironwood actions, 300 Sapling inputs and outputs, a shared budget of 330 across pools, and no new Sprout JoinSplits. These limits more than double Orchard protocol throughput while reducing the worst case sync load a spammer can push onto light wallets by about 37%. Zebra enforces the same limits when it builds block templates and when it admits transactions to the mempool, so oversized transactions are turned away early. (#11529)
Why Testnet Comes First
Changes this deep touch consensus, mining, wallets, and the node’s own database, so they need time on a live network before they reach Mainnet. This release candidate is how we get that time. If you run Testnet infrastructure, mine on Testnet, or build wallets and indexers, upgrading now and reporting what you see is the most useful thing you can do to get NU7 ready for Mainnet.
Breaking Changes
Testnet Node Operators
Upgrade before height 4,465,026. On public Testnet, NU7 activates at that height, the adjusted third halving is at 4,497,948, and reserve reissuance begins at 7,305,222. If your config pins public Testnet consensus values in [network.testnet_parameters], such as an activation schedule without NU7 or the old funding stream end height of 4,476,000, Zebra now refuses to start while using public Testnet magic or seed peers. Remove those overrides to inherit the updated public defaults. (#11554)
Miners and Pools
Because the coinbase now depends on the fees of the selected transactions and on the parent block’s reserve, getblocktemplate lists only time as mutable. Request a new template instead of changing the transaction set or the previous block yourself. Coinbases claim only the miner’s 40% share of fees, and Testnet mining now requires the node to be synced. (#11529, #11530)
Wallet and Infrastructure Developers
Zebra’s state database moves to format v29 (see below). Anything that reads it 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. Library users should expect breaking API changes in zebra-chain, zebra-consensus, zebra-network, zebra-rpc, and zebra-state. (#11530)
Custom Testnet and Regtest Operators
Zebra now checks custom network configurations when it loads them, so mistakes surface at startup instead of hours into a test. Invalid subsidy schedules, overlapping funding stream ranges, too few funding addresses, and TEX funding recipients are all rejected. A custom network with different consensus rules must use its own network_magic and its own peers. Custom Testnets also store their state and peer caches under paths keyed by network name and magic, so they need to resync after upgrading. The full list of configuration changes is in the release notes. (#11527, #11529, #11554)
New Features
getblock Verbosity 3
Explorers and indexers can now get a complete picture of a block in one call. Verbosity 3 adds a prevout object to every transparent input, with the spent output’s value, script, height, and coinbase flag, plus a fee field on every non coinbase transaction. It matches Bitcoin Core, so existing tooling can use it directly, and it removes the need for extra getrawtransaction calls. (#11472)
Reserve Settings for Test Networks
Regtest and custom Testnets can set initial_nsm_value_balance and nsm_reissuance_height under [network.testnet_parameters] without special build flags. This makes it easy to watch reissuance happen on an accelerated schedule instead of waiting years of block height. (#11530)
Bug Fixes
No Bans for Honest Peers at Activation
Around any network upgrade, some peers briefly relay transactions built for the previous or next upgrade. Zebra no longer penalizes them for it during a 50 minute grace window, so honest peers are not banned at the exact moment the network needs them most. (#11563)
Mining and RPC Fixes
Block templates now respect time rules after a clock rollback and notify long polling miners only once when a template expires. getnetworksolps returns an error instead of crashing on very large estimates, getblocksubsidy rejects heights above the consensus limit, and z_listunifiedreceivers returns an error for malformed Orchard receivers. (#11529, #11530)
Other Changes
getstandardfee Schedule on Mainnet
On Mainnet, getstandardfee reports 5,000 zatoshis per logical action until height 3,590,000 and 1,000 after that, following zcash/zips#1352. This lets wallets move to the lower fee together. The mempool already accepts 1,000 zatoshis per logical action. (#11557)
State Database Format
Zebra 7.0.0-rc.0 uses state database format v29, which adds a field for the new reserve. The first time it starts, Zebra moves a compatible v28 database into state/v29 automatically, with no resync. Downgrading is not supported, and the move happens even if state.delete_old_database is disabled, so back up your v28 state first if you want a way back. Please use the built in upgrade rather than renaming directories or adding symlinks. (#11530)
Upgrading
You can find the release on GitHub, crates.io, and Docker Hub as zfnd/zebra:7.0.0-rc.0. The release notes list every change in full technical detail. Testnet operators should upgrade before height 4,465,026 to stay on the NU7 chain. If something looks wrong, please open an issue on GitHub: every report now makes the Mainnet release better.
Thank You to Our Contributors
This release was made possible by the work of @conradoplg, @judah-caruso, @oxarbitrage, @robustfengbin, @upbqdn, and @yagop. 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.