ZIP: 259
Title: Deployment of the NU7 Network Upgrade
Owners: Dev Ojha <[email protected]>
Status: Draft
Category: Consensus / Network
Created: 2026-09-15
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/nu7-coinholder-vote/56912>
The key words “MUST” and “MUST NOT” in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
The term “network upgrade” is to be interpreted as described in ZIP 200. 2
The character § is used when referring to sections of the Zcash Protocol Specification. 3
The terms “Mainnet” and “Testnet” are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. 4
“Scheduled Block Subsidy” means the block subsidy determined by the existing halving schedule, after applying the changes in ZIP 218. 5
This proposal defines the deployment of the NU7 network upgrade. NU7 reduces the block target spacing from 75 seconds to 25 seconds, introduces per-pool and global shielded action limits, introduces the Network Sustainability Mechanism (NSM), and removes 60% of transaction fees from circulation. It also deploys 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. 6
The changes do not increase the ZEC supply cap. Funds issued from the NSM Value Balance were previously removed from circulation in equal amount, or unclaimed by miners prior to ZIP 236 7. The NSM Value Balance is public consensus state and introduces no new transaction-level data.
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.
The primary sources of information about NU7 consensus protocol changes are:
FS_FPF_ZCG_H3 address list. 12The network handshake and peer management mechanisms defined in ZIP 201 also apply to this upgrade. 13
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. 14 15
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.
For NU7 only, the requirement in ZIP 200 2 that ACTIVATION_HEIGHT MUST exceed DEPRECATION_HEIGHT in the last software version without support for the upgrade is waived. The recommendation to allow approximately three months after the first supporting software release is also waived. This exception does not change the scheduling requirements for other network upgrades. Operators of unsupported software may therefore remain online at activation and follow a pre-NU7 consensus branch; deployment communications need to explicitly warn operators to upgrade before activation.
The following network upgrade constants are defined for NU7: 2
0x77190AD9Each ACTIVATION_HEIGHT (NU7) MUST be a multiple of 3, as required by Revision 3 of ZIP 214. 9 The Mainnet activation height MUST also satisfy the address-list constraint in ZIP 2008 12, so that the new funding recipient is selected before the stream ends.
Each NSM_REISSUANCE_HEIGHT is \(\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT}\) for the corresponding network, as calculated in ZIP 237 11. 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.
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.
The version 4 prohibition applies to all version 4 transactions, including transparent-only and Sapling transactions, not only Sprout transfers. Wallets and transaction services need to stop constructing version 4 transactions for post-activation inclusion and clearly report pending transactions that become invalid. Where possible, users can recreate non-Sprout transactions in a supported format; re-signing alone cannot make a version 4 transaction valid. Saved and offline-signed transactions need the same activation checks. Sprout transactions have no supported post-activation replacement format.
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.
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. 16
The coinholder and community poll results are available at 17.
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 11.
Avoiding a new format limits parser and wallet disruption in the upgrade immediately following the introduction of version 6 in NU6.3. 18 The fee contribution is a block-level consensus calculation and therefore does not require a new field in ordinary or coinbase transactions.
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” ↩︎
Zcash Protocol Specification, Version 2026.8.0 [NU6.3] or later ↩︎
Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.12: Mainnet and Testnet ↩︎
ZIP 237: Network Sustainability Mechanism: Halving-Preserving Issuance ↩︎
ZIP 233: Network Sustainability Mechanism: Removing Funds From Circulation ↩︎
ZIP 234: Network Sustainability Mechanism: Issuance Smoothing ↩︎