TL;DR
Zcash developers proposed cutting target block spacing from 25 seconds to 20 seconds, seeking faster first confirmations and inclusion in the NU7.1 upgrade.
Stress tests showed orphan rates of 1.9% on Zakura-only networks and 3.3% on mixed Zakura/Zebra-Andele setups, below earlier readiness thresholds used for 25-second blocks.
The proposal keeps daily issuance and shielded throughput unchanged by proportionally scaling block rewards, action limits and time-based parameters.
Zcash developers have proposed lowering target block spacing from 25 seconds to 20 seconds, extending the latency reductions introduced with NU7. In a community forum proposal , developers ValarDragon and Evan Forbes said they want the change included in the next poll and slated for NU7.1. The proposal targets faster confirmations without increasing Zcash’s shielded transaction capacity. The change would continue the performance push around Zcash , following the move from 75-second to 25-second blocks.
Developers Target Lower Latency Without Raising Daily Throughput
The proposal describes the 20-second target as a follow-on to ZIP 218, which powered NU7’s block-time reduction. Developers argue that transactions still wait for block inclusion when blocks have spare capacity, creating friction for point-of-sale payments, exchange deposits and cross-chain swaps. Cutting another five seconds would shorten time to first confirmation and improve back-to-back payment latency. The plan follows the NU7 mainnet activation , which reduced target spacing from 75 seconds to 25 seconds.
Stress tests used an 80-miner network across 12 regions with full 2 MB blocks. A Zakura-only network produced a 1.9% orphan rate, while a 50-50 Zakura/Zebra-Andele setup reached 3.3%. Both results meet or improve upon the readiness bar previously used for 25-second blocks , where testing showed a 4.68% empirical orphan rate and a 3.26% theoretical estimate. Developers attribute the improvement to work in Zakura and Zebra-Andele, building on Zebra performance and security upgrades .
The proposal would scale shielded action limits by four-fifths rather than allowing faster blocks to increase daily private-transaction capacity. Orchard and Ironwood actions per block would fall from 330 to 264, while Sapling inputs plus outputs would drop from 300 to 240. Keeping daily shielded maxima unchanged is intended to prevent a 25% increase in worst-case light-wallet synchronization load. The 2 MB block-size limit would remain unchanged, separating latency improvements from future throughput expansion.
Monetary and timing parameters would also be adjusted to preserve wall-clock behavior. Per-block issuance would fall proportionally, while the halving interval would expand from 5.04 million to 6.3 million blocks. Default transaction expiry, difficulty averaging and reorganization-related settings would scale. The proposal changes block frequency without altering expected daily issuance or asking services to reduce confirmation counts. Its next step is governance consideration, continuing the network’s community-backed push for faster transactions .
