Zcash developers propose 20-second blocks without increasing daily coin issuance
Source report: 2026-11-08 · Editorial analysis published: 2026-11-09
The November 8 proposal follows NU7’s 25-second target. Faster confirmations would come with smaller per-block rewards and shielded-action limits; no activation date is set.
A further step after the 25-second upgrade
Zcash developers Dev Ojha and Evan Forbes proposed reducing the block target from 25 to 20 seconds in a November 8 community post. They want the proposal considered in the next poll and potentially included in NU7.1. The proposal and its draft specification are under discussion; neither the post nor an open code-review request is an activation announcement. The 25-second target introduced by NU7 remains the baseline of this proposal.
For people mining or receiving ZEC, the attraction is a shorter expected wait for a block to include a payment. For operators, the question is whether nodes and pools can deliver that improvement without discarding substantially more work. The authors frame this as a latency change: it is intended to shorten waiting time, rather than raise daily shielded transaction capacity or create more new coins per day.
More blocks, less new currency in each one
At the target intervals, a day contains an expected 3,456 blocks at 25 seconds or 4,320 at 20 seconds. That is 25% more blocks, not 25% more newly issued ZEC. The draft scales the per-block subsidy to four-fifths of its previous amount. Multiplying 1.25 times as many blocks by 0.8 times the subsidy preserves expected new issuance over the same time.
The halving interval would likewise rise from 5,040,000 to 6,300,000 blocks to preserve its expected duration. The proposed change retains the issuance schedule and 21-million-coin supply limit. A miner therefore cannot turn a higher block count into a proportional income forecast. Its share of network work, transaction fees, rejected work and pool accounting still matter; the subsidy arithmetic alone promises no extra daily reward for the same hashrate.
Smaller shielded limits preserve the daily workload
The proposal reduces the global shielded action budget and the Orchard and Ironwood per-block action limits from 330 to 264. Sapling's combined input-and-output limit would move from 300 to 240. These are limits on pieces of shielded transaction work, not a statement that every action is an entire customer payment. The two-megabyte block-size limit would remain.
The reason is wallet workload. If the old per-block action limits were kept while blocks became more frequent, the maximum amount of private transaction data a light wallet might need to process would rise. Scaling the limits by four-fifths keeps the expected daily action ceilings unchanged. There are still more block headers to follow, so “unchanged shielded capacity” should not be read as every byte and every networking operation remaining identical.
The cost of losing the block race
Two miners can find competing blocks before learning about each other's result. Eventually one branch wins; the competing block outside the accepted chain is often called an orphan. For its miner, electricity spent on that block does not generate the normal accepted-block reward. Shorter target intervals give messages less time to travel between discoveries, making this an important operating risk to examine.
The authors report stress tests with 80 miners spread over 12 regions, using full two-megabyte blocks at a 20-second target. The reported orphan rate was 1.9% with Zakura alone and 3.3% in a half-Zakura, half-Zebra-Andele network. They compare these with 4.68% in an earlier empirical investigation used for the 25-second case. These are attributed experiments under their conditions, not a guarantee of those percentages for a live pool or an independent ASIC.tools test.
Quicker confirmations do not choose an exchange's policy
Three target intervals would become 60 seconds instead of 75. That is an illustration of expected timing, not a countdown: proof-of-work block discovery is irregular. A service can also require a different number of confirmations or assess elapsed time and accumulated work. The proposal does not require exchanges to lower their confirmation counts, so the actual time before a deposit can be used still depends on the receiving service.
Difficulty averaging also changes from 102 blocks to 128, keeping the expected observation duration close: 2,550 seconds versus 2,560. The ten-second difference means it is approximately, not exactly, the same interval. Default transaction expiry would scale from 120 to 150 blocks. These details show why a shorter target involves more than replacing one time value in the node: related rules measured in block counts need coordinated treatment.
Read live data and upgrade status separately
The forum discussion refers to encouraging post-NU7 observations, but a block explorer's orphan rate is what its observers saw, not a census of every losing block. ZecBlock's methodology says that before November 5 it observed from one Helsinki node, then added other observers. More observation points can reveal competing blocks previously missed. A before-and-after percentage with changing coverage cannot by itself isolate the effect of the upgrade.
For now, there is no new ASIC setting to enable 20-second blocks and no scheduled activation in this proposal. Operators can follow the draft, the poll process and eventual node-release instructions, while keeping the current network rules in force. ASIC.tools checked the original post, pinned draft and observer methodology; it did not run the stress network. The useful change being debated is faster inclusion with preserved expected daily issuance, not a new guarantee of mining profitability or instant settlement.
Another explorer metric compares the block header time with the first observed receipt. ZecBlock explains that pools often set header time when issuing work, so this gap includes time spent finding a solution as well as delivery. It is not a direct network-propagation measurement; clocks can even make the gap negative. A pool operator investigating stale work should not substitute this convenient chart for its own submission, rejection and connection records.
Source: Zcash developers / community proposal ↗ · Draft specification and review status ↗ · Pinned draft examined for this report ↗ · Observer methodology, not a universal orphan census ↗
Mining calculator ↗
