ZIP: 218
Title: 25-second Block Target Spacing
Owners: Dev Ojha <dev@valargroup.dev>
        Evan Forbes <evan@valargroup.dev>
Status: Draft
Category: Consensus
Created: 2026-03-13
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577>

Terminology

The key words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” in this document are to be interpreted as described in BCP 14 ¹ when, and only when, they appear in all capitals.

The terms “block chain”, “consensus rule change”, “consensus branch”, and “network upgrade” are to be interpreted as defined in ZIP 200. ²

The term “block target spacing” means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the “target block time”, but “block target spacing” is the term used in the Zcash Protocol Specification ³.)

The character § is used when referring to sections of the Zcash Protocol Specification. ⁴

The terms “Mainnet” and “Testnet” are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. ⁵

Abstract

This proposal specifies a change in the block target spacing from 75 seconds to 25 seconds in NU7, and introduces per-pool action limits for the Sapling and Orchard shielded protocols.

This solves three problems.

• Significantly improves the UX for actors who need 1 or 2 conf’s. (Near Intents, small payments) The user-latency goes down 3x.
• Increases consensus bandwidth, which amplifies the scaling impact of a future shielded pool which does not require shielded sync.
• Introduces action limits. These provide limits of the number of actions that can go into a block. There is a global limit across all pools, and per pool limits. It is configured to more than double the Orchard TPS (2.9 → 6.6 TPS), while lowering the impact a DoS attacker can impose on wallets; for example, maximum shielded sync bandwidth for light clients is reduced by 37% (271 → 169 MB/day).

The action limits significantly decrease the number of Sprout and Sapling pool outputs available per block, to lower the maximum shielded sync burden under attempted DoS.

The emission schedule of mined ZEC will be the same in terms of ZEC/day, but this requires the emission per block to be adjusted to take account of the changed block target spacing.

Motivation

The motivations for decreasing the block target spacing are:

• Reduced transaction latency. Currently, users must wait 75 seconds on average for even a single confirmation, regardless of network utilization. This creates friction for point-of-sale payments, exchange deposits, and cross-chain bridge operations. A 25-second target spacing reduces the expected wait for a first confirmation to 25 seconds on average.

• Greater throughput. With 3× as many blocks per day and the same 2 MB block size limit, we will have allocated higher consensus bandwidth capacity. Short term, when paired with the action limits, we will more than double the Orchard TPS for 2-action transactions. Longer term, when we get a shielded pool with no shielded sync burden, we will have 3x higher throughput.

The throughput goal on its own could be achieved via a block size increase. However the goal of this proposal is foremost to improve the transaction latency.

This proposal is complementary to, and does not compete with, finality mechanisms such as Crosslink ⁶. Faster block times improve the responsiveness of the base layer regardless of whether an additional finality gadget is also deployed. Rollback-risk analysis depends on the threat model. For models that bound an attacker by a fixed fraction of total hash power, reducing the block target spacing can reduce confirmation latency by nearly the same factor, provided that block validation and propagation remain small relative to the target spacing. Given that is maintained here, this proposal is expected to improve confirmation latency by slightly less than 3x for users applying the same rollback-risk tolerance as today. See (1)_ for analysis under several attack models.

Economic rollback models give a different result. For recipients who wait until the block rewards built on top of their payment exceed the payment value, then shorter block times significantly reduce the variance of their waiting time, while the mean stays roughly the same. Recall that proof of work block times have high very high variance, so variance reduction is a substantial benefit. This ZIP does not argue for clients reducing confirmation counts, but it does expect many users to see a lower expected time until receipt under confirmation policies comparable to those they use today.

Security

Scaling and block time reductions in Zcash impose three security costs, one on full nodes and miners' ability to verify blocks, a second on clients for shielded sync, and a third on the whole network for the uncle rate and fork rate. Action limits are introduced in this ZIP to limit the block processing costs, and client shielded sync costs. The proposed parameterization lowers the worst case for shielded sync and node processing times relative to today, while yielding far higher Orchard TPS. We benchmark block verification, and the uncle-rate post-proposal on networks more distributed than mainnet at maximum load is far lower than ETH-PoW was, leading to conclusion that it is safe.

Today the worst-case DoS attack can induce 271 MB of wallet sync download to clients per day, and 4.8M trial decryptions per day ⁷. This is d one with max utilizing Sapling transactions, with few inputs and many outputs. The worst-cast DOS for node verification time is done with many Sapling inputs, and a single transparent output, totalling 5600 Sapling inputs and ZKP’s. This takes 3.2s on a modern AMD laptop CPU with 4 pinned threads. Meanwhile regular userflow has far lower costs on the network, than the DOS model.

We propose introducing global action limits and per-pool action limits as follows:

• A maximum of 330 actions per block across all pools

• A maximum of 330 Orchard actions per block

• A maximum of 300 Sapling inputs + outputs. (Total inputs + outputs <= 300)

• A maximum of 25 Sprout JoinSplits per block.

With these limits, the worst case client load becomes 169 MB bandwidth and 2.3M trial decrypts per day. This is a 37% improvement in worst case wallet sync bandwidth despite 3x more blocks. This yields a 2x in Orchard TPS, and keeps Sapling TPS at a higher level than today’s Orchard TPS. We expand on these derivations in []

However, every wallet does have to download every compact block header, which is 90 bytes. This leads to an extra 200kb of wallet bandwidth per day in exchange for the improved UX.

The reduced Sapling and Sprout per-block limits are justified by the current distribution of shielded funds across pools. As of May 2026:

The vast majority of shielded activity is already in Orchard, and this trend is expected to continue. The Sapling and Sprout limits are set generously relative to their current usage while substantially reducing their potential for DoS.

Stale block rate

The stale rate is the percentage of blocks that get orphaned, which relates to mining centralization risk, block propagation delay, and block verification times. Today the stale rate is 0.4%, but this may be lower than what pure block propagation delay may imply due to hashpower centralization in mining pools.

At 25-second block target spacing, the theoretical stale block rate is approximately 3.26%, derived from measured Zcash network propagation delays. A devnet experiment with 99 geographically-distributed Zebra nodes producing 2MB blocks at 25-second target spacing measured a stale block rate of 4.86% and a fork rate of 0.37%. Both observed figures are below the 5.4% safety threshold set by Ethereum’s historical proof-of-work stale rate. ⁸ The only modification required to achieve these rates was tuning TCP configuration (more details in the linked footnote). The devnet’s node distribution was significantly more decentralized than today’s mainnet, so these figures represent a near worst-case scenario. ⁹

Block processing time

A prerequisite for reducing the target block spacing is that block validation and propagation must remain small relative to the target spacing. The per-pool propagation remain small relative to the target spacing. The per-pool action limits introduced by this proposal ensure that worst-case per-block processing time is lower than today’s. The fact that there are three times as many blocks in unit time does mean that the overall worst-case proportion of time taken for processing, and the worst cost of sync after a given time offline for full nodes will increase. We accept this trade-off. These computational limits parallelize well. The max bandwidth requirement from the chain is 655kbps, so syncing with 10mbps bandwidth still has a 15x advantage factor over full blocks on mainnet.

Current worst case: A full 2 MB block today can contain up to ₆₁₇ Orchard actions or ₂,090 Sapling outputs, with no per-pool limits. A fully packed Orchard block requires verifying all action proofs and spend authorization signatures for those ₆₁₇ actions.

Proposed worst case: With the action limits, a block contains at most 330 actions across pools. There is separately, limits per pool. We propose per-pool limits of:

• 330 Orchard actions
• 300 Sapling inputs+outputs.
• 25 Sprout JoinSplits.

This means the new worst case block processing time, if Orchard dominant, would be 14% of today’s worst case, and Sapling’s would be less than one tenth. The per-block verification work is therefore substantially reduced.

Batch verification. Orchard transaction verification benefits from batch validation, where proof and signature verification is amortized across multiple transactions. In Zebra, Orchard transactions are batch-verified in groups of up to 64 transactions (each worst case being a single action). Zebra has performed batch verification during live network syncing since version 3.0.0. With the action limits, a worst-case block’s Orchard bundle can be fully batch-verified in a small number of batches.

Measured timing. We benchmarked worst-case block verification with Zebra on a modern AMD laptop CPU with 4 pinned threads.¹⁰ The figures report wall-clock time for verifying the zero-knowledge proofs and signatures in a single block, without any mempool pre-verification.

• Full Orchard limit (proposed) — binding post-NU7 verification worst case.
• Full Sapling limit (proposed) — verification worst case is all-spends; the bandwidth worst case (all-outputs) is in Rationale.
• Today’s Orchard worst case — dense multi-action (single-action would understate the byte bound).
• Today’s Sapling worst case — analogous, dense multi-spend.

When transactions have already been pre-verified upon entering the mempool, which is the typical case for a node that has been online, block validation reduces to checking signatures and state updates, which is even cheaper.

Specification

The changes described in this section are to be made in the Zcash Protocol Specification ⁴, relative to the specification as of the activation of this proposal.

Consensus changes

Block target spacing

In § 2 ‘Notation’, add \(\mathsf{NU7ActivationHeight}\) and \(\mathsf{PostNU7PoWTargetSpacing}\) to the list of integer constants.

In § 5.3 ‘Constants’, define:

\[\mathsf{PostNU7PoWTargetSpacing} := 25 \text{ seconds}\]

For a given network (production or test), define \(\mathsf{NU7ActivationHeight}\) as the height at which this network upgrade activates on that network, as specified in a separate deployment ZIP.

Define:

\[\mathsf{NU7PoWTargetSpacingRatio} := \mathsf{PostBlossomPoWTargetSpacing} \;/\; \mathsf{PostNU7PoWTargetSpacing} = 3\]

Define \(\mathsf{IsNU7Activated}(\mathsf{height})\) to return true if \(\mathsf{height} \geq \mathsf{NU7ActivationHeight}\kern-0.05em\textsf{\small ,}\) otherwise false.

In § 7.7.3 ‘Difficulty adjustment’, redefine \(\mathsf{PoWTargetSpacing}\) as:

$$ \mathsf{PoWTargetSpacing}(\mathsf{height}) := \begin{cases} \mathsf{PreBlossomPoWTargetSpacing}, &\text{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\ \mathsf{PostBlossomPoWTargetSpacing}, &\text{if } \mathsf{IsBlossomActivated}(\mathsf{height}) \text{ and not } \mathsf{IsNU7Activated}(\mathsf{height}) \\ \mathsf{PostNU7PoWTargetSpacing} &\text{otherwise} \end{cases} $$

Averaging window

In § 2 ‘Notation’, add \(\mathsf{PostNU7PoWAveragingWindow}\) to the list of integer constants.

In § 5.3 ‘Constants’, define:

\[\mathsf{PostNU7PoWAveragingWindow} := 102\]

In § 7.7.3 ‘Difficulty adjustment’, redefine \(\mathsf{PoWAveragingWindow}\) as a height-dependent function:

$$ \mathsf{PoWAveragingWindow}(\mathsf{height}) := \begin{cases} 17, &\text{if not } \mathsf{IsNU7Activated}(\mathsf{height}) \\ \mathsf{PostNU7PoWAveragingWindow} &\text{otherwise} \end{cases} $$

All other references to \(\mathsf{PoWAveragingWindow}\) in § 7.7.3 ‘Difficulty adjustment’ that previously took the constant value 17 are reinterpreted as \(\mathsf{PoWAveragingWindow}(\mathsf{height})\) for the height of the block under consideration. This includes the size of the averaging window used to compute the average target threshold and the average block timespan.

Halving interval and block subsidy

Define:

\[\mathsf{PostNU7HalvingInterval} := \lfloor \mathsf{PostBlossomHalvingInterval} \cdot \mathsf{NU7PoWTargetSpacingRatio} \rfloor = 5{,}040{,}000\]

Redefine the \(\mathsf{Halving}\) function as:

$$ \mathsf{Halving}(\mathsf{height}) := \begin{cases} \left\lfloor \dfrac{\mathsf{height} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}} \right\rfloor, &\text{if not } \mathsf{IsBlossomActivated}(\mathsf{height}) \\[1.5ex] \left\lfloor \dfrac{\mathsf{BlossomActivationHeight} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}} + \dfrac{\mathsf{height} - \mathsf{BlossomActivationHeight}}{\mathsf{PostBlossomHalvingInterval}} \right\rfloor, &\text{if } \mathsf{IsBlossomActivated}(\mathsf{height}) \text{ and not } \mathsf{IsNU7Activated}(\mathsf{height}) \\[1.5ex] \left\lfloor \dfrac{\mathsf{BlossomActivationHeight} - \mathsf{SlowStartShift}}{\mathsf{PreBlossomHalvingInterval}} + \dfrac{\mathsf{NU7ActivationHeight} - \mathsf{BlossomActivationHeight}}{\mathsf{PostBlossomHalvingInterval}} + \dfrac{\mathsf{height} - \mathsf{NU7ActivationHeight}}{\mathsf{PostNU7HalvingInterval}} \right\rfloor, &\text{otherwise} \end{cases} $$

Redefine \(\mathsf{BlockSubsidy}\) to add a case for post-activation heights. The prior Blossom case in § 7.8 ‘Calculation of Block Subsidy and Founders’ Reward', currently written as “otherwise”, must be amended to “if \(\mathsf{IsBlossomActivated}(\mathsf{height})\) and not \(\mathsf{IsNU7Activated}(\mathsf{height})\)”:

$$ \mathsf{BlockSubsidy}(\mathsf{height}) := \begin{cases} \ldots &\text{(prior cases, with the Blossom case amended as above)} \\[1ex] \mathsf{floor}\left(\dfrac{\mathsf{MaxBlockSubsidy}}{\mathsf{BlossomPoWTargetSpacingRatio} \cdot \mathsf{NU7PoWTargetSpacingRatio} \cdot 2^{\mathsf{Halving}(\mathsf{height})}}\right), &\text{if } \mathsf{IsNU7Activated}(\mathsf{height}) \end{cases} $$

This divides the per-block subsidy by an additional factor of 3 relative to the post-Blossom subsidy, so that the total issuance per unit of wall clock time remains the same.

Note: the current post-Blossom block subsidy of 1.5625 ZEC does not divide evenly by 3. The post-NU7 subsidy is \(\mathsf{floor}(156250000 / 6) = 26041666\) zatoshi (0.26041666 ZEC), losing approximately 0.33 zatoshi per block to rounding. Over a full halving interval of 5,040,000 blocks this amounts to less than 0.017 ZEC of total underpaid issuance, a negligible amount. Should ZIP 234 be accepted, the difference will eventually be reissued.

Shielded pool action limits

Define the following constants in § 5.3 ‘Constants’:

\[\mathsf{GlobalShieldedBudget} := 330\] \[\mathsf{OrchardBlockActionLimit} := 330\] \[\mathsf{SaplingBlockIOLimit} := 300\] \[\mathsf{SproutBlockJoinSplitLimit} := 25\]

For each block at height \(\mathsf{height}\) where \(\mathsf{IsNU7Activated}(\mathsf{height})\kern-0.05em\textsf{\small ,}\) the following limits MUST be satisfied:

Per-pool limits:

• The total number of Orchard actions across all transactions in the block MUST NOT exceed \(\mathsf{OrchardBlockActionLimit}\kern-0.05em\textsf{\small .}\) That is, \(\sum_{\mathit{tx} \in \mathit{block}} \mathit{nActionsOrchard}(\mathit{tx}) \leq 330\kern-0.05em\textsf{\small .}\)

• The total number of Sapling inputs and outputs across all transactions in the block MUST NOT exceed \(\mathsf{SaplingBlockIOLimit}\kern-0.05em\textsf{\small .}\) That is, \(\sum_{\mathit{tx} \in \mathit{block}} (\mathit{nSpendsSapling}(\mathit{tx}) + \mathit{nOutputsSapling}(\mathit{tx})) \leq 300\kern-0.05em\textsf{\small .}\)

• The total number of Sprout JoinSplits across all transactions in the block MUST NOT exceed \(\mathsf{SproutBlockJoinSplitLimit}\kern-0.05em\textsf{\small .}\) That is, \(\sum_{\mathit{tx} \in \mathit{block}} \mathit{nJoinSplit}(\mathit{tx}) \leq 25\kern-0.05em\textsf{\small .}\)

Global shielded budget:

In addition to the per-pool limits, the total shielded cost across all pools in a block MUST NOT exceed \(\mathsf{GlobalShieldedBudget}\kern-0.05em\textsf{\small .}\) The shielded cost of a block is defined as:

\[\sum_{\mathit{tx}} \mathit{nActionsOrchard}(\mathit{tx}) \;+\; \sum_{\mathit{tx}} (\mathit{nSpendsSapling}(\mathit{tx}) + \mathit{nOutputsSapling}(\mathit{tx})) \;+\; 2 \times \sum_{\mathit{tx}} \mathit{nJoinSplit}(\mathit{tx}) \;\leq\; 330\]

where the factor of 2 for Sprout JoinSplits reflects that each JoinSplit produces 2 shielded outputs.

This global budget ensures that the worst-case shielded sync bandwidth per block is bounded regardless of which combination of pools is used.

These limits do not apply to the transparent components of transactions. The overall 2 MB block size limit continues to apply as before.

Rationale: Compact sync bandwidth per action

The limits above are chosen to bound the worst-case bandwidth that lightweight wallets must download for shielded sync. The compact representation used for syncing has the following per-note costs:

Orchard: 148 bytes per action, consisting of:

Sapling: 32 bytes per spend (input) and 116 bytes per output, consisting of:

With these limits, the worst-case compact sync bandwidth per block is:

• Orchard: \(330 \times 148 = 48{,}840\) bytes
• Sapling: at most \(300 \times 116 = 34{,}800\) bytes (all-output pathological case)

Due to the global shielded budget, these cannot stack: a block that uses 330 Orchard actions has zero budget remaining for Sapling or Sprout. The worst-case compact sync bandwidth per block is therefore always bounded by the Orchard case at 48,840 bytes.

See the Rationale section for the full daily bandwidth analysis.

Effect on difficulty adjustment

As with the Blossom activation ¹¹, the difficulty adjustment parameter \(\mathsf{PoWMedianBlockSpan}\) refers to a number of blocks and does not change at activation. The change in the effective value of \(\mathsf{PoWTargetSpacing}\) will cause the block spacing to adjust to the new target at the normal rate for a difficulty adjustment. See Difficulty averaging window in the Rationale for analysis of the \(\mathsf{PoWAveragingWindow}\) change.

It is likely that the difficulty adjustment for the first few blocks after activation will be limited by \(\mathsf{PoWMaxAdjustDown}\kern-0.05em\textsf{\small .}\) This is not anticipated to cause any problem.

Minimum difficulty blocks on Testnet

On Testnet, the minimum-difficulty block threshold defined in ZIP 205 ¹² and modified by ZIP 208 ¹¹ continues to use \(6 \cdot \mathsf{PoWTargetSpacing}(\mathsf{height})\) seconds. After activation, this threshold becomes \(6 \times 25 = 150\) seconds.

Non-consensus node behaviour

Default expiry delta

When not overridden by the -txexpirydelta option, node implementations that create transactions use a default expiry delta. The current default of 40 blocks (approximately 50 minutes at 75-second spacing) SHOULD change to \(\mathsf{NU7PoWTargetSpacingRatio} \times 40 = 120\) blocks after activation, to maintain the approximate expiry time of 50 minutes.

If the -txexpirydelta option is set, then the set value SHOULD be used both before and after activation.

Block-count-based constants

The following constants, measured in number of blocks, were reviewed. Implementations SHOULD scale by \(\mathsf{NU7PoWTargetSpacingRatio}\) those constants that represent a time duration (marked “Scale by 3” below), and SHOULD NOT scale those whose semantics are intrinsically measured in blocks (marked “No change”):

This proposal is fundamentally about decreasing the target spacing, which makes the wall-clock margin shorter for any given MAX_REORG_LENGTH. Zebra’s MAX_REORG_LENGTH is currently 99, set just below COINBASE_MATURITY (= 100) by Bitcoin-inherited convention. At Zcash’s launch 150-second spacing it covered about 4.2 hours, at the current 75-second spacing about 125 minutes, and at NU7’s proposed 25-second spacing only about 42 minutes.

Recent incidents show consensus splits can persist beyond tens of minutes: for example, Litecoin’s April 2026 MWEB incident produced a 13-block invalid chain that was later reorged out, with a ₃-hour recovery window per the postmortem ¹³. The optimal long-term value for MAX_REORG_LENGTH likely needs to change further in the future, but that is out of scope here. Raising it to 600 blocks restores the ₄.2-hour wall-clock window it provided at Zcash’s launch 150-second target spacing, while COINBASE_MATURITY remains 100. This is more conservative than the ₁₂₅-minute window at today’s 75-second spacing. Given the incident above and that the launch 150-second-spacing value predates this line of evidence, restoring the launch wall-clock margin is the safer choice.

This deliberately means that a supported reorg may invalidate a mature coinbase output. That case is already a valid consequence of deep PoW reorgs in the abstract protocol model.

Anchor selection depth

ZIP 315 ¹⁴, recommends selecting an anchor 3 blocks back from the chain tip when constructing shielded transactions. The recommended anchor depth SHOULD remain at 3 blocks after activation, reducing the average wall-clock anchor delay from ₃.75 minutes to ₁.25 minutes. This follows the same precedent set by the Blossom upgrade (ZIP 208 ¹¹), which did not update the anchor depth and therefore halved delay.

The increased likelihood of forking due to block time reduction should not be concerning here. For an issue to occur when anchor depth is 3 blocks back, you must have a 4 block re-org. In the many years of Ethereum PoW, a 4 block re-org has never been observed ¹⁵. So we are not practically at risk of inherent randomness causing a re-org. In other POW chains, re-orgs of 4+ blocks resulted from a consensus split of some form, including the recent Litecoin attack, or an attack from a surge in hashpower. Anchor height depth is not intended to protect against those two vectors.

Rationale

Shielded sync bandwidth analysis

The per-pool block space limits are chosen so that the worst-case daily bandwidth for lightweight wallet syncing does not increase relative to the current protocol. This section presents the analysis.

Parameters

Orchard pool:

Sapling pool:

Daily bandwidth comparison

The worst-case compact sync bandwidth is 169.10 MB/day, a reduction of 37% from today’s worst case of approximately 270.5 MB/day. This is despite a 3× increase in block frequency and overall throughput capacity.

The binding constraint is Orchard at 330 actions per block: \(330 \times 148 \times 3{,}456 + 90 \times 3{,}456 = 169.10\text{ MB/day}\kern-0.05em\textsf{\small .}\)

The trial decryption count also decreases significantly, since the per-block action limits more than offset the 3× increase in block count.

Note that the trial decrypt count is 2× the number of shielded outputs/actions, because wallets must attempt decryption with both the internal and external incoming viewing keys (IVKs). The internal IVK detects change outputs sent back to the wallet, while the external IVK detects incoming payments. In principle, wallets could avoid trial decrypts with their IVK assuming other sync trade-offs are taken, but current Sapling and Orchard wallets always attempt both.

Normal transaction throughput

For standard 2-action Orchard transactions, the action limit of 330 allows \(\lfloor 330 / 2 \rfloor = 165\) transactions per block, giving:

\[\mathsf{orchard\_tps} = 165 \;/\; 25 = 6.6 \text{ TPS}\]

For comparison, the current protocol (75s blocks, block-size limited) supports approximately 2.9 TPS for 2-action Orchard transactions. This is a 2.3× increase in normal Orchard throughput.

Sapling throughput. For standard Sapling transactions (2 spends + 2 outputs = 4 IOs), the limit of 300 IOs allows \(\lfloor 300 / 4 \rfloor = 75\) transactions per block, giving \(75 / 25 = 3.0\) TPS. Even with the reduced Sapling limit, the post-NU7 Sapling TPS (3.0) still exceeds the current pre-NU7 Orchard TPS (2.9).

Fee incentives and DoS resistance

A concern with per-pool limits is that a DoS attacker could fill the Sapling or Sprout budget to crowd out Orchard transactions (or vice versa). The global shielded budget prevents this from being worse than filling any single pool, but it is worth examining whether fee incentives create an asymmetry.

Under ZIP 317 ¹⁶, the conventional fee is based on logical actions: each Sapling output or spend counts as one logical action, and each Orchard action counts as one logical action. The marginal fee per logical action is the same regardless of pool. Therefore, an attacker gains no fee advantage by spamming Sapling instead of Orchard (or vice versa). The cost per unit of shielded budget consumed is identical.

Furthermore, because the global shielded budget is shared, filling the Sapling budget necessarily reduces the Orchard budget by the same amount. An attacker who spends their entire budget on Sapling spam at 300 IOs leaves only 30 Orchard actions available in that block. But this attack is no cheaper than filling 330 Orchard actions directly, since the per-action fee is the same. The global budget ensures that the total shielded sync cost per block is bounded to 330 units regardless of the attacker’s pool choice.

The Orchard per-pool cap of 330 also guarantees that legitimate Orchard transactions always have access to the full Orchard budget when Sapling and Sprout are not used, which is the expected common case going forward.

Difficulty averaging window

This proposal increases \(\mathsf{PoWAveragingWindow}\) from 17 to 102 at NU7 activation (specified in Averaging window under Consensus changes), so that the wall-clock smoothing window is \(102 \times 25 = 17 \times 150 = 2{,}550\) seconds — the same wall-clock window the value \(\mathsf{PoWAveragingWindow} = 17\) was originally chosen to provide at Zcash’s launch target spacing of 150 s. At today’s 75 s spacing the same value covers only 1,275 s, and at NU7’s proposed 25 s spacing it would cover only 425 s.

The motivations are:

1. To preserve the wall-clock duration over which difficulty is smoothed, so that NU7 does not amplify difficulty-manipulation attacks like the one recently observed on Litecoin ¹³.
2. As an additional improvement over keeping \(\mathsf{PoWAveragingWindow} = 17\kern-0.05em\textsf{\small ,}\) to reduce the standard deviation of block-spacing averages over short rolling windows.

Under a Zebra difficulty-adjustment simulator ¹⁷ with a stable hash rate and with \(\mathsf{PoWAveragingWindow} = 17\) unchanged across the transition, the expected block spacing recovers to within 5% of the new 25 s target within 62 blocks of NU7 activation:

Setting \(\mathsf{PoWAveragingWindow} = 102\) is expected to require roughly 6× as many blocks to cross each threshold, which is the same wall-clock duration as recovery would have taken at Zcash’s launch 150 s spacing with \(\mathsf{PoWAveragingWindow} = 17\kern-0.05em\textsf{\small .}\)

For a real-world reference point, the Blossom upgrade ¹¹ made a 2× target-spacing reduction (150 s → 75 s) with \(\mathsf{PoWAveragingWindow}\) unchanged; mainnet block spacing (20-block rolling average) reached approximately 74 s at height 653,664 — 64 blocks after activation.

Two geographically-distributed devnets of 99 Zebra nodes across 14 regions (1 vCPU per node), one at \(\mathsf{PoWAveragingWindow} = 17\) and one at 51, confirmed a ~1-second reduction in the standard deviation of 5- and 10-block rolling-average block spacings. The variance reduction is expected to be somewhat larger at \(\mathsf{PoWAveragingWindow} = 102\kern-0.05em\textsf{\small .}\)

Deployment

This proposal is intended to be deployed as part of NU7, should tokenholder polling and developer consensus agree on it. A separate ZIP will specify the deployment details including activation heights and consensus branch IDs.

References