Zcash Devs Eye 20-Second Blocks Days After Major Network Overhaul

Key Takeaways

Zcash Developers Propose 20-Second Block Times

Zcash developers have proposed reducing the network’s target block interval to 20 seconds, just days after a major upgrade cut block times to 25 seconds. The latest proposal aims to accelerate transaction confirmations while preserving Zcash (ZEC)’s existing issuance schedule and supply cap.

The proposal, published for community discussion on the Zcash forums, targets inclusion in the upcoming Network Upgrade 7.1 (NU7.1). The proposal follows the successful activation of Network Upgrade 7 (NU7), which introduced several structural changes to Zcash, including faster block production, a long-term network security reserve and the retirement of its original Sprout shielded pool.

The upgrade reduced Zcash’s target block interval from 75 seconds to 25 seconds and introduced the Network Sustainability Mechanism (NSM), developed by Shielded Labs. The mechanism redirects 60% of transaction fees to a long-term reserve designed to bolster network security as mining subsidies decline, beginning around 2031.

The upgrade also retired the legacy Sprout pool by discontinuing version 4 transactions, permanently freezing approximately 12,226 ZEC, valued at roughly $16 million, associated with lost or abandoned keys.

Following activation, ZEC experienced significant price volatility, initially rallying from $1,120 to more than $1,380 before retreating 7% to 9% to a range of $1,260 to $1,315 amid profit-taking and the unwinding of leveraged positions.

Latency and Action Limit Adjustments

Despite the recent overhaul, Zcash developers are already pursuing further improvements to transaction confirmation speeds. The latest draft proposes an additional 20% reduction in the target block interval, which would increase expected block production by 25%.

According to the proposal, the primary objective is to reduce transaction latency, particularly for applications requiring rapid confirmations. These include point-of-sale payments, cryptocurrency exchange deposits and cross-chain swaps, where shorter confirmation times could improve the user experience.

The proposed changes would not affect Zcash’s daily issuance schedule or its 21 million ZEC supply cap. Instead, block subsidies and time-dependent parameters, including difficulty adjustment windows, would be scaled proportionally to accommodate the faster block schedule.

Developers have also proposed reducing shielded action limits to prevent the increased block frequency from placing excessive synchronization demands on light wallets and network nodes.

Specifically, the draft calls for scaling certain limits established under ZIP 218 to four-fifths of their current levels, reducing the global shielded action budget and relevant Orchard and Ironwood action limits from 330 to 264 per block.

Meanwhile, the existing 2 MB block size limit would remain unchanged. At maximum block utilization, the proposed interval would imply a theoretical peak data-processing rate of approximately 100 KB per second.

Rapid Upgrade Schedule Raises Network Stability Concerns

Although reducing Zcash’s target block interval to 20 seconds could accelerate transaction confirmations, it also raises concerns about higher orphan block rates resulting from tighter block propagation windows. The rapid succession of upgrades could also place additional operational demands on miners, exchanges and node operators.

Albert Dadon AM, CEO and founder of AEREDIUM, warned that introducing another upgrade so soon after NU7 could expose the network to stability risks that have yet to emerge under real-world conditions.

Dadon argued that a few days of live operation provide insufficient evidence of network resilience, particularly for a proof-of-work blockchain where problems such as stale blocks, short reorganizations and connectivity advantages among miners may only become apparent during periods of sustained activity.

“The problems that matter in a proof of work network, such as stale blocks, short reorganisations and miners with better connections gaining an edge over the others, show themselves under stress and over weeks, not in the first quiet days after an upgrade,” Dadon said.

He also highlighted the operational challenges associated with successive changes to block intervals, noting that wallets, exchanges, mining pools and other services that rely on transaction confirmations must adapt to each adjustment.

Dadon suggested that developers should allow NU7 to operate through at least one period of heavy network activity before introducing further changes.

“Speed gained in a hurry is the most expensive kind,” he cautioned.

However, stress tests and post-NU7 data reportedly indicate lower orphan block rates than before the upgrade, partly due to optimizations in node implementations such as Zebra and Zakura. Nevertheless, risks associated with heavy mainnet traffic remain.

Unlike NU7, which introduced major structural changes, NU7.1 focuses primarily on reducing transaction latency without altering Zcash’s monetary policy. Its implementation nevertheless remains subject to community review and governance polls.