# ZIP 218: 25-second Block Target Spacing

Status: Draft

Owners: Dev Ojha, Evan Forbes

Snapshot: a34cfc091434275120ff017c92c3b50d3cef623a

Source date: 2026-10-16T02:56:04+01:00

[Source revision](https://github.com/zcash/zips/commit/a34cfc091434275120ff017c92c3b50d3cef623a)

[Official source](https://zips.z.cash/zip-0218) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-0218.md) · [Discussion](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577)

## Document parts

[Part 1](https://zip-tools-web.harpocrates.workers.dev/zip/218) · [Part 2](https://zip-tools-web.harpocrates.workers.dev/zip/218?part=2)

Reading part 2 of 2. Follow all parts for the complete proposal.

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 ~3-hour
recovery window per the postmortem <a id="user-content-fnref-litecoin-mweb-incident"></a>
[28](#user-content-fn-litecoin-mweb-incident). 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 at least 600 blocks restores the ~4.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
~125-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.

Since version 5.2.0, Zebra keeps a rollback window of 1000 blocks before and
after activation (about 20.8 hours at 75-second spacing and 6.9 hours at
25-second spacing), which satisfies the floor of 600.

<a id="rationale-for-anchor-selection-depth"></a>

### Rationale for anchor selection depth

This follows the same precedent set by the Blossom upgrade (ZIP 208
<a id="user-content-fnref-zip-0208-5"></a>
[24](#user-content-fn-zip-0208)), which did not update the anchor depth and therefore halved delay.

| Parameter | Current | Post-activation | Notes |
| --- | --- | --- | --- |
| Recommended anchor depth | 3 blocks (~3.75 min) | 3 blocks (~1.25 min) | No change; follows Blossom precedent |

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 <a id="user-content-fnref-lovejoy-reorg"></a>
[29](#user-content-fn-lovejoy-reorg). 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.

<a id="shielded-sync-bandwidth-analysis"></a>

### 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

| Parameter | Value |
| --- | --- |
| Block size limit | 2,000,000 bytes |
| Block target spacing | 25 seconds |
| Blocks per day | $ 86{,}400 / 25 = 3{,}456$ |
| Compact block header size | ~90 bytes |

**Orchard and Ironwood pools:**

| Parameter | Value |
| --- | --- |
| $\mathsf{OrchardProtocolBlockActionLimit}$ | 330 actions per pool |
| Compact sync bandwidth per action | 148 bytes |
| Compact bandwidth per block | $330 \times 148 = 48{,}840$ bytes |

**Sapling pool:**

| Parameter | Value |
| --- | --- |
| $\mathsf{SaplingBlockIOLimit}$ | 300 (inputs + outputs) |
| Compact sync bandwidth per spend | 32 bytes |
| Compact sync bandwidth per output | 116 bytes |
| Compact bandwidth per block (worst case, all outputs) | $300 \times 116 = 34{,}800$ bytes |

#### Daily bandwidth comparison

| Metric | Current (75s, no pool limits) | Proposed (25s, action limits) |
| --- | --- | --- |
| Blocks per day | 1,152 | 3,456 |
| Max Orchard + Ironwood actions/block | ~617 (block-size limited) | 330 |
| Sapling IOs/block | ~2,140 (simulated attack) | 300 (limit) |
| Orchard or Ironwood compact BW/day | ~105.2 MB | 168.79 MB |
| Sapling compact BW/day | ~270.38 MB | 120.27 MB |
| Compact block headers/day | ~0.10 MB | 0.31 MB |
| **Worst-case total BW/day** | **~270.5 MB** | **169.10 MB** |
| Worst-case trial decrypts/day | ~4.8M | ~2.3M |

The pre-activation Sapling estimates use the Shielded Sync Simulator's
<a id="user-content-fnref-syncsimulator-2"></a>
[8](#user-content-fn-syncsimulator) one-spend, 64-output transaction model; IOs count both spends
and outputs. They are not maxima over arbitrary input/output mixes. The simulator
uses 32 compact bytes per spend and 112 per output, whereas the post-activation
Sapling bound above uses 116 bytes per output.

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 or Ironwood at 330 actions per block:
$330 \times 148 \times 3{,}456 + 90 \times 3{,}456 = 169.10\textsf{ MB/day}$.

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 per account 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 one of their IVKs assuming other sync trade-offs are taken, but current Sapling
and Orchard-protocol wallets always attempt both.

#### Normal transaction throughput

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

$\mathsf{orchard\_protocol\_tps} = 165 \;/\; 25 = 6.6 \textsf{ 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 one
pool's budget to crowd out transactions in another pool. 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 <a id="user-content-fnref-zip-0317"></a>
[30](#user-content-fn-zip-0317), the conventional fee is based on *logical
actions*. Each Orchard or Ironwood action counts as one logical action,
but a transaction's Sapling spends and outputs count as
$\max(\mathit{nSpendsSapling}, \mathit{nOutputsSapling})$ logical actions,
whereas they consume $\mathit{nSpendsSapling} + \mathit{nOutputsSapling}$
units of the global shielded budget. A balanced Sapling bundle therefore
buys budget units at half the Orchard or Ironwood price, while an
all-output or all-spend Sapling bundle pays the same price per unit.

Furthermore, because the global shielded budget is shared, filling one
pool's budget necessarily reduces the remaining budget for all other
pools by the same amount. An attacker who spends their entire budget on
Sapling spam at 300 IOs leaves only 30 Orchard or Ironwood actions
available in that block. With 150 Sapling spends and 150 Sapling outputs,
plus 30 Orchard actions, the attacker exhausts the budget for 180 logical
actions, about 55% of the conventional fee for 330 Orchard or Ironwood
actions. Such a block carries less compact sync data, however:
$150 \times 32 + 150 \times 116 + 30 \times 148 = 26{,}640$ bytes, against
$330 \times 148 = 48{,}840$ bytes.
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 bounds this ZIP sets therefore still hold: a block contains at most 330
units in any mix of pools, and the cheapest way to exhaust the budget carries
less compact sync data than an Orchard-protocol block. What the Sapling
pricing changes is the cost of crowding other transactions out of a block. At
the ZIP 317 marginal fee of 5,000 zatoshis, it is 0.009 ZEC per block, about
31 ZEC per day at 25-second spacing, instead of 0.0165 ZEC and about 57 ZEC.
A future ZIP could remove the difference by counting
$\mathit{nSpendsSapling} + \mathit{nOutputsSapling}$ logical actions in
ZIP 317, which raises the conventional fee of a typical one-spend, two-output
Sapling transaction by half, or by having block templates rank transactions by
fee per unit of shielded budget rather than per logical action.

The 330-action per-pool cap also allows either Orchard or Ironwood
transactions to use the full global budget when other shielded pools are
not used.

<a id="difficulty-averaging-window-difficulty-averaging-window"></a>

### Difficulty averaging window [difficulty-averaging-window]

This proposal increases $\mathsf{PoWAveragingWindow}$ from 17 to 102
at NU7 activation (specified in
[Averaging window](#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
   <a id="user-content-fnref-litecoin-mweb-incident-2"></a>
   [28](#user-content-fn-litecoin-mweb-incident).

2. As an additional improvement over keeping
   $\mathsf{PoWAveragingWindow} = 17$, to reduce the standard
   deviation of block-spacing averages over short rolling windows.

Under a Zebra difficulty-adjustment simulator
<a id="user-content-fnref-daa-recovery-benchmark"></a>
[31](#user-content-fn-daa-recovery-benchmark) 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:

| Expected spacing | Blocks after activation | Wall-clock |
| --- | --- | --- |
| 75 s (pre-NU7 target) | — | — |
| 56.8 s (activation) | 0 | — |
| $\leq 30$ s | 30 | ~21 min |
| $\leq 26.25$ s | 62 | ~36 min |

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$.

For a real-world reference point, the Blossom upgrade <a id="user-content-fnref-zip-0208-6"></a>
[24](#user-content-fn-zip-0208)
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$.

<a id="deployment"></a>

## Deployment

This proposal is intended to be deployed as part of NU7. ZIP 259 <a id="user-content-fnref-zip-0259-3"></a>
[16](#user-content-fn-zip-0259)
specifies the deployment details, including activation heights and the
consensus branch ID.

<a id="reference-implementation"></a>

## Reference implementation

- Zebra: <a id="user-content-fnref-zebra-11529"></a>
  [32](#user-content-fn-zebra-11529)

- Zakura: <a id="user-content-fnref-zakura-1066"></a>
  [33](#user-content-fn-zakura-1066) <a id="user-content-fnref-zakura-1068"></a>
  [34](#user-content-fn-zakura-1068) <a id="user-content-fnref-zakura-1221"></a>
  [35](#user-content-fn-zakura-1221)

<a id="references"></a>

## References

<a id="footnote-label"></a>

### Footnotes

1. [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14) [↩](/zip/218#user-content-fnref-bcp14)

2. [ZIP 200: Network Upgrade Mechanism](/zip/200) [↩](/zip/218#user-content-fnref-zip-0200)

3. [Zcash Protocol Specification, Version 2025.6.3. Section 7.7.3: Difficulty adjustment](protocol/protocol.pdf#diffadjustment) [↩](/zip/218#user-content-fnref-protocol-diffadjustment)

4. [Zcash Protocol Specification, Version 2025.6.3 or later](protocol/protocol.pdf) [↩](/zip/218#user-content-fnref-protocol) [↩2](/zip/218#user-content-fnref-protocol-2)

5. [Zcash Protocol Specification, Version 2025.6.3. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) [↩](/zip/218#user-content-fnref-protocol-networks)

6. [Zcash Trailing Finality Layer: Crosslink](https://daira.github.io/tfl-book/design/crosslink.html) [↩](/zip/218#user-content-fnref-crosslink)

7. [On Slow and Fast Block Times](https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/) [↩](/zip/218#user-content-fnref-slowfastblocks)

8. [Shielded Sync Simulator](https://nu7syncsimulator.valargroup.dev/) [↩](/zip/218#user-content-fnref-syncsimulator) [↩2](#user-content-fnref-syncsimulator-2)

9. [ZIP 2003: Disallow version 4 transactions](/zip/2003) [↩](/zip/218#user-content-fnref-zip-2003)

10. [Forum: Proposal — Lower Zcash Block Target Spacing to 25s](https://forum.zcashcommunity.com/t/proposal-lower-zcash-block-target-spacing-to-25s/54577) [↩](/zip/218#user-content-fnref-forum-proposal)

11. [Forum: Zcash Block Time Reduction Appears Safe for NU7 w/ Zebra-only Devnet](https://forum.zcashcommunity.com/t/zcash-block-time-reduction-appears-safe-for-nu7-w-zebra-only-devnet/55586) [↩](/zip/218#user-content-fnref-devnet-blocktime-test)

12. [ZIP 229: Version 6 Transaction Format](/zip/229) [↩](/zip/218#user-content-fnref-zip-0229) [↩2](/zip/218#user-content-fnref-zip-0229-2)

13. [Zebra worst-case block verification benchmark (`worst_case_tx_verification.rs`)](https://github.com/valargroup/zebra/blob/evan/benchmark-worst-case-block-verification/zebra-consensus/benches/worst_case_tx_verification.rs) [↩](/zip/218#user-content-fnref-verification-benchmark)

14. [ZIP 315: Best Practices for Wallet Implementations](/zip/315) [↩](/zip/218#user-content-fnref-zip-0315) [↩2](/zip/218#user-content-fnref-zip-0315-2) [↩3](/zip/218#user-content-fnref-zip-0315-3)

15. [Zcash Protocol Specification, Version 2025.6.3. Section 5.3: Constants](protocol/protocol.pdf#constants) [↩](/zip/218#user-content-fnref-protocol-constants)

16. [ZIP 259: Deployment of the NU7 Network Upgrade](/zip/259) [↩](/zip/218#user-content-fnref-zip-0259) [↩2](/zip/218#user-content-fnref-zip-0259-2) [↩3](#user-content-fnref-zip-0259-3)

17. [Zcash Protocol Specification, Version 2025.6.3. Section 7.8: Calculating Block Subsidy, Funding Streams, Lockbox Disbursement, and Founders' Reward](protocol/protocol.pdf#subsidies) [↩](/zip/218#user-content-fnref-protocol-subsidies)

18. [ZIP 237: Network Sustainability Mechanism: Halving-Preserving Issuance](/zip/237) [↩](/zip/218#user-content-fnref-zip-0237)

19. [ZecStats Mainnet network statistics](https://zecstats.org/network), reporting height 3,501,422 at 2026-09-30 12:05 UTC. [↩](/zip/218#user-content-fnref-mainnet-height-20260930)

20. [ZIP 214: Consensus rules for a Zcash Development Fund](/zip/214) [↩](/zip/218#user-content-fnref-zip-0214)

21. [ZIP 207: Funding Streams](/zip/207) [↩](/zip/218#user-content-fnref-zip-0207)

22. [Zcash Protocol Specification, Version 2025.6.3. Section 7.1: Transaction Encoding and Consensus](protocol/protocol.pdf#txnencoding) [↩](/zip/218#user-content-fnref-protocol-txnencoding)

23. [Zcash Light Wallet Protocol v0.5.0: `compact_formats.proto`](https://github.com/zcash/lightwallet-protocol/blob/v0.5.0/walletrpc/compact_formats.proto) [↩](/zip/218#user-content-fnref-lightwallet-protocol)

24. [ZIP 208: Shorter Block Target Spacing](/zip/208) [↩](/zip/218#user-content-fnref-zip-0208) [↩2](/zip/218#user-content-fnref-zip-0208-2) [↩3](/zip/218#user-content-fnref-zip-0208-3) [↩4](/zip/218#user-content-fnref-zip-0208-4) [↩5](#user-content-fnref-zip-0208-5) [↩6](#user-content-fnref-zip-0208-6)

25. [ZIP 205: Deployment of the Sapling Network Upgrade](/zip/205) [↩](/zip/218#user-content-fnref-zip-0205)

26. [ZIP 315: Best Practices for Wallet Implementations — Expiration height](/zip/315#expiration-height) [↩](/zip/218#user-content-fnref-zip-0315-expiration-height)

27. [Zcash Protocol Specification, Version 2025.6.3. Section 7.1.2: Transaction Consensus Rules](protocol/protocol.pdf#txnconsensus) [↩](/zip/218#user-content-fnref-protocol-txnconsensus)

28. [Litecoin MWEB Security Incident Postmortem](https://litecoin.com/news/litecoin-mweb-security-incident-postmortem) [↩](#user-content-fnref-litecoin-mweb-incident) [↩2](#user-content-fnref-litecoin-mweb-incident-2)

29. [Lovejoy, James P. (2020). *An Empirical Analysis of Chain Reorganizations and Double-Spend Attacks on Proof-of-Work Cryptocurrencies.* M.Eng. thesis, Massachusetts Institute of Technology, Department of Electrical Engineering and Computer Science.](https://static1.squarespace.com/static/6675a0d5fc9e317c60db9b37/t/66eb3560532516773c4f7ece/1726690657755/LovejoyJamesP-meng-eecs-2020+%281%29.pdf) [↩](#user-content-fnref-lovejoy-reorg)

30. [ZIP 317: Proportional Transfer Fee Mechanism](/zip/317) [↩](#user-content-fnref-zip-0317)

31. [Zebra difficulty-adjustment recovery simulator: `benchmark_hash_rate_shock_daa_configurations` in `zebra-state/src/service/check/difficulty.rs`](https://github.com/valargroup/zebra/blob/evan/benchmark-worst-case-block-verification/zebra-state/src/service/check/difficulty.rs#L555). The 3× target-spacing transition is exercised by [`simulate_three_x_target_spacing_reduction`](https://github.com/valargroup/zebra/blob/evan/benchmark-worst-case-block-verification/zebra-state/src/service/check/difficulty.rs#L397) in the same file. [↩](#user-content-fnref-daa-recovery-benchmark)

32. [Zebra PR 11529: feat(consensus)!: implement NU7 spacing, funding schedules, and shielded limits](https://github.com/ZcashFoundation/zebra/pull/11529) [↩](#user-content-fnref-zebra-11529)

33. [Zakura PR 1066: feat(consensus): reduce block target spacing to 25 seconds at NU7](https://github.com/zakura-core/zakura/pull/1066) [↩](#user-content-fnref-zakura-1066)

34. [Zakura PR 1068: fix(chain): apply NU7 spacing at activation boundary](https://github.com/zakura-core/zakura/pull/1068) [↩](#user-content-fnref-zakura-1068)

35. [Zakura PR 1221: test(chain): pin ZIP 218 rounding over every block and halving era](https://github.com/zakura-core/zakura/pull/1221) [↩](#user-content-fnref-zakura-1221)

## Citation relationships

Cites: [ZIP 200](https://zip-tools-web.harpocrates.workers.dev/zip/200), [ZIP 203](https://zip-tools-web.harpocrates.workers.dev/zip/203), [ZIP 205](https://zip-tools-web.harpocrates.workers.dev/zip/205), [ZIP 207](https://zip-tools-web.harpocrates.workers.dev/zip/207), [ZIP 208](https://zip-tools-web.harpocrates.workers.dev/zip/208), [ZIP 214](https://zip-tools-web.harpocrates.workers.dev/zip/214), [ZIP 229](https://zip-tools-web.harpocrates.workers.dev/zip/229), [ZIP 237](https://zip-tools-web.harpocrates.workers.dev/zip/237), [ZIP 259](https://zip-tools-web.harpocrates.workers.dev/zip/259), [ZIP 315](https://zip-tools-web.harpocrates.workers.dev/zip/315), [ZIP 317](https://zip-tools-web.harpocrates.workers.dev/zip/317), [ZIP 2003](https://zip-tools-web.harpocrates.workers.dev/zip/2003)

Cited by: [ZIP 203](https://zip-tools-web.harpocrates.workers.dev/zip/203), [ZIP 207](https://zip-tools-web.harpocrates.workers.dev/zip/207), [ZIP 208](https://zip-tools-web.harpocrates.workers.dev/zip/208), [ZIP 214](https://zip-tools-web.harpocrates.workers.dev/zip/214), [ZIP 237](https://zip-tools-web.harpocrates.workers.dev/zip/237), [ZIP 259](https://zip-tools-web.harpocrates.workers.dev/zip/259), [ZIP 271](https://zip-tools-web.harpocrates.workers.dev/zip/271), [ZIP 401](https://zip-tools-web.harpocrates.workers.dev/zip/401), [ZIP 1016](https://zip-tools-web.harpocrates.workers.dev/zip/1016), [ZIP 2008](https://zip-tools-web.harpocrates.workers.dev/zip/2008)