Zcash Proposes 20-Second Blocks After Major Network Upgrade

I’ve been watching privacy-focused networks for years, and every so often something happens that makes me sit up a little straighter. This week it was Zcash. Only a few days after the network flipped the switch on a major upgrade that already cut block times dramatically, developers came forward with another idea: push the target even lower, down to twenty seconds. That kind of rapid iteration is rare, and it immediately raised questions about safety, user experience, and whether the chain can handle the extra pressure without creating new problems.

Why Faster Blocks Matter Right Now

Most people who send or receive cryptocurrency care about one simple thing: how long they have to wait before the money actually feels usable. For retail payments, exchange deposits, or cross-chain swaps, those extra seconds add up. The recent upgrade already moved the average first confirmation from roughly seventy-five seconds down to twenty-five. The new proposal would shave another five seconds off that wait. On paper it looks modest. In practice, for anyone who needs three confirmations before funds are released, the difference becomes fifteen seconds less staring at a loading screen.

I’ve found that small improvements in confirmation speed often matter more than flashy marketing claims. When a payment needs to clear before another service will act, every second counts. The developers behind the proposal highlighted exactly those use cases—everyday payments, deposit processing, and swaps that sit between different chains. They are not chasing theoretical throughput records. They are targeting the moments when people actually feel the delay.

What Changed With the Recent Network Upgrade

The upgrade that went live a few days ago, known internally as NU7, was already ambitious. It reduced the target block interval from seventy-five seconds to twenty-five seconds while leaving the total supply schedule untouched. At the same time it introduced tighter controls around shielded transactions and a new fee distribution model that reserves a portion of fees for future mining rewards. Miners still receive a direct share, but the network now sets aside sixty percent for longer-term incentives.

That combination—faster blocks plus a revised fee structure—was meant to improve usability without breaking the economic model that has kept Zcash aligned with a fixed maximum supply. Early on-chain numbers suggest the network absorbed the change better than some feared. Orphan rates, the percentage of blocks that get discarded because another miner found a competing block first, rose only modestly at first and then settled back near previous levels.

According to early mining trackers, the orphan rate over a recent twenty-four-hour window sat around zero point six nine percent. Before the upgrade it hovered near zero point six six percent. Across the entire period since activation the figure was higher, around one point two nine percent, largely because of the initial adjustment period. Once the network stabilized, the rate improved again. One of the lead developers publicly noted that the orphan rate performed better than anticipated. That kind of real-world feedback carries more weight than any simulation.

The New Proposal and Its Core Goals

Two developers, working from the community forum, put forward a formal suggestion to move the target from twenty-five seconds to twenty seconds and to consider the change for a follow-up upgrade. They are not asking for an immediate activation. They want the idea included in the next community poll so the broader group can weigh in. That measured approach feels sensible. Faster blocks sound attractive, yet every reduction in interval increases the chance that distant miners will produce conflicting blocks before the network can reconcile them.

The proposal keeps several important guardrails in place. The maximum number of shielded actions allowed in a single block would drop from three hundred thirty to two hundred sixty-four. That adjustment prevents the daily capacity for private transactions from rising simply because more blocks appear. The two-megabyte block size limit stays the same. Wallet software that must download and process data would therefore face roughly the same overall load it does today.

Issuance also remains carefully protected. The block subsidy and the length of each halving interval would be recalibrated so that the total number of coins released over time matches the existing schedule. The hard cap of twenty-one million stays intact. In other words, users and long-term holders would not see a change in scarcity simply because blocks arrive more often.

Testing the Twenty-Second Interval

Before submitting the proposal, the developers ran controlled tests with eighty miners spread across twelve different geographic regions. Those simulations produced orphan rates between one point nine percent and three point three percent, depending on the exact mining software configuration. Earlier tests that helped justify the move to twenty-five seconds had recorded an orphan rate of four point six eight percent under similar stress. The newer numbers look more comfortable.

Of course, laboratory conditions never match the full chaos of a live network. Latency varies, hash power distribution shifts, and software versions differ across operators. Still, the test results gave the team enough confidence to put the idea in front of the community. In my view that is the right sequence: gather data, share it openly, and then ask for broader agreement rather than pushing a change through quietly.

Difficulty Adjustment and Network Stability

One under-appreciated part of the recent upgrade was the expansion of the difficulty averaging window. It grew from seventeen blocks to one hundred two blocks. The new proposal would stretch that window further, to one hundred twenty-eight blocks, if the twenty-second target is adopted. A longer window tends to smooth out sudden swings in mining difficulty.

Previously, difficulty could swing roughly between minus forty percent and plus thirty percent in relatively short periods. With the longer averaging period the developers estimate the range might tighten to something closer to minus twenty percent and plus fifteen percent. Actual results will only appear after the change, if it is approved, but the direction of the adjustment is clear: more stability rather than more volatility.

Another community decision that already landed concerns the re-organization limit. The network raised the limit from one hundred blocks to one thousand blocks. That change reduces the chance that a sudden deep reorganization could rewrite recent history. Taken together, the longer difficulty window and the higher re-org limit show a consistent preference for robustness even while chasing lower latency.

What Users Would Actually Notice

For most holders the difference between twenty-five and twenty seconds will feel small on a single transaction. Where it becomes noticeable is in sequences. An exchange that waits for three confirmations would move from an expected seventy-five seconds to sixty seconds. A merchant waiting for a single confirmation would see the average drop by five seconds. Those numbers matter when a customer is standing at a point of sale or when an automated system is waiting to release goods or services.

The proposal also updates a couple of related parameters so that user experience stays consistent. The recommended confirmation depth of three blocks would keep the same expected waiting time after the interval change. Default transaction expiry would move from one hundred twenty blocks to one hundred fifty blocks, preserving the same real-world duration before a transaction is considered expired. These small calibrations show attention to detail. Changing one number without adjusting the surrounding rules often creates confusion; adjusting the whole set keeps the system coherent.

The orphan rate has gotten better than I anticipated.

That short comment from one of the developers captures the mood around the early data. Expectations were cautious; reality so far has been milder. Of course, a few days of observation do not equal a final verdict. Networks can behave differently under sustained high load or during periods of rapidly changing hash rate. Still, the initial signal is encouraging.

Balancing Speed and Privacy Capacity

Privacy remains the defining feature of the network. Any change that increases the number of blocks must carefully avoid inflating the total amount of shielded data that wallets need to process. By lowering the per-block limit on shielded actions in proportion to the increase in block frequency, the proposal keeps daily private capacity essentially flat. That decision prioritizes the experience of existing users who already rely on shielded transactions rather than chasing higher theoretical throughput at the cost of heavier client software.

I’ve always believed that privacy networks succeed or fail on the quality of the everyday experience. If wallets become sluggish because they must scan more data, adoption suffers even if the underlying cryptography is excellent. Keeping the data burden roughly constant while improving confirmation speed feels like the more mature path.

Community Process and Next Steps

Nothing is locked in. The developers explicitly want the idea to go through a community poll before any code is scheduled for a future upgrade. That process gives miners, wallet developers, exchanges, and ordinary users a chance to raise concerns or suggest refinements. Previous upgrades required node operators to update software in order to stay in consensus. The same would be true for any follow-up change that alters consensus rules.

There is no announced activation date. The team is treating the twenty-second interval as a candidate for a later upgrade rather than an urgent patch. That patience is welcome. Rushing a second interval reduction so soon after a major change would risk fatigue among operators and could introduce edge cases that only appear under prolonged stress.

In the meantime the network continues to run under the rules introduced a few days ago. Early mining data, improved orphan rates, and the expanded difficulty window all provide a live laboratory. Observers can watch how the chain behaves under real conditions while the community debates whether another five-second reduction is worth the marginal increase in coordination risk.

Broader Implications for Payment Experience

Cryptocurrency has long struggled with the gap between theoretical speed and practical usability. Many chains advertise sub-second finality, yet the services that people actually use—exchanges, payment processors, cross-chain bridges—still impose their own confirmation requirements. Reducing the underlying block interval does not force those services to lower their thresholds, but it does make a lower threshold safer. When the expected wait for three confirmations shrinks, more platforms may eventually decide that three is enough.

For privacy-focused users the stakes are higher. Shielded transactions already carry more computational cost than transparent ones. Making the confirmation experience smoother without increasing the data load on wallets is a non-trivial engineering win. If the proposal succeeds, it could quietly improve the competitiveness of private payments against faster transparent alternatives.

Perhaps the most interesting aspect is the timing. Networks often treat major upgrades as endpoints. Here the upgrade seems to have functioned as a starting point for further refinement. That iterative mindset—ship a significant improvement, measure the results, and immediately explore the next increment—is healthier than the all-or-nothing cycles that dominate some other projects.

Potential Risks That Still Deserve Attention

No change is free of trade-offs. Shorter block times increase the relative impact of network latency. Miners located far from the majority of hash power may find themselves orphaned more often. The geographic tests attempted to model that risk, yet real-world distribution of mining power can shift quickly. Continuous monitoring of orphan rates across different regions will remain essential if the proposal moves forward.

There is also the question of software readiness. Wallet providers, explorers, and exchange infrastructure all need to handle the higher block frequency without introducing new bottlenecks. Most of those systems already adapted to the jump from seventy-five to twenty-five seconds. Another twenty-percent reduction should be manageable, but it is not automatic. Clear communication and reasonable lead time will matter.

Finally, the community itself needs time to absorb the idea. Rapid successive changes can create a sense that the rules are always in flux. By routing the proposal through a formal poll and treating it as a candidate for a later upgrade rather than an emergency measure, the developers have tried to leave room for deliberation.

How the Numbers Stack Up

Putting the key figures side by side helps clarify the scale of the change. Before the recent upgrade the target was seventy-five seconds. After activation it became twenty-five seconds. The new target under discussion is twenty seconds. First confirmation expectations would move from seventy-five to twenty-five to twenty. Three-confirmation expectations would move from two hundred twenty-five to seventy-five to sixty. Those are the practical numbers that services and users will feel.

On the capacity side, the per-block shielded action limit would fall from three hundred thirty to two hundred sixty-four while the number of blocks per day would rise proportionally. The net effect is designed to keep daily private throughput roughly constant. The block size limit stays at two megabytes. Issuance math is adjusted so that the long-term supply curve does not change. Difficulty averaging lengthens from one hundred two to one hundred twenty-eight blocks. Transaction expiry and recommended confirmation depth are recalibrated to preserve real-world timing.

Taken together, the proposal is less a radical redesign and more a careful tightening of an already improved system. It accepts the success of the recent upgrade and asks whether one more modest step is justified by the data.

Looking Ahead

Whether the community ultimately approves the twenty-second target is still an open question. The early mining results have reduced one major source of anxiety—the fear that faster blocks would produce an unmanageable rise in orphans. The testing with distributed miners provided additional reassurance. The careful preservation of issuance and shielded capacity removes other common objections.

What remains is the collective judgment of the people who run nodes, mine, build wallets, and use the network every day. That process will take time, and that is appropriate. In the meantime the chain continues to operate under the rules that went live a few days ago, giving everyone more real-world data to examine.

I expect the discussion to focus less on ideology and more on measured trade-offs. How much additional confirmation speed is worth a modest rise in coordination risk? How confident are operators that their infrastructure can absorb another increase in block frequency? Those are practical questions, and the proposal has been framed in a way that invites practical answers.

For anyone who follows privacy technology, the episode is a reminder that progress often arrives in increments rather than revolutions. A major upgrade lands, early data looks solid, and the team immediately explores whether another small improvement is feasible. That rhythm—ship, measure, refine—tends to produce more reliable systems than occasional giant leaps followed by long periods of stagnation.

The coming weeks will show whether the community shares the developers’ sense that twenty seconds is a reasonable next target. Until then, the network’s recent performance offers a useful baseline. Confirmation times are already noticeably better than they were a week ago. Orphan rates have settled into a comfortable range. Difficulty adjustments are smoother. Those are tangible gains. The proposal simply asks whether the network can capture a little more of the same benefit without undoing the stability it has just achieved.

In the end, the decision will rest on evidence rather than enthusiasm. That is how durable improvements are made. And for a network whose value proposition rests on both privacy and practical usability, careful iteration may be the most valuable upgrade of all.