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," Proposed, 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 235 — removes 60% of transaction fees from circulation (miners keep 40%), so they can be reissued later through block subsidies (see "Sustainability mechanism" below).
• ZIP 237 — the "halving-preserving" sustainability mechanism that later reissues those funds without changing the halving schedule. It is now published as its own document (Proposed).
• ZIP 2003 — disallows version 4 transactions once NU7 activates.
• Funding-stream housekeeping — ZIP 207 Revision 2 and ZIP 214 Revision 3 adjust funding-stream address periods and end heights for the new block time, and ZIP 2008 rotates one funding-stream recipient address.

ZIP 259 also states explicitly that NU7 does not deploy ZIP 233 or ZIP 234. That is the current authoritative scope; it widened between our September 25 and October 3 checks, and it can still change before mainnet activation.

When will NU7 activate?

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

We are not inventing a height, and neither should any secondary source you read — both heights above come straight from ZIP 259, and the mainnet one matches Zebra 7.0.0's release notes. If you see a different NU7 mainnet block height, or a fixed calendar date, stated as fact anywhere, 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 3 relative to today, matching the spacing ratio, so ZEC issued per day stays about the same (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 divides the current subsidy by the same 3x spacing ratio. Its formula starts from Zcash's original maximum subsidy (12.5 ZEC, set for the launch 150-second blocks) and divides it by Blossom's ratio of 2 (150 to 75 seconds in 2019), by NU7's ratio of 3, and by 2 for every halving so far:

floor(MaxBlockSubsidy ÷ (BlossomPoWTargetSpacingRatio (2) × NU7PoWTargetSpacingRatio (3) × 2^Halving))

The factor 2 for Blossom is already part of today's subsidy, so relative to today the change is, in ZIP 218's words, "an additional factor of 3 relative to the post-Blossom subsidy". ZIP 218's own worked examples:

• Current subsidy: 1.5625 ZEC = 156,250,000 zatoshi
• After NU7, until the third halving: floor(156,250,000 ÷ 3) = 52,083,333 zatoshi = 0.52083333 ZEC per block
• After NU7 and the third halving: floor(78,125,000 ÷ 3) = 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

The interval uses the same 3x spacing ratio as the per-block subsidy cut, not a combined 6x: blocks three times as often, each paying a third, and three times as many blocks per halving period keep both the ZEC issued per day and the calendar timing of halvings about where they were.

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," Proposed, 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 (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
• Ironwood: 330 actions maximum per block
• Sapling: 300 combined inputs and outputs maximum per block
• Sprout: no JoinSplits at all — achieved together with ZIP 2003's version-4 rule (see below)
• Global shielded budget: 330 units per block, shared across all pools. Per ZIP 218's current Draft text (read October 18, 2026), every Orchard action, every Ironwood action, every Sapling spend and every Sapling output counts as one unit, and every Sprout JoinSplit counts as two. ZIP 218's own example: a transaction with 200 Orchard actions and 200 Ironwood actions satisfies both per-pool limits but exceeds the global budget.

ZIP 218 justifies the reduced Sapling limit and the disabling of Sprout by their low current usage (it cites about 25,409 ZEC, or 0.5% of supply, still in Sprout as of May 2026), and notes 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. An earlier version of ZIP 218, which our September 25 check reflected, still allowed 25 Sprout JoinSplits per block.

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" (NSM, short for Network Sustainability Mechanism). It's actually five separate documents, and ZIP 259 treats them very differently:

How the pieces fit together. From NU7 activation, ZIP 235 moves 60% of fees into the "NSM Value Balance" — a public, consensus-tracked balance that is not spendable and is not counted as issued supply. ZIP 237 then pays it back out gradually as an additional block subsidy. Per ZIP 237's own text, that reissuance starts at a height computed from the scheduled issuance curve: the first block after the (NU7-adjusted) third halving where the reference reissuance amount drops below the scheduled block subsidy. On mainnet that works out to 16,026,474 − 2 × (NU7 activation height); with the mainnet activation height 3,543,405, ZIP 259 gives it as block 8,939,664. On testnet, ZIP 259 gives it as block 7,305,222. Zebra's 7.0.0-rc.0 notes add that NU7 seeds the mainnet reserve with its historical pre-NU6 shortfall of 36,858,445,520 zatoshi (about 368.6 ZEC of unclaimed subsidy and fees). None of this raises the 21M cap: ZIP 259 (Draft, read October 18, 2026) states that "Funds issued from the NSM Value Balance were previously removed from circulation in equal amount, or unclaimed by miners prior to ZIP 236."

What the vote decided, and where it stops. The September 2026 vote (~2.4M of ~3.6M eligible ZEC voting) backed keeping the existing discrete halving schedule rather than ZIP 234's smoothed curve (98.9% to 1.1%). Reporting at the time also cited strong support for starting reissuance in February 2031. ZIP 259's own rationale, however, says the polls "did not reach a shared majority position on when NSM reissuance should begin," and specifies the post-third-halving crossover above instead. We report both rather than pick one. A vote result is not the same thing as a ZIP being marked Final — no ZIP in this table is Final: ZIP 233 and 234 are Draft, and ZIP 235, 237 and 259 are Proposed (re-read October 23, 2026).

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 (the README itself was last checked September 25). 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.52083333 ZEC instead of 1.5625 ZEC once active, and 0.26041666 ZEC after the third halving.
• 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.
• A smaller share of transaction fees — under ZIP 235, miners keep 40% of fees; the other 60% goes into the NSM Value Balance for later reissuance. Zebra 7.0.0-rc.0's getblocktemplate already excludes that NSM contribution from the miner's fee figure from NU7 onward.

Our mining calculator and 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. ZIP 259 now sets the mainnet activation height (block 3,543,405); once NU7 actually activates there, 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 before mainnet activation. Zebra 7.0.0 (October 22, 2026) is that release: it activates NU7 on mainnet at height 3,543,405, its notes say "Mainnet nodes must upgrade before the activation height to stay on the consensus chain", and it "is supported for 8 weeks instead of 12" (see "When will NU7 activate?"). The earlier 7.0.0-rc.0 release candidate covered testnet only. Our Zebra node guide shows what running a node involves. 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 Proposed 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.

NU7 also does not tackle the costs that grow with shielded usage itself, such as wallets scanning every transaction and validators storing every nullifier. That is the target of Project Tachyon, a separate proposal that does not appear in the NU7 sources we reviewed.

Software and infrastructure implications

• Full nodes: require an NU7-aware release. Zebra 7.0.0 (October 22, 2026) is the release that activates NU7 on mainnet at height 3,543,405. Like the 7.0.0-rc.0 testnet release candidate before it, it moves the node database format from v28 to v29, and its notes advise backing up the v28 state before upgrading from Zebra 6.x. The Zcash Foundation had shortened Zebra's end-of-support window "from 15 weeks to 12 so that 6.4.x stops around 2 November, ahead of NU7's tentative Mainnet date of 5 November" (engineering update, October 6) — mainnet operators have to install Zebra 7.0.0 before the activation height.
• 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

• The exact mainnet activation date — ZIP 259 sets a height (block 3,543,405), not a date. At 75-second blocks that is expected around November 5–6, 2026, but real block times vary, and NU7 is not active on mainnet until a block at that height is mined.
• Resolved since our last check: ZIP 259 now publishes the mainnet NSM reissuance height, block 8,939,664, which follows from the mainnet activation height.
• The testnet run — NU7 activated there at block 4,465,026 on October 4. The Zcash Foundation reported no problems in its October 6 update.
• Un-upgraded testnet nodes follow a separate, pre-NU7 chain. A public testnet RPC we checked on October 6 still runs Zebra 6.4.2: it reports no NU7 entry in its upgrade table and a chain past height 4,467,000 with version-4 blocks about 75 seconds apart. That is the expected behaviour of old nodes after a network upgrade, not a protocol fault — but it means older public testnet endpoints, explorers and wallets no longer show the NU7 chain until their operators upgrade.
• Resolved since our last check: Zebra 7.0.0 (October 22, 2026) is the mainnet NU7 release; the earlier 7.0.0-rc.0 was a testnet-only release candidate.
• ZIP 259 itself lists one open item: adding reference implementations and test vectors for the NSM Value Balance.
• Resolved since our first check: we previously flagged a one-digit conflict in the consensus branch ID (0x77190AD9 in ZIP 259 versus 0x77190AD8 in a separate pull request title). Zebra 7.0.0-rc.0 now uses ZIP 259's 0x77190AD9.
• 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: the raw source of ZIP 218, ZIP 235, ZIP 237, ZIP 259 and ZIP 2008 in the zcash/zips repository, Zebra's own changelog (including 7.0.0-rc.0, October 1, 2026, and 7.0.0, October 22, 2026), 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, and cross-referenced reporting on the September 2026 coinholder vote results. Where a fact could not be independently verified against its own primary document, that is stated explicitly rather than presented as confirmed. The first version of this article (September 25) predates ZIP 237's publication and ZIP 259's scope expansion; the October 3 update replaced those parts, and the October 5 update records the testnet activation (height 4,465,026 passed on October 4, confirmed by the Zcash Foundation). Correction, October 6: the public testnet node we also cited on October 5 turned out to run Zebra 6.4.2 and to follow the pre-NU7 chain, so its block height was not evidence of NU7 activation; the Foundation's confirmation and its October 6 engineering update are. The October 23 update records ZIP 259's mainnet activation height (block 3,543,405, Status: Proposed) and the Zebra 7.0.0 release; NU7 is still not active on mainnet, and we'll revisit this page once mainnet reaches that height — 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.