Zcash prepares for 25-second blocks: Zebra 7.0.0 gives miners an upgrade deadline
Source report: 2026-10-22 · Editorial analysis published: 2026-10-26
Zebra 7.0.0 supports the planned NU7 activation at block 3,543,405. Faster blocks do not triple daily ZEC issuance, and pools must update how they build their block rewards.
The deadline is a block height
Zcash Foundation released Zebra 7.0.0 on October 22 with support for NU7, the next main-network upgrade. Operators of Zebra nodes must upgrade before block 3,543,405 to remain on the network’s consensus chain. The Foundation places that height around November 5, but the height decides activation: a calendar estimate cannot replace it.
For someone mining ZEC, the immediate question is who runs the node that supplies work. A node checks blocks and helps a pool construct a candidate block. If a pool runs that infrastructure, its operator handles the node upgrade. A miner running a personal node or solo setup has that responsibility directly.
This is a node-software release, not new firmware for every Zcash ASIC. There is no reason to upload a Zebra binary to a mining machine. First identify the actual software chain connecting the machine, pool and node, then check the operator’s NU7 preparation. Updating one component does not establish that the whole setup has been tested.
Three times as many blocks, a smaller reward in each
NU7 changes the target interval from 75 seconds to 25 seconds. A target is an average the protocol aims for, not a stopwatch guarantee for each payment. Blocks will still arrive irregularly, and a receiving service can require several confirmations before crediting a deposit.
The accompanying issuance changes divide the scheduled block subsidy by three and adjust the remaining halving intervals to preserve the four-year schedule. With other conditions held equal, three times as many opportunities carry a third of the subsidy each. The scheduled daily issuance does not triple, and the 21 million ZEC supply cap remains.
Think of a daily loaf cut into more slices: smaller pieces do not create more bread. That comparison concerns scheduled issuance, not a promise that one miner’s daily income stays fixed. Their share of the network, rejected work, downtime, fees and the market value of ZEC still affect the result.
Transaction fees get a separate rule
Under the NU7 mechanism described by the Foundation and ZIP 235, 60% of transaction fees are removed from circulation into a reserve mechanism, while miners can claim the remaining 40%. This applies to transaction fees, not to 60% of the ordinary block subsidy or to 60% of a miner’s whole balance.
The plan later reissues a prescribed part of the reserve through block rewards. Mainnet reissuance begins at a different height, 8,939,664, under ZIP 259. Removing fees and later reissuing part of the reserve are separate stages; a pool cannot treat all reserved fees as immediately available mining revenue.
An earnings comparison should therefore keep the subsidy and transaction-fee components apart. A change to one component cannot be applied as the same percentage change to the total. The actual effect on an individual payout also depends on the pool’s settlement rules and the transactions included in its blocks.
Pools need fresh block templates
A block template is the candidate block a node gives mining software to work on. In Zebra 7.0.0, only time is listed as mutable in getblocktemplate. The required coinbase transaction—the special transaction that creates and allocates a block reward—commits to the selected transactions’ fees and the subsidy.
The Foundation’s practical instruction is to request a fresh template instead of independently changing its transaction set or previous block. From NU7, the coinbase must also respect the miner’s 40% fee share. A pool adapting old software needs to check these construction rules, not merely whether its node reports a new version.
Home miners using a pool can look for a clear readiness notice and check that their workers keep submitting accepted work. A quiet dashboard is not proof that a node upgrade succeeded. Compare device status with pool-side accepted shares, and preserve a working configuration before changing connections.
Back up before the database moves
On first start, Zebra 7 migrates its state database from format v28 to v29 without requiring an initial resync. The release advises operators coming from Zebra 6.x to back up the state/v28 directory within their configured state cache first. Anyone already on the 7.0.0 release candidate has already crossed that database boundary.
Zebra 6.x cannot use the migrated v29 database. A downgrade after migration requires a full resync unless the operator has an appropriate preserved state. That makes a tested backup and a maintenance window more useful than simply keeping the old executable. Avoid treating a major-version rollback as a quick toggle.
The release also changes monitoring labels and log output. An alert that relies on a removed label can stop working even while the node runs. Operators should check their dashboards after the upgrade and read the release-candidate notes for the additional configuration and remote-call changes inherited by version 7.
What to check next
Zebra 7.0.0 also repairs sync stalls, mined-block broadcasting and several security problems. These changes matter to a pool that must receive current work and relay a found block promptly. They do not establish a guaranteed reduction in rejected blocks or a measured hashrate increase for every installation.
The supported lifetime for this release is eight weeks rather than the usual twelve; the notes describe a halt about 56 days after its estimated release height. Installing 7.0.0 is therefore part of ongoing maintenance, not a reason to ignore subsequent releases. Obtain downloads and instructions from the project’s official channels.
For a reader with a single ZEC miner, the useful checklist is short: identify the pool or node responsible for templates, verify its NU7 upgrade plan, and understand the new reward accounting before comparing earnings. At our October 26 check, this remains preparation for a future mainnet activation, not a report that 25-second mainnet blocks have already begun.
Source: Zcash Foundation ↗ · Zebra 7.0.0 release and security fixes ↗ · NU7 activation specification ZIP 259 ↗ · ZIP 218 block interval changes ↗ · ZIP 235 fee mechanism ↗
Mining calculator ↗
