Direct Answer
If Zcash's proposed NU7 network upgrade activates with ZIP 218 as currently drafted, the natural stale-block rate should increase relative to today's network. The mechanism is straightforward: ZIP 218 proposes cutting Zcash's block target spacing from 75 seconds to 25 seconds, a threefold increase in target block frequency. A shorter interval leaves less time for a newly found block to reach the rest of the network before a competing miner finds an alternative block on the same parent. That dynamic is a feature of proof-of-work systems generally, not a Zcash-specific defect, and NU7's design includes measures intended to limit how much the stale-block rate rises. As of this writing, NU7 has not activated on Mainnet, and its activation height remains unassigned, so every statement in this article about its effects should be read as a description of a proposed, not yet deployed, upgrade.
Why a Shorter Block Interval Raises Stale-Block Risk
A stale block is a valid, fully mined block that does not end up part of the chain that nodes ultimately treat as canonical, typically because a competing block reached more of the network first and accumulated more proof-of-work on top of it. The probability of this outcome rises when the time needed to propagate a block across the network represents a larger share of the average time between blocks.
ZIP 218 proposes reducing Zcash's block target spacing from 75 seconds to 25 seconds (ZIP 218). Holding propagation time and validation time constant, a block that takes, for example, two seconds to reach most of the network consumes roughly 2.7% of the current 75-second interval but roughly 8% of a 25-second interval. The ratio of propagation time to block interval is the central variable that determines how often two miners end up racing to extend the same parent block — a dynamic also described in the academic literature on block-propagation delay and natural forking.
At the proposed 25-second target, the network would also produce roughly 3,456 blocks per day, compared with roughly 1,152 blocks per day at the current 75-second target. Faster block production means more opportunities for competing blocks to be found close together in time, which is the structural reason stale-block risk is expected to rise if the target spacing is shortened without other changes.
Evidence from the NU7 Devnet Test
The most concrete evidence available comes from a geographically distributed Zebra-only devnet test described in a Zcash Community Forum report. The test used 100 Zebra nodes spread across 19 regions in the United States, Europe, India, Australia, and Singapore, each running a single CPU miner with eight vCPUs, 16 GB of RAM, and 1–3 Gbps connectivity (Zcash Community Forum).
Across 1,069 canonical heights, the report counted 52 heights with competing non-canonical blocks and 52 stale blocks. Thus, both the stale-height rate and stale blocks per accepted block were 52 / 1,069 = 4.86% in this sample. This is not the percentage of all discovered blocks that were stale. Four higher-cumulative-work branch switches gave a separate rate of 4 / 1,069 = 0.37%.
The report also estimated 3.26% expected stale blocks per accepted block using a simplified propagation model. Its assumptions included treating node reach as a proxy for mining work and assuming no material propagation tail beyond 90% reach. The authors considered the results supportive of a 25-second target with appropriate TCP configuration; they do not establish a universal safety threshold.
These figures should not be read as a Mainnet forecast. They describe a controlled devnet with deliberately wide geographic distribution and complete observability of every participating node — conditions that do not necessarily match the eventual Mainnet topology of pools, solo miners, and relay infrastructure. They are best understood as stress-test results that the proposal's authors used to argue the 25-second target is workable, not as a guarantee of the rate Mainnet will eventually show.
Built-in Mitigations: Shielded-Action Limits and Validation Benchmarks
ZIP 218 does not propose shortening the block interval in isolation. It also proposes a global limit of 330 shielded actions per block, with separate sub-limits for Orchard, Ironwood, and Sapling activity. The stated purpose is to bound the worst-case time needed to validate a block and to keep wallet shielded-sync costs manageable as blocks arrive roughly three times as often.
The ZIP's own benchmarking reports that a worst-case block containing the full proposed 330 Orchard actions took 432.11 ± 11.03 milliseconds to verify on a modern AMD laptop using four pinned threads. That figure is below the ZIP's benchmark for a current worst-case Orchard block under today's higher limits, reported at 769.85 ± 16.18 milliseconds, and well below the benchmark for a current worst-case Sapling-spend block, reported at 3,174.90 ± 144.04 milliseconds. These are implementation-specific measurements on a single reference machine, not universal guarantees for every node operator's hardware, but they support the proposal's underlying argument: if the shielded-action limits hold, block validation itself should not become the dominant source of propagation delay under the new 25-second target.
NU7 also proposes lengthening the difficulty-adjustment averaging window from 17 blocks to 102 blocks after activation. At a 25-second target, 102 blocks span 2,550 seconds, or 42.5 minutes — intended to keep difficulty responsive without overreacting to short-term variance in a much faster block cadence.
What Changes for Miners vs. Pools
A practical question for operators is whether NU7 requires action at the device level. According to the official Zcash NU7 overview, ASIC miners do not verify Zcash's consensus rules directly, and NU7 is not expected to alter the block header format. The page indicates that no NU7-specific firmware action is expected on ASIC hardware; miners instead depend on the node and pool infrastructure they connect to for consensus-rule compliance (Zcash NU7 overview). This should be read as the current expectation based on the proposal's present form, not as an absolute guarantee, since the upgrade's final specification could still change before Mainnet activation.
What does carry material weight is node and pool-side readiness. Zcash's NU7 materials indicate that zcashd is being deprecated in favor of the Zebra full node, and ZIP 259 specifies that NU7-compatible nodes will disconnect peers still advertising an older network protocol version after activation (ZIP 259). For a mining pool, this makes block-template distribution speed, peer connectivity, and the pace at which the pool's nodes stop issuing work on a stale parent block more consequential to stale-block exposure than any change at the ASIC level. Pools that upgrade their node infrastructure ahead of activation and maintain well-connected peer sets are better positioned to minimize the time spent building on an outdated chain tip once a shorter block interval is in effect.
Stale Blocks, Stale Shares, and Rejected Shares Are Distinct Measurements
Discussions of mining risk sometimes conflate chain-level outcomes with pool-accounting outcomes. These are related but measured at different layers, and an increase in one does not automatically imply a matching increase in the other:
- A stale block is a valid, fully mined block that does not remain part of the chain nodes treat as canonical, because a competing block accumulated more proof-of-work.
- A stale share is work that was valid for an earlier mining job but reaches the pool after that job is no longer accepted, commonly following a new block. Merely issuing newer work does not necessarily invalidate every earlier job. Delays in receiving new work or returning a completed share can contribute to stale submissions.
- Rejected shares are submissions the pool does not accept. Stale work can be a rejection reason, alongside invalid or duplicate submissions. Reporting categories and crediting policies depend on the pool and mining software.
A rise in the chain-level stale-block rate reflects network-wide propagation dynamics. A pool's stale-share rate reflects job-update and share-submission delays across the pool, network connection, and miner, as well as the pool's acceptance rules. The two can move together, but neither one can be inferred precisely from the other. The distinction between new work and invalidated work is also described in the Stratum job-assignment mechanism (Hardening Stratum, Section 2.4).
Payout and Revenue Considerations
Three times as many target blocks does not mean three times as much newly issued ZEC. ZIP 218 proposes reducing the scheduled subsidy per block to roughly one-third, preserving scheduled issuance per unit of time apart from rounding. This concerns the total block subsidy, not a guaranteed payment to an individual miner (ZIP 218).
NU7's proposed revenue changes also extend beyond stale blocks: ZIP 259 includes ZIP 235, which would remove 60% of transaction fees from circulation. Miners should distinguish scheduled subsidy, transaction-fee allocation, and pool payouts when assessing revenue (ZIP 259; ZIP 235).
When a block a pool found turns out to be stale, the pool does not receive the reward associated with that specific block. How that loss is reflected in an individual miner's payout depends on the pool's payout method, fee structure, and internal accounting rules, which vary across payout models such as PPS+ and PPLNS. This article does not assume a uniform effect across payout methods, and miners evaluating a pool's resilience to a faster block interval should review that pool's specific payout terms rather than assume a single universal outcome.
The Centralization Trade-off
The NU7 devnet report notes a secondary consideration: mining concentration can make an observed stale-block rate look lower, because a large share of hashrate concentrated within a small number of well-connected pools may receive new blocks faster than a more geographically and operationally distributed network would. Academic work on block propagation similarly finds that lower propagation delay and greater hashrate concentration tend to reduce the observed rate of natural forks, independent of any change to the block interval itself.
This means a lower stale-block rate after NU7 activates would not, by itself, be evidence of healthier decentralization. A network can display fewer natural forks partly because more of its hashrate sits inside a few closely interconnected pools — an outcome that raises separate questions about network resilience that a stale-block statistic alone cannot answer.
Current Status and Timeline
As of this writing, NU7 remains in a draft deployment state. ZIP 259, the deployment specification, lists the Mainnet activation height as to be determined, and the official Zcash NU7 page likewise indicates that the activation height has not yet been set. Readers evaluating NU7's eventual mining impact should treat every figure in this article — the 25-second target, the shielded-action limits, the devnet's 4.86% stale-blocks-per-accepted-block observation, and the proposed difficulty-adjustment window — as descriptions of a proposal under active development, subject to revision before any Mainnet activation is finalized.
Conclusion
NU7, as currently proposed, trades a faster confirmation interval for a higher expected rate of natural stale blocks, a trade-off inherent to shortening any proof-of-work block target. The proposal's authors have built in explicit mitigations — tighter shielded-action limits and a benchmarked reduction in worst-case validation time — intended to keep that increase within a range a geographically distributed devnet test found manageable. For individual miners, the practical risk sits less at the hardware level and more at the level of pool infrastructure: how quickly a pool's nodes receive, validate, and distribute new block templates once blocks arrive roughly three times as often as they do today.
FAQ
Will Zcash NU7 definitely increase the Mainnet stale-block rate?
A Mainnet rate cannot yet be confirmed, since NU7 has not activated and its activation height is unassigned. The proposed reduction in block target spacing from 75 to 25 seconds should raise stale-block risk relative to today's network based on standard propagation dynamics, and a controlled devnet test observed 4.86 stale blocks per 100 accepted blocks under the proposed interval, but that figure describes a specific devnet experiment, not a guaranteed Mainnet outcome.
Do ASIC miners need firmware updates for NU7?
Based on the current proposal, no NU7-specific firmware action is expected at the ASIC level, since ASIC miners do not verify Zcash consensus rules directly and NU7 is not expected to change the block header format. This expectation applies to the upgrade's present design and could change if the proposal's scope changes before activation.
Is a stale block the same thing as a stale share?
No. A stale block is a chain-level outcome affecting which blocks remain canonical. A stale share is work submitted after its earlier job is no longer accepted by the pool. Issuing newer work alone does not necessarily invalidate earlier jobs. Stale work can cause rejection; the pool's reporting and crediting rules determine how it is recorded.
Does a lower stale-block rate always mean a healthier network?
Not necessarily. Research referenced in the NU7 devnet report indicates that higher hashrate concentration within well-connected pools can reduce observed stale-block rates independent of any change to decentralization, so a lower rate alone does not establish improved network health.
When will NU7 activate on Zcash Mainnet?
As of this writing, the Mainnet activation height has not been set. ZIP 259 currently lists it as to be determined, and readers should consult official Zcash upgrade documentation for the finalized date and height once announced.
References
- ZIP 218: 25-Second Block Target Spacing — Source
- ZIP 259: Deployment of the NU7 Network Upgrade — Source
- Zcash NU7 Overview — Source
- Zcash Community Forum: Zebra Devnet Stale-Block Analysis — Source
- ZIP 235: Remove 60% of Transaction Fees From Circulation — Source
- Hardening Stratum, the Bitcoin Pool Mining Protocol, Section 2.4 — Source