Mentioned in This Article
1. Zcash developers propose 20-second blocks
Zcash developers Dev Ojha and Evan Forbes proposed on Sunday, November 9, cutting the network's target block time from 25 seconds to 20 seconds. The idea arrives three days after the NU7 upgrade, activated on Friday, shortened the interval from about 75 seconds to 25. The proposal is unapproved and has no activation date.
The move reflects early optimism among developers. Data collected since NU7 went live suggests the faster schedule has not caused the surge in wasted mining work that some had feared, and that has encouraged them to ask whether blocks can be made faster still.
Zcash (ZEC) is a privacy-focused cryptocurrency that lets users send transactions whose details are hidden from public view. Its supply is capped at 21 million coins, the same ceiling that applies to Bitcoin, and the proposal would leave that limit and the schedule for issuing new coins untouched.
The proposal is a small tweak compared with the upgrade it follows, but it shows how quickly the community is willing to iterate once real-world numbers look favorable.
Zcash's design makes transaction speed a relevant topic. Private payments are more computationally demanding than ordinary transparent transfers, and users of such systems often care about how quickly a payment can be treated as settled. Shortening the wait for a first confirmation addresses one of the most visible differences between privacy-focused networks and faster payment rails.
2. What is a block time, and why does it matter?
A block time is the average interval at which a blockchain adds a new batch of transactions to its ledger. Each batch is called a block, and a payment receives its first confirmation when it is included in one. A shorter interval between blocks therefore means that a payment is confirmed sooner.
The difference is easy to see in everyday use. A customer paying a shop in ZEC would wait about 20 seconds for the first confirmation under the new proposal, compared with about 25 seconds today. An exchange that requires three confirmations before crediting a deposit would cut its expected wait from 75 seconds to 60 seconds.
These figures are averages. Because miners find blocks at unpredictable intervals, any individual wait can be shorter or longer than the target. The target sets the long-run rhythm of the network and not a guarantee for each transaction.
Before Friday's NU7 upgrade, Zcash produced a block roughly every 75 seconds. For merchants and exchanges, that pace made the network feel slower than many payment systems, and speeding it up has been a stated goal of the upgrade.
Confirmations matter because they are the way a blockchain signals that a payment is unlikely to be reversed. Each additional block built on top of a transaction makes it harder to undo, so businesses that accept large payments usually wait for several confirmations. When the interval between blocks shrinks, the time needed to reach any given level of confidence shrinks with it.
3. Why do developers worry that faster blocks waste mining work?
The main worry is a phenomenon known as orphan blocks. When two miners find a valid block at nearly the same moment, the network can keep only one of them, and the other is discarded. The miner whose block was discarded has spent electricity and computing power for no reward.
Faster blocks increase the chance of this happening, because miners have less time to learn about each other's discoveries before another block appears. If the rate of discarded blocks climbs too high, miners lose income, and the network can become less secure because some of its computing power is spent on work that does not count.
That risk was a main concern in the debate over NU7. Developers had feared that blocks arriving three times as fast could push the orphan rate sharply higher, and the early evidence matters because it bears directly on whether the shorter interval is sustainable.
A lower target would amplify the same trade-off, since each reduction in block time leaves miners with a smaller window to hear about competing blocks. The question developers face is whether the added speed is worth even a modest rise in wasted work.
Proof-of-work networks such as Zcash rely on miners competing to solve a computational puzzle, and the first to solve it earns the right to add the next block. The network's security comes from the combined computing power devoted to that competition, which is why developers treat any change that might waste that power with caution.
4. What do the early orphan-block numbers show?
ZecBlock's mining tracker shows an observed orphan rate of 0.69% over the 24 hours ending early Monday. That compares with roughly 0.66% before NU7, a difference small enough to suggest that the faster schedule has not caused a major deterioration.
Ojha reacted positively to the figures. He wrote on Monday that "The orphan rate has gotten better than I anticipated!" The comment captures the mood among developers, who had been braced for a worse result.
The picture is not entirely settled. The rate measured since NU7 took effect is still higher at 1.29%, although readings fell after an early spike. That pattern is common after a network change, when nodes and miners are still adjusting to new conditions.
The comparison is also imperfect for a technical reason. ZecBlock raised its monitoring from one node to ten shortly before the upgrade, so it now detects some competing blocks that it previously missed. The before-and-after numbers therefore cannot be treated as an exact like-for-like measure of the change.
It is worth keeping the size of these numbers in perspective. A discard rate below one percent means that, on average, only a small fraction of blocks are lost to near-simultaneous discovery. Even the higher post-upgrade reading of 1.29% is modest next to the 4.68% rate seen in the earlier stress tests that were used to justify the 25-second target.
5. How did separate testing compare?
Separate testing offered a second data point. That experiment used 80 miners across 12 regions and found that between 1.9% and 3.3% of blocks were discarded, depending on the software used. Earlier stress tests, which helped establish that 25-second blocks were safe, had produced a discard rate of 4.68%.
Taken together, the live and simulated results suggest that confirmation times could be shortened again without a sharp rise in wasted work. They provide a reason for confidence and not proof, since a test environment is only a model of the real network.
Developers have been careful to note that simulations do not guarantee similar performance on the live network. Real-world conditions, such as uneven connectivity between mining operations and sudden changes in the amount of computing power, can behave differently from a controlled experiment.
Because of those uncertainties, the proposal's supporters are treating the data as encouraging evidence for further discussion and not as a final answer.
The proposal's authors are effectively arguing that the network has headroom. If the discard rate stays low at 25 seconds, they reason, a modest further reduction to 20 seconds is unlikely to push it into territory that would harm miners. The ongoing readings from the live network will test that reasoning in the coming days.
6. Would the change affect privacy transactions or supply?
The proposal is designed to leave key properties of the network unchanged. It would not increase the daily capacity for private transactions. To offset the extra blocks, developers would allow fewer transactions per block, so the total number of transactions the network can handle each day stays the same.
That design choice protects wallet users. If each block carried the same amount of data but blocks arrived more often, wallets would have to process more information, which could slow them down or raise the cost of running them. Keeping the daily total constant avoids that burden.
The issuance schedule, which determines how many new ZEC coins are created over time, would also be unchanged, as would the 21 million coin supply limit.
By holding these parameters steady, the proposal aims to deliver faster confirmations as a pure speed improvement, without altering the economic rules that investors and miners rely on.
The proposal also illustrates a design philosophy common to cautious blockchain development: make a change, measure it against live data, and only then consider the next step. Having moved from 75 seconds to 25 seconds in a single upgrade, the community is now weighing a far smaller adjustment, with a clearer view of how the network behaves under the new schedule.
7. What happens next for the proposal?
Ojha and Forbes want the proposal to be considered in the next community poll. They also suggest that it could be bundled into NU7.1, a future upgrade to the network. Neither step has been taken, and the idea has no activation date.
Network upgrades in Zcash typically move through discussion, community feedback and testing before activation, so any change to the block interval would require more evidence and broader agreement. The next poll is the first checkpoint, and the orphan-rate data gathered in the coming days will likely shape how the community responds.
For now, the debate shows that the faster-block approach introduced by NU7 has been received more smoothly than some developers expected. Whether that early result holds as more data arrives will decide if a 20-second target becomes a formal part of the network.
Because the proposal is unapproved, nothing changes for users, miners or exchanges at this point. Anyone relying on current confirmation times should continue to plan around the 25-second target that NU7 introduced.