Zcash NU7 targets one block every 25 seconds, but the first 250 intervals averaged 38.21 seconds. Miners now keep roughly 40% of transaction fees. Holders can no longer spend ZEC left in the old Sprout pool.
Zcash activated NU7 on its main network on November 6 at block 3,543,405. The deployment specification cuts the target interval between blocks from 75 seconds to 25. Recipients can expect a shorter wait for a first confirmation, though each payment still has to make it into a miner’s block.
Developers had already tested the rules at height 4,465,026 on the public test network. At the time, they expected the mainnet upgrade around November 5. The switch took place when miners reached the designated height.
What the first 250 block intervals showed
PulseHawk, which monitors the network, read the activation block header on its own client and reported a timestamp of 02:34:02 UTC. Its sample covers blocks 3,543,406 through 3,543,655. The longest wait, just before block 3,543,445, exceeded four minutes.
| Measure | Time |
|---|---|
| Protocol target | 25 seconds |
| Observed mean | 38.21 seconds |
| Median | 25 seconds |
| Longest interval | 249 seconds |
A transfer earns its first block confirmation when a miner includes it in a valid block. For three confirmations, two more blocks must follow. At the target pace, three block intervals now add up to one minute and 15 seconds, down from three minutes and 45 seconds. Each crypto exchange sets its own confirmation threshold before crediting a ZEC deposit.
Light wallets have more blocks to scan for shielded payments. ZIP 218 limits how many shielded actions a block can contain. Sapling, Orchard and Ironwood each have a cap, and a separate limit covers all three combined. The developers modeled an attacker filling blocks to create the heaviest possible workload for wallets. In that scenario, the maximum daily download falls from 271 MB to 169 MB and the maximum number of trial decryptions falls from 4.8 million to 2.3 million.
The reserve receives 60% of transaction fees
Under the new fee rule, the calculation starts with the total fees in a block. Miners keep roughly 40%, and nodes record the other 60% as out of circulation. The protocol rounds the reserve’s share down to a whole zatoshi, ZEC’s smallest unit. If a block contained 11 zatoshis in fees, six would go to the reserve and five to the miner.
Nodes track the reserve as a public balance. Nobody can spend it from a wallet. Starting at mainnet block 8,939,664, the protocol will add a small portion of the reserve to the ordinary block reward. Developers expect the network to reach that height around February 2031.
Each block now creates a third as much new ZEC as before, and it takes more blocks to reach the next halving. That adjustment keeps scheduled daily issuance and the four-year halving cycle intact. Supply remains capped at 21 million ZEC. The 98,000 ZEC plan the grants committee withdrew on November 3 concerned its own treasury and future grant income.
The fee discussion at 1:52 in BSCN’s November 6 bulletin covers the miner’s share and how the protocol will eventually reissue the remainder.
Why holders can no longer spend Sprout funds
Nodes now reject every transaction in the version 4 format. Sprout, the original shielded pool, could only pay out using that format. Coin Mühendisi reported that the pool still held about 12,224 ZEC when NU7 went live. The deployment specification provides no replacement format for transferring those funds.
The version 4 ban also applies to older transparent and Sapling transactions. Where possible, users can rebuild non-Sprout payments in version 5 or 6. Signing a version 4 transaction again will not make it valid. A digital signature authorizes a transaction under a specific set of network rules. Wallet software must check which rules the sender signed for, even on version 5 or 6 transactions prepared offline before the upgrade.
Zebra 7.0.0 was the first stable release to support NU7 on mainnet. Upgraded nodes disconnect peers that advertise the old protocol. On its first start, Zebra automatically migrates the existing v28 database to v29. Operators who switch back to Zebra 6 need to resync or restore a pre-upgrade v28 backup because the older software cannot read the new format.
