Loading...
In the NU7 coinholder poll that closed on 14 September 2026, about 2,397,669 ZEC voted for ZIP 218 and 141.6 ZEC voted against it, a 99.9% result. Most coverage summed it up as "Zcash blocks get faster." That is true, but it leaves out most of what the proposal does and most of what it deliberately keeps the same.
This page explains ZIP 218 from its own text: what changes, what does not, and what it costs.
| Today | After ZIP 218 | |
|---|---|---|
| Block target spacing | 75 seconds | 25 seconds |
| Blocks per day | 1,152 | 3,456 |
| Block subsidy (current halving era) | 1.5625 ZEC | 0.52083333 ZEC |
| New ZEC per day | unchanged | unchanged |
| Halving interval | 1,680,000 blocks | 5,040,000 blocks |
| Limits on shielded actions per block | none (only the 2 MB size limit) | 330 total, with per-pool caps |
| Orchard throughput (2-action transactions) | about 2.9 per second | about 6.6 per second |
Three times as many blocks, each paying a third as much. The supply schedule stays where it was.
The main goal is lower waiting time. Today a payment waits 75 seconds on average for its first confirmation, whatever the network load. At 25 seconds that falls to 25 seconds on average. The ZIP names point-of-sale payments, exchange deposits and cross-chain bridges as the uses that feel this most.
Two points from the ZIP are worth keeping in mind:
The ZIP also notes that higher throughput alone could have been achieved with a larger block size. Latency is the reason for choosing shorter blocks instead.
Tripling the number of blocks would triple daily issuance if nothing else changed. ZIP 218 prevents that by dividing the per-block subsidy by a further factor of three once NU7 is active.
In the current halving era, that takes the block subsidy from 1.5625 ZEC to 0.52083333 ZEC (52,083,333 zatoshi). Because 156,250,000 zatoshi does not divide evenly by three, each block rounds down by a third of a zatoshi. Across a full 5,040,000-block halving interval that is about 0.0168 ZEC in total.
The subsidy is the total new ZEC created per block. The existing development-funding share is still taken from it, so miners receive less than the full figure, exactly as today.
A note on the 0.26041666 ZEC figure. The draft ZIP's explanatory note prints the post-NU7 subsidy as floor(156250000 / 6) = 0.26041666 ZEC, and some news coverage has repeated it. That note is wrong by a factor of two: 156,250,000 zatoshi is already the post-Blossom subsidy, so dividing it by six applies the Blossom factor of two a second time on top of the NU7 factor of three. The normative formula gives floor(1,250,000,000 / (2 · 3 · 4)) = 52,083,333 zatoshi at the current halving index. Zebra's implementation issue for this change (#11463) records the note as double-counting the Blossom factor, tells implementers to "implement the formula, not the note," and says a correction has been filed against the ZIP. The correct figure at activation is 0.52083333 ZEC.
The halving interval triples from 1,680,000 blocks to 5,040,000 blocks. Since blocks arrive three times as often, halvings still land at roughly the same point in time as they would have without the change. The total supply cap is unaffected.
This is separate from the other issuance question in the NU7 poll, where coinholders voted to keep halvings rather than replace them with a smoothed curve. ZIP 218 works with the existing halving model and does not change it.
ZIP 218 adds caps on how much shielded activity a single block can hold:
| Limit | Maximum per block |
|---|---|
| All shielded pools combined | 330 (each Sprout JoinSplit counts as 2) |
| Orchard actions | 330 |
| Sapling inputs plus outputs | 300 |
| Sprout JoinSplits | 25 |
Transparent parts of transactions are not affected, and the 2 MB block size limit still applies.
The limits exist because more blocks would otherwise mean more work for wallets and nodes. With the caps in place the worst case actually gets better than today, even with three times as many blocks:
The Sapling and Sprout caps are tight on purpose. As of May 2026, Orchard held 87.9% of shielded ZEC, Sapling 11.6% and Sprout 0.5%, so the smaller pools get enough room for their real usage while giving an attacker less to abuse. Because ZIP 317 fees charge the same per logical action in every pool, an attacker gains nothing by spamming one pool instead of another.
With 330 Orchard actions per block, a standard 2-action Orchard transaction fits ⌊330 / 2⌋ = 165 times per block. At one block every 25 seconds that is about 6.6 transactions per second, up from about 2.9 today — the ZIP calls it a 2.3× increase in normal Orchard throughput. Sapling comes out at about 3.0 per second, still above what Orchard manages today.
The difficulty algorithm averages over a window of recent blocks. ZIP 218 raises that window from 17 blocks to 102, so it still covers about 2,550 seconds of real time, the same span it covered when Zcash launched with 150-second blocks. The ZIP gives two reasons: to avoid making difficulty-manipulation attacks easier (it cites Litecoin's April 2026 MWEB incident), and to smooth out short-term variation in block times.
Right after activation, block times will take a while to settle at the new target. That is expected and mirrors what happened at Blossom, when Zcash went from 150 to 75 seconds.
These are recommendations for implementations rather than consensus rules:
Faster blocks are not free. A stale block is a valid block that loses the race to be included in the chain because another block reached the network first. The shorter the gap between blocks, the more often this happens, and the ZIP ties the stale rate to block propagation, verification time and mining centralisation risk.
There are two smaller costs as well. Light wallets download about 200 KB more per day of compact block headers. And because there are three times as many blocks, a full node that has been offline has more blocks to process when it catches up, even though each block is cheaper to verify. The ZIP accepts both.