#Terminology

The key words "MUST", "MUST NOT", and "SHOULD" 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 branch", and "network upgrade" follow ZIP 200. ² The character § refers to sections of the Zcash Protocol Specification. ³

"Block target spacing" means the interval between blocks targeted by the difficulty adjustment algorithm. Actual block intervals vary.

The "25-second baseline" means the rules after NU7, including ZIP 218's 25-second target spacing and ZIP 237's subsidy definitions. ^{4 5}

A "stale block" is a valid mined block that does not remain on the selected chain. This document reports "stale blocks per accepted block" separately from the fraction of all mined blocks that become stale.

"Reach 90%" means the time for a block to reach 90% of the specified node sample. "Effective old-tip mining time" means the accumulated mining work spent on the old tip, expressed as seconds of the whole network's mining power.

MB means 1,000,000 bytes.

#Abstract

This proposal reduces block target spacing from 25 to 20 seconds in a network upgrade after NU7. It builds on ZIP 218 without changing its action limits or block size limit. ^{4 6}

The change reduces the expected wait for a first confirmation by 20%. With unchanged per-block limits, it increases maximum transaction throughput by 25%. Nodes and wallets must process 25% more blocks per unit time, increasing worst-case block processing time and sync cost. It adjusts the difficulty averaging window, issuance parameters, and duration-based node defaults to the new spacing. Shorter inclusion intervals can expose finer transaction timing information.

#Motivation

A 20-second target reduces the expected wait for a first confirmation by five seconds. With unchanged per-block limits, it increases maximum transaction throughput by 25%. The additional blocks increase worst-case block processing time and sync cost per unit time. This proposal evaluates that incremental trade-off from ZIP 218's baseline.

#Privacy Implications

ZIP 218 identifies timing and anchor-depth privacy effects. ⁴ Shorter blocks give observers finer timing information without changing what individual shielded transactions reveal.

A three-block anchor depth spans an expected 60 seconds instead of 75. A rollback past the anchor invalidates the transaction. A replacement spending the same notes exposes the same nullifiers, linking the two transactions. Ordinary stale-block measurements do not bound rollback depth.

#Requirements

• Reduce target spacing from 25 to 20 seconds after NU7.
• Preserve approximately the difficulty averaging duration and issuance schedule, including partial halving intervals, subject to integer rounding.
• Preserve historical consensus rules and integrate the transition with ZIP 237 and active funding-stream schedules.

#Specification

This section applies to the post-NU7 rules of ZIPs 218 and 237. ^{4 5} Implementations MUST retain all pre-activation rules at heights below the new activation height.

#Activation and target spacing

Define the following constants:

$𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍:\mathbb{N}$ $𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖯𝗈𝖶𝖳𝖺𝗋𝗀𝖾𝗍𝖲𝗉𝖺𝖼𝗂𝗇𝗀:\mathbb{N}:=20\text{ seconds}$ $𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖲𝗉𝖺𝖼𝗂𝗇𝗀𝖱𝖺𝗍𝗂𝗈:{\mathbb{Q}}_{>0}:=25/20=5/4$

A separate deployment ZIP will assign $𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$ for each network. It MUST be strictly greater than that network's $𝖭𝖴\mathrm{𝟩}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$. No NU7 activation constant changes.

For a height $h\in \mathbb{N}$ at or above this activation height, define:

$𝖯𝗈𝖶𝖳𝖺𝗋𝗀𝖾𝗍𝖲𝗉𝖺𝖼𝗂𝗇𝗀(h):=𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖯𝗈𝖶𝖳𝖺𝗋𝗀𝖾𝗍𝖲𝗉𝖺𝖼𝗂𝗇𝗀.$

For $h<𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$, retain ZIP 218's definition of $𝖯𝗈𝖶𝖳𝖺𝗋𝗀𝖾𝗍𝖲𝗉𝖺𝖼𝗂𝗇𝗀$. In particular, $𝖯𝗈𝗌𝗍𝖭𝖴\mathrm{𝟩}𝖯𝗈𝖶𝖳𝖺𝗋𝗀𝖾𝗍𝖲𝗉𝖺𝖼𝗂𝗇𝗀$ remains 25 seconds.

#Difficulty averaging window

The difficulty adjustment algorithm (DAA) averages over 128 blocks after activation, replacing ZIP 218's 102-block window. The larger block count preserves approximately the same expected averaging duration at the shorter target spacing.

Define:

$𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖯𝗈𝖶𝖠𝗏𝖾𝗋𝖺𝗀𝗂𝗇𝗀𝖶𝗂𝗇𝖽𝗈𝗐:\mathbb{N}:=128.$

For $h\ge 𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$, define:

$𝖯𝗈𝖶𝖠𝗏𝖾𝗋𝖺𝗀𝗂𝗇𝗀𝖶𝗂𝗇𝖽𝗈𝗐(h):=𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖯𝗈𝖶𝖠𝗏𝖾𝗋𝖺𝗀𝗂𝗇𝗀𝖶𝗂𝗇𝖽𝗈𝗐.$

For $h<𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$, retain ZIP 218's averaging window, including 102 blocks after NU7 activation. All uses of this function in the difficulty algorithm use the height of the block under consideration.

The averaging window includes pre-activation blocks when its lookback crosses the activation height. Implementations MUST NOT reset it at activation. ZIP 218's difficulty formulae therefore use:

• a 128-block lookback for $𝖬𝖾𝖺𝗇𝖳𝖺𝗋𝗀𝖾𝗍(h)$;
• $𝖠𝖼𝗍𝗎𝖺𝗅𝖳𝗂𝗆𝖾𝗌𝗉𝖺𝗇(h)=𝖬𝖾𝖽𝗂𝖺𝗇𝖳𝗂𝗆𝖾(h)-𝖬𝖾𝖽𝗂𝖺𝗇𝖳𝗂𝗆𝖾(h-128)$;
• $𝖠𝗏𝖾𝗋𝖺𝗀𝗂𝗇𝗀𝖶𝗂𝗇𝖽𝗈𝗐𝖳𝗂𝗆𝖾𝗌𝗉𝖺𝗇(h)=128\times 20=\mathrm{2,560}$ seconds.

The median-time span, damping factor, adjustment bounds, and proof-of-work limit remain unchanged. Implementations MUST apply the existing difficulty algorithm with these height-dependent inputs from the activation block; there is no separate difficulty reset.

#Halving interval and scheduled subsidy

Define:

$𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅:\mathbb{N}:=𝖯𝗈𝗌𝗍𝖭𝖴\mathrm{𝟩}𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅\cdot 5/4=\mathrm{6,300,000.}$

For the following formula, let $A_{20}=𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$, $A_7=𝖭𝖴\mathrm{𝟩}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$, and $A_B=𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$. These are nonnegative integer heights. For $h\ge A_{20}$, define:

$𝖧𝖺𝗅𝗏𝗂𝗇𝗀(h):=\lfloor \frac{A_B-𝖲𝗅𝗈𝗐𝖲𝗍𝖺𝗋𝗍𝖲𝗁𝗂𝖿𝗍}{\mathrm{840,000}}+\frac{A_7-A_B}{\mathrm{1,680,000}}+\frac{A_{20}-A_7}{\mathrm{5,040,000}}+\frac{h-A_{20}}{\mathrm{6,300,000}}\rfloor .$

The denominators are the pre-Blossom, post-Blossom, post-NU7, and 20-second halving intervals, respectively. For $h<A_{20}$, retain ZIP 218's halving function, including its slow-start cases. Implementations MUST preserve the fractional progress through the halving interval at activation. They MUST NOT restart an interval at $A_{20}$.

For $h\ge A_{20}$, replace ZIP 237's scheduled subsidy with:

$𝖲𝖼𝗁𝖾𝖽𝗎𝗅𝖾𝖽𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(h):=\lfloor \frac{𝖬𝖺𝗑𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒}{2\cdot 3\cdot (5/4)\cdot 2^{𝖧𝖺𝗅𝗏𝗂𝗇𝗀(h)}}\rfloor .$

The factors 2, 3, and $5/4$ are the Blossom, NU7, and 20-second spacing ratios, respectively. The result is a nonnegative integer number of zatoshi. Implementations MUST use the exact rational ratio $5/4$ and apply the floor only to the complete expression. Multiplying an already-rounded 25-second subsidy by $4/5$ can produce a different answer.

For example, at halving index 3 the scheduled subsidy changes from 26,041,666 zatoshi to 20,833,333 zatoshi. Flooring $\mathrm{26,041,666}\times 4/5$ would incorrectly produce 20,833,332 zatoshi.

#Integration with ZIP 237

For $h\ge A_{20}$, redefine ZIP 237's $𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅(h)$ to return $𝖳𝗐𝖾𝗇𝗍𝗒𝖲𝖾𝖼𝗈𝗇𝖽𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$. Retain its earlier cases for $h<A_{20}$. Its existing fraction formula then gives:

$𝖡𝖫𝖮𝖢𝖪\_𝖲𝖴𝖡𝖲𝖨𝖣𝖸\_𝖥𝖱𝖠𝖢𝖳𝖨𝖮𝖭(h)=\frac{\lfloor \mathrm{6,931,680,000}/\mathrm{6,300,000}\rfloor }{{10}^{10}}=\frac{1100}{{10}^{10}}.$

Retain ZIP 237's definition:

$𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(h):=𝖲𝖼𝗁𝖾𝖽𝗎𝗅𝖾𝖽𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(h)+𝖠𝖽𝖽𝗂𝗍𝗂𝗈𝗇𝖺𝗅𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(h).$

Implementations MUST carry the existing NSM Value Balance through activation. They MUST NOT reseed it or recompute historical balances under the new spacing. ZIP 237's additional-subsidy ceiling and balance-update rules continue to apply.

Open specification item: define the NSM reissuance trigger for an activation before reissuance starts. ZIP 259's fixed trigger heights use the 25-second issuance curve. The amended trigger must use the 20-second curve and reissuance fraction. Its reference reserve must use cumulative scheduled issuance through $h-1$, retaining each historical era's integer rounding. If reissuance starts before this upgrade, retain that activated state.

#Action limits

This proposal does not change ZIP 218's action limits, global shielded budget, or block size limit. Implementations MUST continue to enforce them.

#Minimum difficulty blocks on Testnet

Retain ZIP 218's 450-second elapsed-time threshold after this upgrade. A block qualifies only if its timestamp is strictly more than 450 seconds after the preceding block's timestamp. In that case its nBits MUST equal $𝖳𝗈𝖢𝗈𝗆𝗉𝖺𝖼𝗍(𝖯𝗈𝖶𝖫𝗂𝗆𝗂𝗍)$, following ZIP 218.

At and after $A_{20}$, this fixed threshold replaces the expression $18\cdot 𝖯𝗈𝖶𝖳𝖺𝗋𝗀𝖾𝗍𝖲𝗉𝖺𝖼𝗂𝗇𝗀(h)$. Thus 450 seconds does not qualify, while 451 seconds does. This rule does not affect Mainnet. Existing timestamp-validity bounds and local-clock tolerances remain unchanged. The Testnet minimum-difficulty exception remains subject to those rules.

#Non-consensus node behaviour

When converting a height range to expected elapsed time, implementations SHOULD use the target spacing applicable to each block. The expected time from an accepted tip at height $a$ to height $b>a$ is ${\sum }_{h=a+1}^b𝖯𝗈𝖶𝖳𝖺𝗋𝗀𝖾𝗍𝖲𝗉𝖺𝖼𝗂𝗇𝗀(h)$, including the new spacing for the activation block. Policies defined as elapsed durations SHOULD retain those durations across activation.

#Transaction expiry

Wallets SHOULD increase the default expiry delta from 120 to 150 blocks. Choose the default using the transaction's target height, which is the next block height after the chain tip. Use 150 when that height is at or above $A_{20}$; otherwise retain the prior default. Compute expiry relative to the target height as specified by ZIP 218. Wallets SHOULD preserve an explicit user-configured delta across activation.

#Block-count-based defaults

Implementations SHOULD use the following post-activation defaults where they expose the corresponding settings. The table scales duration-based values by $5/4$ relative to ZIP 218. Larger rollback windows conform.

The consensus coinbase maturity remains 100 blocks. This proposal leaves TX_EXPIRING_SOON_THRESHOLD at 3 and NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD at 1728, following ZIP 218.

#Anchor selection depth

Wallets SHOULD retain ZIP 315's recommended anchor depth of 3 blocks. ⁷ Its expected duration changes from 75 to 60 seconds. This recommendation does not guarantee protection against reorganizations.

#Rationale

#Capacity and resource costs

With unchanged per-block limits, nodes and wallets must process 25% more blocks per unit time. If per-block processing time remains unchanged, the worst-case proportion of time spent processing blocks increases by 25%. Syncing blocks produced during a given time offline also requires 25% more work. Maximum two-action Orchard throughput rises from 6.6 to 8.25 transactions per second. ZIP 218's compact-field model rises from approximately 169.10 to 211.38 MB/day; it excludes serialization and transport overhead. ⁴

This figure describes worst-case compact sync bandwidth when blocks fill the shielded action budget. It does not establish a daily download requirement for every wallet.

Ironwood wallet bandwidth constrains the choice of its per-block action limit. This draft retains ZIP 218's limit; it does not increase that limit to obtain more throughput. Shorter target spacing still increases the maximum number of actions per day by 25%. Retaining the per-block limit therefore does not preserve the existing daily bandwidth bound.

Open design item: evaluate a lower Ironwood per-block action limit against a wallet bandwidth budget. Account for the private information retrieval (PIR) query design and measure its download costs before selecting a limit. The compact-field estimate alone does not establish those query costs.

TODO: add matched 25-second and 20-second verification, propagation, and wallet sync measurements under sustained near-full-block workloads.

#Stale blocks and effective propagation time

Following ZIP 218's propagation analysis, we estimate stale blocks per accepted block as the work-weighted time miners remain on the old tip divided by target spacing: $\varphi ={\tau }_{\mathrm{eff}}/T$. ^{4 8}

The Zebra-only devnet data accompanying the propagation report contains 621 block hashes at heights of at least 400 with bodies of at least 1,990,000 bytes. This near-full-block sample has a mean reach-90% time of 1.55994 seconds. ⁸

The mixed-client experiment uses 80 geographically distributed nodes: 40 run Zakura and 40 run Zebra. TODO: identify the mixed-run dataset and report its reach-90% measurement. The 1.56-second input below comes from the Zebra-only sample and has not been established for the mixed run.

Effective old-tip mining time accumulates the mining work still spent on the old tip during propagation. For example, half the network mining the old tip for one second contributes 0.5 effective seconds.

If dissemination rises linearly from 0% to 90% over 1.56 seconds, the old-tip mining share falls from 100% to 10%. Its average is 55%, giving:

${\tau }_{\mathrm{eff}}\approx 1.56\times 0.55=0.858\text{ seconds}.$

At 20 seconds, this gives $\varphi \approx 0.858/20=4.29\%$. It assumes nodes represent mining work and omits any material tail after reaching 90%. Remaining old-tip mining after that percentile adds to the effective time.

Under Poisson discovery, the chance of another block anywhere within 1.56 seconds is $1-e^{-1.56/20}\approx 7.50\%$. That includes blocks found by miners who already received the new tip. The effective-time model counts only old-tip work. Its probability of at least one competitor is $1-e^{-0.858/20}\approx 4.20\%$, distinct from the expected count of 4.29%.

ZIP 218 reports a 3.26% propagation-based estimate at 25 seconds. ⁴ Holding that effective delay fixed gives 4.08% at 20 seconds. The near-full-block filter gives 4.29% under the same model. The difference reflects the sample filter, rather than a different scaling rule.

TODO: publish the filtered dataset and calculation with node coverage and timestamp semantics. The 4.29% value is a theoretical estimate, not an observed 20-second stale rate. The reach proxy does not predict reorganization depth.

#Difficulty averaging duration

ZIP 218's 102-block window at 25 seconds spans an expected 2,550 seconds. The equivalent count at 20 seconds is 127.5 blocks. This proposal rounds up to 128, giving 2,560 seconds, about 0.39% longer. A 127-block window would give 2,540 seconds. Keeping 102 blocks would shorten the duration to 2,040 seconds.

This proposal preserves the averaging duration because mining hash rate can vary. Reducing that duration would change the DAA's response to hash rate changes as well as changing block target spacing.

TODO: simulate activation from the 25-second target and 102-block window to the 20-second target and 128-block window. Include hash rate shocks, network splits, timestamp effects, and recovery criteria.

#Issuance and schedule continuity

The interval change preserves its expected duration:

$\mathrm{6,300,000}\times 20=\mathrm{5,040,000}\times 25\text{ seconds}.$

The halving formula retains progress through the 25-second era. Scaling the unrounded scheduled subsidy by $4/5$ preserves the expected issuance rate before rounding. Integer rounding changes the realized schedule.

The NSM fraction changes from $1375/{10}^{10}$ to $1100/{10}^{10}$, also a factor of $4/5$. ZIP 237's ceiling and evolving balance mean this does not establish exact equality of reissuance per unit of wall-clock time.

Open specification item: amend the funding-stream end heights and address period calculations in ZIPs 207 and 214 for a second spacing transition. ^{9 10} Preserve fractional progress through the active address period and define integer-boundary rounding. Keep ended streams ended and ensure recipient lists cover every extended period. The deployment height and schedule amendments must be settled together; changing NU7 constants retroactively is invalid.

#Reference implementation

TODO: link the implementation and activation vectors. Cover the 25-to-20 transition, 102-to-128 averaging window, exact subsidy rounding, partial halving intervals, funding schedules, NSM state continuity, and Testnet's 450/451-second boundary. Experiment configurations alone do not establish an interoperable consensus implementation.

#Deployment

Deploy this proposal in a separate network upgrade after NU7. ZIP 259 defines NU7's deployment; this proposal does not replace that deployment. ⁶ A separate deployment ZIP will assign this upgrade's activation heights and consensus branch IDs.

Before this ZIP advances to Proposed status, resolve the funding-stream and NSM reissuance-height specification items. Complete the activation and rounding analysis against the selected deployment parameters.

#References