Zcash NU7 Explained: 25-Second Blocks, ZIP 218 & What Changes

Zcash's next network upgrade, NU7, would cut the target time between blocks from 75 seconds to 25 — roughly three times more frequent block production — and rework how the block subsidy and Zcash's long-term sustainability reserve are calculated to match. A September 2026 coinholder vote backed the core ideas by large margins. None of it is active yet. This article works from the current primary sources — ZIP 218, ZIP 259, and the open engineering issues tracking them — to lay out precisely what's decided, what's drafted, what's implemented, and what's still open.

What is Zcash NU7?

NU7 is Zcash's next scheduled network upgrade — a coordinated change to consensus rules that every full node and miner adopts at the same block height. Per ZIP 259 ("Deployment of the NU7 Network Upgrade," Draft, created September 15, 2026), NU7's current scope is:

• ZIP 218 — cuts the block-time target from 75 to 25 seconds, adjusts the block subsidy and difficulty formula to match, and introduces per-pool shielded-action limits.
• ZIP 237 — a "halving-preserving" sustainability reserve mechanism, deployed per ZIP 259's own text but not yet independently published as its own document (see "Sustainability mechanism" below).
• ZIP 2003 — disallows version 4 transactions once NU7 activates.

That's it — that is the current authoritative scope, and it can still change before activation.

When will NU7 activate?

Not on a confirmed date, and not at a confirmed height. Here's exactly what is and isn't decided, kept as separate facts on purpose:

We are not inventing a height where none exists, and neither should any secondary source you read — if you see a specific NU7 mainnet block height stated as fact anywhere before ZIP 259 itself publishes one, treat it with real skepticism.

What changes with 25-second blocks?

The core of ZIP 218: Zcash's proof-of-work target spacing moves from 75 seconds (the rate since the 2019 Blossom upgrade) to 25 seconds — a target-spacing ratio of exactly 3 (75 ÷ 25). Blocks would be expected to arrive roughly three times as often, which is the main thing an ordinary user would notice: faster transaction confirmations.

Why faster blocks are not simply "3x everything"

Cutting the time between blocks by a factor of three does not mean every property of the network scales by exactly three. ZIP 218 makes several different adjustments, each with its own ratio and its own reasoning:

• Per-block subsidy — divided by 6, not 3 (see "Block rewards and issuance" below).
• Difficulty-averaging window — widened by 6x in block-count terms, to hold its real-world duration steady (see "Difficulty" below).
• Shielded-action limits — a brand-new constraint, not a scaled version of anything that existed before, because faster blocks leave less wall-clock time to verify each one.
• Stale/fork rate — a real, non-zero engineering cost that doesn't show up in either the "3x" headline or the subsidy math at all.

Block propagation and stale blocks: producing blocks three times more often gives the network less time between blocks to propagate a given block to every miner before the next one is found, which raises the rate of stale (orphaned) blocks and short forks. ZIP 218 doesn't wave this away — it cites real engineering data: a devnet test with 99 geographically-distributed Zebra nodes, producing 2 MB blocks at a 25-second target spacing, measured a stale rate of approximately 4.86% and a fork rate of approximately 0.37%. ZIP 218 compares this to a 5.4% threshold drawn from Ethereum's own historical proof-of-work stale rate. These are devnet test results, not observed mainnet statistics — mainnet has not run under these rules, so real-world figures once NU7 activates could differ.

Infrastructure: three times as many blocks per unit time means three times as many block templates for pools to distribute, and a materially higher write rate for any indexer or explorer tracking the chain — see "Software and infrastructure implications" below.

Block rewards and issuance

ZIP 218 doesn't just divide the current subsidy by the 3x spacing ratio — it divides by 6, and the reasoning is precise. Zcash's block time was already cut once before, by Blossom in 2019 (150 seconds down to 75), and Blossom's own subsidy formula already accounts for that with a factor of 2. NU7 adds its own 3x ratio on top. The two combine multiplicatively:

BlossomPoWTargetSpacingRatio (2) × NU7PoWTargetSpacingRatio (3) = 6

Applied to today's subsidy:

• Current subsidy: 1.5625 ZEC = 156,250,000 zatoshi
• ZIP 218's own worked example: floor(156,250,000 ÷ 6) = 26,041,666 zatoshi = 0.26041666 ZEC per block

The design goal is straightforward even though the arithmetic isn't: keep the total ZEC issued per unit of real time approximately the same, despite each individual block paying out much less, because blocks now arrive three times as often. This is not a change to how much ZEC ultimately gets issued — it's a change to how that issuance gets sliced across more, smaller blocks.

Halvings and the 21M supply

Zcash's halving interval is currently 1,680,000 blocks. Because blocks would arrive three times as often under NU7, the interval needs to lengthen by the same 3x ratio to keep halvings landing on roughly the same calendar dates rather than arriving three times sooner:

1,680,000 × 3 = 5,040,000 blocks

Note this uses the 3x spacing ratio alone, not the combined 6x used for the per-block subsidy — the halving interval only needs to track calendar time, while the per-block subsidy needs to also absorb Blossom's earlier adjustment.

Nothing here changes Zcash's 21 million ZEC maximum supply. Every adjustment in ZIP 218 — the subsidy divisor, the halving interval — exists specifically to preserve the same issuance curve Zcash was already on, just re-expressed in more, smaller, more frequent blocks. A separate proposal that would have replaced the discrete halving schedule with a smoothed issuance curve — ZIP 234 — was on the same September 2026 ballot and was rejected: coinholders backed keeping the existing discrete halving schedule by roughly 98.9% to 1.1%.

ZIP 218 explained

ZIP 218, "25-second Block Target Spacing," Draft, authored by Dev Ojha and Evan Forbes, is the technical core of NU7. Beyond the subsidy and halving math above, it specifies:

Difficulty. The proof-of-work averaging window — the number of recent blocks difficulty retargeting looks back over — increases from 17 blocks to 102 (also a 6x change: 17 × 6 = 102). The stated reasoning is to hold the window's real-world duration steady: 102 × 25 seconds = 2,550 seconds, which ZIP 218 states matches 17 × 150 seconds — the wall-clock window this parameter was originally chosen to provide, before Blossom's own 2019 block-time cut. ZIP 218 gives this as a deliberate defense against difficulty-manipulation attacks it says faster, thinly-averaged blocks would otherwise be more exposed to, citing "the one recently observed on Litecoin" as the failure mode being designed against — a claim from the ZIP itself, which we have not independently verified in this piece.

Shielded-action limits. New per-block caps, introduced specifically because faster blocks leave less time to verify each one:

• Orchard: 330 actions maximum per block
• Sapling: 300 combined inputs and outputs maximum per block
• Sprout: 25 JoinSplits maximum per block
• Global shielded budget: 330 total actions across all pools, per block

ZIP 218 explains that Sapling and Sprout's limits are set generously relative to their current (much lower) usage, and that ZIP 317's per-logical-action fee design means an attacker gains no cost advantage from targeting one pool's limit over another's.

This is an operational, DoS-resistance change — not a privacy change. See "Does NU7 change Zcash privacy?" below.

Sustainability mechanism — ZIP relationships, precisely

This is the part of NU7 most likely to get flattened into a vague phrase like "a sustainability mechanism." It's actually five separate documents, in three different states, and they should not be treated as interchangeable:

What the vote actually decided (Sept 2026, ~2.4M of ~3.6M eligible ZEC voting): keep the existing discrete halving schedule rather than adopt ZIP 234's smoothed curve (98.9% to 1.1%), and start reissuing sustainability-reserve funds from February 2031 (96.6% support). A vote result is not the same thing as a ZIP being marked Final — ZIP 234's own document still reads Draft and doesn't mention the vote at all. ZIP 259, the deployment specification, is what actually determines NU7's scope, and as of this check it names ZIP 237 for the sustainability component, not 233, 234, or 235 directly.

A note on sourcing: because ZIP 237 has no independently published text of its own yet, the mechanics attributed to it here — that it withholds a share of transaction fees into a reserve from NU7 activation and reissues them via block subsidy starting around February 2031, without requiring a new transaction format — come from ZIP 259's own description and from open Zebra engineering issues tracking its implementation, not from ZIP 237's own primary text. Treat this section as well-corroborated but not independently primary-verified the way ZIP 218 and 259 themselves are.

Candidate ZIPs that are not currently part of NU7's scope: the zcash/zips README lists a broader "NU7 Candidate ZIPs" set for reference — including ZIP 231 (Memo Bundles) and ZIP 2002 (Explicit Fees) — and says plainly that no decision has been made on whether to include each one. Neither appears anywhere in ZIP 259's current text. ZIP 230 ("Version 6 Transaction Format") is Withdrawn, obsoleted back in 2023 by ZIP 229 (which already defines the version-6 format NU6.3/Ironwood uses today). An earlier numbered attempt at NU7's own deployment ZIP, ZIP 254, is also Withdrawn, superseded by the current ZIP 259.

What NU7 means for miners

• ~3x more blocks per unit of time.
• Much smaller reward per individual block — 0.26041666 ZEC instead of 1.5625 ZEC, once active.
• Approximately the same aggregate issuance rate — by design, not by coincidence.
• A wider difficulty-averaging window (102 blocks vs. today's 17), tuned to keep the same real-world smoothing duration.
• A real, non-zero stale/fork-rate cost — ZIP 218's own devnet testing measured ~4.86% stale/~0.37% fork, both below its stated comparison threshold, but not zero.
• More frequent block templates and share accounting for pools, simply from the higher block frequency.

Our /mining/calculator and /tools/halving countdown are not being updated to NU7 assumptions in this piece — NU7 has not activated, and both tools deliberately calculate only against currently-active consensus rules. Once a mainnet activation height exists, the following inputs will need updating together, not individually: block-time assumption, per-block subsidy, the halving-interval block count, and potentially the difficulty-window figure used anywhere reward variance is modeled.

What NU7 means for wallets and exchanges

For ordinary users: faster expected confirmations once NU7 is active. NU7 involves no token swap, no new ZEC asset, and no address-format migration of the kind ZIP 218 itself requires — you would not need to move funds to a new address because of this upgrade.

For operators: full nodes need NU7-aware software once it ships (Zebra has not released this yet — see "When will NU7 activate?"). Indexers and block explorers may need adaptation for the new block cadence and the retirement of version 4 transactions. Exchanges would be expected to perform the kind of routine upgrade-window maintenance seen around prior Zcash upgrades, including Ironwood's July 2026 activation.

We have not found a current primary-source statement from any specific wallet or exchange confirming NU7 readiness, and we're not claiming one here — that's a genuinely open question, not an assumption in either direction.

Sprout and version-4 transactions

Sprout was Zcash's original shielded pool, deprecated in practice since Sapling in 2018 but never consensus-disabled. ZIP 2003 ("Disallow version 4 transactions") is the proposal cited for this rule; its consequence for Sprout is stated directly in ZIP 259 itself, not merely inferred from ZIP 2003's title. We're deliberately not summarizing this as "NU7 burns Sprout" — that overstates both the mechanism (nothing is burned; funds would simply lack a valid transaction format to move them) and the certainty (this is a Draft deployment specification, not yet-active consensus rules).

Does NU7 change Zcash privacy?

No — not materially. Nothing in ZIP 218, ZIP 259, or the sustainability-mechanism ZIPs changes what a shielded transaction reveals or hides, how viewing keys work, or how Orchard or Ironwood's proof systems function. The one shielded-pool-adjacent change NU7 introduces is the per-pool action limits described above — an operational cap on how many shielded actions fit in a block, designed for DoS-resistance under faster blocks. It changes capacity, not privacy. We're not presenting NU7 as a privacy upgrade, because it isn't one.

Software and infrastructure implications

• Full nodes: require an NU7-aware release once Zebra ships one — not available as of this check; the implementation exists only as an open, in-progress draft pull request.
• Indexers/explorers: likely need updates for the new block cadence and the retirement of version 4 transactions.
• Mining pools: need to account for smaller, more frequent block rewards and the real stale-rate trade-off in payout logic.
• Wallets: expected to need little to no change for ordinary sending/receiving, per current reporting — but see the Sprout/version-4 note above for the one concrete exception.

What is still unresolved

• No activation height exists for testnet or mainnet — both explicitly TBD in ZIP 259.
• ZIP 237 is not independently published — everything about its mechanics is sourced from ZIP 259's description and Zebra's open implementation work, not ZIP 237's own primary text.
• Whether ZIP 237 and ZIP 2003 ship at NU7's initial activation, or are deferred, is not fully settled — the coinholder vote's own result favored shipping whatever is genuinely ready rather than waiting on every contested item.
• Zebra has not released NU7 support — implementation is open and in-progress, not merged, not released.
• Open protocol-specification work remains on the ZIP-editor side.
• A technical detail we found genuinely conflicting and are not resolving here: ZIP 259's own text states NU7's consensus branch ID as 0x77190AD9; a pull request title in a separate Zcash repository states 0x77190AD8 — a one-digit difference. This has no bearing on anything in this article for ordinary readers; we mention it only so it isn't silently picked one way before the primary sources themselves resolve it.
• No current primary-source statement was found from wallet or exchange vendors confirming NU7 readiness specifically.

Sources & methodology

This article is based on direct review of: ZIP 218 and ZIP 259's raw source and commit history in the zcash/zips repository, the zcash/zips README's NU7 Candidate ZIPs section (used only to identify candidates, never to infer final inclusion — ZIP 259 alone determines that here), ZIP 230 and ZIP 234's own status fields, open GitHub issues and pull requests tracking Zebra's NU7 implementation, and cross-referenced reporting on the September 2026 coinholder vote results. Where a fact could not be independently verified against its own primary document — ZIP 237 chief among them — that is stated explicitly rather than presented as confirmed. Because ZIP 259's activation parameters are explicitly scheduled to change (Oct 5 testnet, Oct 20 mainnet), we'll revisit this page as those dates pass — see the Zcash Network Upgrade Tracker for the current, continuously-maintained status in the meantime, and Zcash's Ironwood Upgrade for how this same primary-source-first approach applied to Zcash's previous network upgrade. For the underlying halving mechanics this upgrade adjusts, see Zcash Halving Explained; for how Zcash mining works day to day, see Zcash Mining Explained, which already covers ZIP 218's subsidy math in detail. For the complete upgrade history NU7 would extend, see Zcash Network Upgrades: A Complete Timeline.