Two Zcash developers want to cut the network’s target block time again, from 25 seconds to 20, two days after the NU7 upgrade brought it down from 75. Dev Ojha and Evan Forbes posted a draft Zcash Improvement Proposal on the community forum on Sunday and asked for it to go into the next community poll and the planned NU7.1 upgrade. The change would mean 20-second blocks without adding to daily private transaction capacity or changing ZEC’s issuance schedule. It has not been approved and has no activation date.
What the draft would change
The ZIP text itself was opened on GitHub on Nov. 5, the day before NU7 activated. The authors describe it as “a latency-only change.” Their reasoning is the same as for NU7: “every transaction waits for block inclusion, even when blocks are nearly empty,” which slows point-of-sale payments, exchange deposits and cross-chain swaps through NEAR Intents, where market makers need at least one confirmation before acting.
To stop the extra blocks from adding load, the draft scales the shielded limits that NU7 introduced by four-fifths. The global shielded budget and the per-block caps for Orchard and Ironwood actions would drop from 330 to 264, and Sapling inputs plus outputs from 300 to 240. The 2 MB block size limit stays.
Everything measured in wall-clock time is meant to stay put. The per-block subsidy would shrink by the same four-fifths, and the halving interval would rise from 5,040,000 to 6,300,000 blocks, so daily issuance is unchanged. The difficulty averaging window would grow from 102 to 128 blocks and default transaction expiry from 120 to 150 blocks. The recommended anchor depth stays at three blocks, which works out to 60 seconds instead of 75.
The case on orphan rates
Faster blocks raise the risk of orphans, valid blocks the network discards because a rival block spread first. The authors tested 20-second blocks on an 80-miner network spread across 12 regions, with full 2 MB blocks under worst-case load. They measured a 1.9% orphan rate with only Zakura nodes and 3.3% on a network split evenly between Zakura and Zebra Ándale. The data used to clear 25-second blocks showed 4.68% in testing and 3.26% in a theoretical model, so the draft argues 20 seconds already meets the earlier safety bar.
The draft also takes on the worry that shorter blocks weaken each confirmation. Against a minority attacker, it says, security grows exponentially with the number of confirmations, and against an economic or majority attacker what matters is the block reward per unit of time, which does not change. “The ZIP doesn’t ask anyone to reduce their confirmation count,” it says.
In a forum reply, Ojha said the chain peaks at about 80KB/s today and “this change would make it 100KB/s, which is still tiny quantities that dialups could still handle.” He added that the live orphan rate is now lower than it was before the upgrade.
Will it fit into NU7.1?
That is the harder question. NU7.1 was proposed for a different job. In a Nov. 5 timeline, the five groups that coordinate coinholder voting, including Ojha’s Valar Group, said that if this month’s vote on Zcash Community Grants’ share of the Dev Fund produces rough consensus, the main purpose of NU7.1 will be to implement the winning proposal. Proposals were due by the end of Sunday, and polls run from Nov. 16 to Nov. 30. The groups wrote that “major features and transaction format changes are outside the scope of this upgrade,” though smaller improvements could be added if engineers think they can ship safely by the target date. The block-time draft was posted a few hours before that deadline and describes NU7.1 as “a very small, low risk upgrade.” Ojha also asked in the timeline thread for it to be included in the poll.
On Monday the coordinators said they would exclude proposals that came in after the deadline, and repeated that the main focus is ZCG’s share of the Dev Fund, “with room for smaller improvements that the engineering teams determine can safely ship within the upgrade timeline.” They have not said whether the block-time change will be on the ballot, and the draft poll questions had not been posted in the thread at the time of writing.
Not everyone on the forum is sold on the number itself. “Is the optimum under current circumstances really 20 seconds?” one commenter asked. Ojha replied that block times could likely go lower, but that 20 seconds is what the available analysis supports for now.
The same authors have a second scaling draft open. A ZIP submitted on GitHub on Nov. 6 would raise the block size limit from 2,000,000 to 3,000,000 bytes while keeping the shielded action limits, so the extra room would mostly go to transparent transactions. Ojha wrote that after 20-second blocks, “the next big win should come from doubling maximum block size.” The 3 MB draft is a smaller step than that.
Where Zcash stands after NU7
NU7 activated at block 3,543,405 on Friday, the Zcash Foundation said, with blocks every 25 seconds. The upgrade also switched on the Network Sustainability Mechanism, which removes 60% of transaction fees from circulation to be reissued as future block rewards from 2031. ZEC topped $1,000 for the first time in September.
FAQ
Has Zcash approved 20-second blocks?
No. It is a draft proposal on the community forum with no activation date, and its authors want it considered in the next community poll.
Would faster blocks create more ZEC?
No. The draft cuts the per-block subsidy by four-fifths and lengthens the halving interval in blocks, so issuance per day and the 21 million cap stay the same.
Do exchanges need to change confirmation rules?
Not under the draft. It does not ask services to cut their confirmation counts, and services that set deposit rules by elapsed time need no change.
Disclaimer: This article is for informational purposes only and does not constitute financial advice.
