ZIP 259: Deployment of the NU7 Network Upgrade

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

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’. ⁴

“ZEC/TAZ” refers to the native currency of Zcash on a given network: ZEC on Mainnet and TAZ on Testnet.

\(\mathsf{MAX\_MONEY}\kern-0.05em\textsf{,}\) as defined in § 5.3 ‘Constants’, is the maximum permitted ZEC/TAZ supply measured in zatoshi. ⁵

“Issued Supply” at a given height means the sum of all chain value pool balances at that height, as calculated in § 4.17 ‘Chain Value Pool Balances’. ⁶

“Scheduled Block Subsidy” means the block subsidy determined by the existing halving schedule, after applying the changes in ZIP 218. ⁷

“NSM Value Balance” is to be interpreted as defined in ZIP 237. It is the consensus-tracked balance of ZEC/TAZ removed from circulation by the Network Sustainability Mechanism (NSM). It is not a spendable chain value pool and is not included in Issued Supply. ⁸

Abstract

This proposal defines the deployment of the NU7 network upgrade. NU7 reduces the block target spacing from 75 seconds to 25 seconds and introduces per-pool and global shielded action limits, as specified in ZIP 218. It also deploys ZIP 235, ZIP 237, and ZIP 2008.

NU7 introduces no new transaction format. Once NU7 activates, version 4 transactions are invalid, while version 5 and version 6 transactions remain valid. Because Sprout transfers can only be represented by version 4 transactions, funds remaining in the Sprout pool become unspendable. ⁹

The changes do not increase the ZEC supply cap. Funds paid from the NSM Value Balance were previously removed from circulation in equal amount. The NSM Value Balance is public consensus state and introduces no new transaction-level data.

Motivation

NU7 is deliberately limited to changes that have strong support from coinholders, developers, and major ecosystem organizations. These changes can be deployed without another transaction-format migration. Faster blocks reduce confirmation latency, while the action limits in ZIP 218 bound the validation and shielded synchronization costs enabled by the increased block frequency.

Specification

NU7 consensus changes

The network handshake and peer management mechanisms defined in ZIP 201 also apply to this upgrade. ¹⁴

NU7 deploys all of the consensus changes specified in the ZIPs listed above, including Revision 2 of ZIP 207 and Revision 3 of ZIP 214. NU7 does not deploy ZIP 233 or ZIP 234. ¹⁵ ¹⁶

On Testnet, the minimum-difficulty threshold specified in ZIP 218 changes at the Testnet NU7 activation height from six to 18 block target spacings. With the 25-second target spacing, a block time must be more than 450 seconds after the preceding block’s time to qualify for minimum difficulty. This change does not affect Mainnet.

The NU7 upgrade does not follow ²’s guidance that network upgrades should be scheduled after the last supporting node on the network’s end of support halt.

NU7 network constants

Each ACTIVATION_HEIGHT (NU7) MUST be a multiple of 3, as required by Revision 3 of ZIP 214. ¹¹

Each NSM_REISSUANCE_HEIGHT is \(\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT}\) for the corresponding network, as calculated in ZIP 237 ⁸. The Testnet ACTIVATION_HEIGHT (NU7) \(A = 4{,}465{,}026\) lies between the second and third pre-NU7 Testnet halvings (2,796,000 and 4,476,000). The ZIP 218 third halving is therefore at \(H_3 = 13{,}428{,}000 - 2A = 4{,}497{,}948\kern-0.05em\textsf{,}\) and the Testnet reissuance height is \(H_3 + 2{,}807{,}274 = 16{,}235{,}274 - 2A = 7{,}305{,}222\kern-0.05em\textsf{.}\)

For each network, nodes compatible with NU7 activation on that network MUST advertise a network protocol version greater than or equal to the corresponding MIN_NETWORK_PROTOCOL_VERSION.

Backward compatibility

Before NU7 activates on a network, NU7 and pre-NU7 nodes can connect to each other. NU7 nodes will prefer other NU7 nodes, so pre-NU7 nodes will gradually be disconnected approaching activation.

Once NU7 activates, NU7 nodes will disconnect peers that advertise a lower network protocol version. Blocks produced under the pre-NU7 consensus rules may also be rejected because of the new target spacing, subsidy calculation, action limits, fee allocation, or transaction-version rule.

Version 5 and version 6 transactions remain structurally unchanged. This does not imply that a transaction is valid across NU7 activation, because its signatures commit to a consensus branch ID.

Rationale

Coinholder and Community polling

The August and September 2026 NU7 polls asked five scope questions: whether to preserve halvings or smooth issuance; when NSM reissuance should begin; when version 4 transactions should be disabled; whether to deploy ZIP 218; and whether to ship promptly with only features ready by the September 30 deadline. The poll announcement records the complete questions and response options. ¹⁷

The polls did not reach a shared majority position on when NSM reissuance should begin. NU7 uses the post-third-halving crossover of reference NSM issuance and the scheduled block subsidy, calculated from the assigned NU7 activation height as specified in ZIP 237 ⁸.

Rationale for no new transaction format

Avoiding a new format limits parser and wallet disruption in the upgrade immediately following the introduction of version 6 in NU6.3. ¹⁹ The fee contribution is a block-level consensus calculation and therefore does not require a new field in ordinary or coinbase transactions.

Open issues

References

Terminology