ZIP: 237
Title: Network Sustainability Mechanism: Halving-Preserving Issuance
Owners: Judah Caruso <judah@shieldedlabs.net>
Original-Authors: Nathan Wilcox
                  Jason McGee
                  Zooko Wilcox
                  Mark Henderson
                  Tomek Piotrowski
                  Mariusz Pilarek
                  Paul Dann
Credits: Conrado Gouvea
Status: Proposed
Category: Consensus
Created: 2026-08-19
License: BSD-2-Clause
Discussions-To: <https://github.com/zcash/zips/issues/1353>
Pull-Request: <https://github.com/zcash/zips/pull/1354>

#Terminology

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

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. ²

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

The symbol "$\cdot$" means multiplication, and $𝖿𝗅𝗈𝗈𝗋(x)$ and $𝖼𝖾𝗂𝗅𝗂𝗇𝗀(x)$ mean the largest integer $\le x$ and the smallest integer $\ge x$, as described in § 2 ‘Notation’. ⁵

"ZEC/TAZ" refers to the native currency of Zcash on a given network, i.e. ZEC on Mainnet and TAZ on Testnet.

Let $𝖯𝗈𝗌𝗍𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$ be as defined in ⁶, and $𝖯𝗈𝗌𝗍𝖭𝖴\mathrm{𝟩}𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$ be as defined in ZIP 218. ⁷

$𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸$, as defined in § 5.3 ‘Constants’ ⁸, is the total ZEC/TAZ supply cap measured in zatoshi, corresponding to 21,000,000 ZEC. This is slightly larger than the supply cap for the current issuance mechanism, but is the value used in existing critical consensus checks.

"Issued Supply" - The Issued Supply at a given height of a block chain is the total ZEC/TAZ value in all chain value pool balances at that height, as calculated by $𝖨𝗌𝗌𝗎𝖾𝖽𝖲𝗎𝗉𝗉𝗅𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$ defined in § 4.17 ‘Chain Value Pool Balances’. ⁹

"Scheduled Block Subsidy" - The block subsidy given by the existing halving schedule, i.e. $𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$ as defined in § 7.8 ‘Calculating Block Subsidy, Funding Streams, Lockbox Disbursement, and Founders' Reward’ ¹⁰ prior to this ZIP, renamed $𝖲𝖼𝗁𝖾𝖽𝗎𝗅𝖾𝖽𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$ in the Specification below.

"NSM Value Balance" - The total ZEC/TAZ that has been removed from circulation and not yet reissued: funds removed via a registered mechanism, plus block subsidy and fees left unclaimed by coinbase transactions prior to NU6 ¹¹. It is not part of the Issued Supply. $𝖭𝖲𝖬𝖵𝖺𝗅𝗎𝖾𝖡𝖺𝗅𝖺𝗇𝖼𝖾(𝗁𝖾𝗂𝗀𝗁𝗍)$ is defined in the Specification below.

#Abstract

This ZIP proposes a change to how nodes calculate the block subsidy.

The step function around the 4-year halving intervals inherited from Bitcoin is retained unchanged. In addition, from the NSM reissuance height onward, each block issues a fixed portion of the current NSM Value Balance (the ZEC/TAZ that has been removed from circulation or left unclaimed), so that such funds are reissued along a smooth curve on top of the existing schedule.

The new issuance scheme is identical to the existing schedule whenever the NSM Value Balance is zero. Total issuance never exceeds the existing supply cap (which is below $𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸$), but falls slightly short of it, because the NSM does not reissue the shortfall that the rounding of the post-NU7 block subsidy introduces ¹². Because the balance is seeded at NU7 with historical unclaimed value, it is positive at activation even if no funds are removed by a deployed removal mechanism. This ZIP is proposed as an alternative to ZIP 234 ¹³, from which its structure and much of its text are adapted.

#Motivation

The current block reward halving schedule is fixed and does not provide a way to “recycle” funds removed from circulation (for example via ZIP 235 or ZIP 233) into future issuance. Once scheduled issuance ends, the network becomes reliant on transaction fees for the security budget.

Key Objectives:

1. We want to introduce an automated mechanism that allows users of the network to contribute to the long-term sustainability of the network.
2. We want to enable ZEC that has been removed from circulation to be reissued in the future to benefit network sustainability.
3. We want to retain the existing ZEC supply cap of 21 million, as an upper bound on issuance.
4. We want the issuance rate to remain identical to the historical rate for Zcash (and before that, Bitcoin), including the 4-year halving structure, whenever the NSM Value Balance is zero.
5. We want issuance to be easy for all network users to understand and predict.
6. We want to preserve Zcash's existing 4-year halving schedule.

This ZIP is an alternative to ZIP 234 ¹³ that differs only in Key Objective 6. ZIP 234 replaces the halving schedule with a smooth curve in order to reissue funds removed from circulation; this ZIP shows that reissuance does not require that change. The halving schedule is a long-standing, widely understood property of Zcash on which block subsidy recipients and the wider community rely, and this ZIP allows the question of whether to change it to be decided on its own merits.

This NSM-based issuance scheme preserves the core aspects of Zcash's issuance policy, the halving schedule, and the 21-million-coin cap. Critically, it establishes the intended path for ZEC that has been voluntarily removed from circulation, as well as transaction fees that are deliberately redirected into the reserve: these funds are automatically and algorithmically reissued over future block subsidies, ensuring they benefit the network's long-term security.

#Privacy Implications

The NSM Value Balance and additional block subsidy are calculated from already-public values: the initial balance, amounts removed from circulation, and prior reissuance. These calculations disclose no additional transaction information.

#Requirements

Reissuing funds removed from circulation while preserving halvings is possible using an exponential decay formula applied to the NSM Value Balance that satisfies the following requirements:

1. The issuance can be summarized into a reasonably simple explanation.
2. If the NSM Value Balance is zero, block subsidies are identical to the existing halving schedule.
3. From $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$ onward, if the NSM Value Balance is greater than 0, then the additional block subsidy must be non-zero, so that funds removed from circulation are eventually fully reissued.
4. For any halving period, the additional block subsidies paid out are approximately equal to half of the NSM Value Balance at the beginning of that period, if no ZEC/TAZ is removed from circulation during it.
5. Decrease the short-term impact of the deployment of this ZIP on block subsidy recipients, and minimize the potential reputation risk to Zcash of changing the block subsidy amount.

#Specification

#Mechanisms for removal from circulation

The following mechanisms for removal from circulation are part of the consensus rules as of NU7 ¹⁴:

Mechanism	Source	Defining ZIP
Transaction fees	$𝖭𝖲𝖬𝖥𝖾𝖾𝖢𝗈𝗇𝗍𝗋𝗂𝖻𝗎𝗍𝗂𝗈𝗇(𝗁𝖾𝗂𝗀𝗁𝗍)$	ZIP 235 15

Additional mechanisms for removal from circulation MAY be added to this list via modifications to this ZIP specified in other ZIPs. Such modifications MUST specify their source as a function solely dependent on height.

Let $𝖭𝖲𝖬𝖵𝖺𝗅𝗎𝖾𝖱𝖾𝗆𝗈𝗏𝖾𝖽(𝗁𝖾𝗂𝗀𝗁𝗍⦂\mathbb{N})$ be the total value removed from circulation in the block at $𝗁𝖾𝗂𝗀𝗁𝗍$. It is the sum of all values in the "Source" column above.

#Parameters

$𝖫𝖭\mathrm{𝟤}\_𝖲𝖢𝖠𝖫𝖤𝖣⦂\mathbb{N}:=6\_931\_680\_000$

$𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅(𝗁𝖾𝗂𝗀𝗁𝗍⦂\mathbb{N}):=$ the number of blocks in a halving period at $𝗁𝖾𝗂𝗀𝗁𝗍$: $𝖯𝗈𝗌𝗍𝖭𝖴\mathrm{𝟩}𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$ if $𝖨𝗌𝖭𝖴\mathrm{𝟩}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝖾𝖽(𝗁𝖾𝗂𝗀𝗁𝗍)$ as defined in ZIP 218 ⁷, otherwise $𝖯𝗈𝗌𝗍𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$.

$𝖡𝖫𝖮𝖢𝖪\_𝖲𝖴𝖡𝖲𝖨𝖣𝖸\_𝖥𝖱𝖠𝖢𝖳𝖨𝖮𝖭(𝗁𝖾𝗂𝗀𝗁𝗍⦂\mathbb{N}):=𝖿𝗅𝗈𝗈𝗋(𝖫𝖭\mathrm{𝟤}\_𝖲𝖢𝖠𝖫𝖤𝖣/𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅(𝗁𝖾𝗂𝗀𝗁𝗍))/10\_000\_000\_000$

This is $4126/10\_000\_000\_000=0.0000004126$ with $𝖯𝗈𝗌𝗍𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅=1\_680\_000$, the value specified by ZIP 234 ¹³, and $1375/10\_000\_000\_000$ with $𝖯𝗈𝗌𝗍𝖭𝖴\mathrm{𝟩}𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅=5\_040\_000$. Since $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$ is not before NU7 activation, only the latter value is used by $𝖠𝖽𝖽𝗂𝗍𝗂𝗈𝗇𝖺𝗅𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒$. See the BLOCK_SUBSIDY_FRACTION section below.

$𝖨𝖭𝖨𝖳𝖨𝖠𝖫\_𝖭𝖲𝖬\_𝖵𝖠𝖫𝖴𝖤\_𝖡𝖠𝖫𝖠𝖭𝖢𝖤⦂\{0..𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸\}:=$ the block subsidy and fees left unclaimed by coinbase transactions before NU6, in zatoshi, which seeds the NSM Value Balance at NU7 activation. Since ZIP 236 ¹¹ requires coinbase transactions to claim their full value, this is the fixed amount

${\sum }_{𝗁=0}^{𝖧}𝖲𝖼𝗁𝖾𝖽𝗎𝗅𝖾𝖽𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁)-𝖨𝗌𝗌𝗎𝖾𝖽𝖲𝗎𝗉𝗉𝗅𝗒(𝖧)$

for any $𝖧$ from the last pre-NU6 height up to $𝖭𝖴\mathrm{𝟩}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍-1$. The network-specific values are:

Network	Last pre-NU6 height $𝖧$	$𝖨𝖭𝖨𝖳𝖨𝖠𝖫\_𝖭𝖲𝖬\_𝖵𝖠𝖫𝖴𝖤\_𝖡𝖠𝖫𝖠𝖭𝖢𝖤$ (zatoshi)
Mainnet	2,726,399	36,858,445,520 (368.58445520 ZEC)
Testnet	2,975,999	55,768,414,957 (557.68414957 TAZ)

These values are derived as follows, in zatoshi. The scheduled issuance is calculated from § 7.8; $𝖨𝗌𝗌𝗎𝖾𝖽𝖲𝗎𝗉𝗉𝗅𝗒(𝖧)$ is the sum of the transparent, Sprout, Sapling and Orchard chain value pool balances at $𝖧$ (the deferred development fund and Ironwood chain value pool balances are zero at $𝖧$), which can be checked against the chain value pool balances that a full node reports at that height.

Network	${\sum }_{𝗁=0}^{𝖧}𝖲𝖼𝗁𝖾𝖽𝗎𝗅𝖾𝖽𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁)$	$𝖨𝗌𝗌𝗎𝖾𝖽𝖲𝗎𝗉𝗉𝗅𝗒(𝖧)$
Mainnet	1,575,000,000,000,000	1,574,963,141,554,480
Testnet	1,603,125,000,000,000	1,603,069,231,585,043

$𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳⦂\mathbb{N}:=$ the height at which reissuance begins on the relevant network, calculated in NSM reissuance height below. It is named $𝖭𝖲𝖬\_𝖱𝖤𝖨𝖲𝖲𝖴𝖠𝖭𝖢𝖤\_𝖧𝖤𝖨𝖦𝖧𝖳$ in the NU7 deployment ZIP ¹⁴.

#NSM reissuance height

The reissuance height is determined from the scheduled issuance curve and a reference reserve of $𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸-S_A(h-1)$, without accounting for amounts removed from circulation or the positive historical seed. This makes it independent of transaction activity and the actual NSM Value Balance.

For each network, let $A=𝖭𝖴\mathrm{𝟩}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$ and let $B_A(h)$ be $𝖲𝖼𝗁𝖾𝖽𝗎𝗅𝖾𝖽𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(h)$ after applying ZIP 218 ⁷ at $A$. Let $S_A(h)={\sum }_{i=0}^h{B}_A(i)$ be cumulative scheduled issuance through height $h$, excluding additional NSM subsidies and amounts removed from circulation. Let $H_3$ and $H_4$ be the first heights at which the ZIP 218 $𝖧𝖺𝗅𝗏𝗂𝗇𝗀$ function equals 3 and 4, respectively.

$𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$ SHALL be the first height $h$ with $\max (A,H_3+1)\le h<H_4$ for which

$𝖼𝖾𝗂𝗅𝗂𝗇𝗀\left(\frac{1375(𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸-S_A(h-1))}{{10}^{10}}\right)<B_A(h).$

Here 1375 is the numerator of $𝖡𝖫𝖮𝖢𝖪\_𝖲𝖴𝖡𝖲𝖨𝖣𝖸\_𝖥𝖱𝖠𝖢𝖳𝖨𝖮𝖭$ after NU7 activation. The strict inequality selects the first block where the rounded reference NSM subsidy is below the scheduled block subsidy. The ceiling is the same rounding rule used for $𝖠𝖽𝖽𝗂𝗍𝗂𝗈𝗇𝖺𝗅𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒$; the reference balance $𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸-S_A(h-1)$ is used only to select the deployment height. NU7 activation heights SHALL be chosen so that this height exists before $H_4$. The NU7 deployment ZIP ¹⁴ specifies the resulting height for each network.

The value can be calculated without testing every block. Set $h_0=\max (A,H_3+1)$, $b=B_A(h_0)$, $R_0=𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸-S_A(h_0-1)$, and $R_{\max }=𝖿𝗅𝗈𝗈𝗋((b-1)\cdot {10}^{10}/1375)$. Since $b$ is constant before $H_4$, the first qualifying height is

$h_0+𝖼𝖾𝗂𝗅𝗂𝗇𝗀\left(\frac{\max (0,R_0-R_{\max })}{b}\right).$

For the expected case in which $A$ lies between the second and third pre-NU7 halvings, the ZIP 218 third halving occurs at $H_3=A+3(H_3^{(75)}-A)$, where $H_3^{(75)}$ is 4,406,400 on Mainnet and 4,476,000 on Testnet. Let $H_2^{(75)}$ be the corresponding second halving height in the table below. In this range, $b=\mathrm{26,041,666}$, $R_{\max }=\mathrm{189,393,927,272,727}$, and $R_0=\mathrm{262,499,975,638,334}-(A-H_2^{(75)})$ zatoshi. Consequently $𝖼𝖾𝗂𝗅𝗂𝗇𝗀((R_0-R_{\max })/b)=\mathrm{2,807,273}$ throughout the range. Including the one-block offset from $H_3$ to $h_0$ gives $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳=H_3+\mathrm{2,807,274}$:

Network	Second halving	Third halving after NU7	Reissuance height
Mainnet	2,726,400	$\mathrm{13,219,200}-2A$	$\mathrm{16,026,474}-2A$
Testnet	2,796,000	$\mathrm{13,428,000}-2A$	$\mathrm{16,235,274}-2A$

For example, the Mainnet activation height $A=\mathrm{3,543,405}$ ¹⁴ gives a third halving at 6,132,390 and a reissuance height of 8,939,664. At height 8,939,663 the rounded reference subsidy is 26,041,667 zatoshi, above the scheduled 26,041,666; at 8,939,664 it is 26,041,663, below it.

#Changes to the Zcash Protocol Specification

In § 7.8 ‘Calculating Block Subsidy, Funding Streams, Lockbox Disbursement, and Founders' Reward’ ¹⁰:

Apply the changes of ZIP 218 ⁷ first. Then rename the resulting function $𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$ to $𝖲𝖼𝗁𝖾𝖽𝗎𝗅𝖾𝖽𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$, leaving its definition unchanged.

Add the following definition, where $𝖭𝖲𝖬𝖵𝖺𝗅𝗎𝖾𝖡𝖺𝗅𝖺𝗇𝖼𝖾$ is as defined in § 4.17 ‘Chain Value Pool Balances’ ⁹ below:

0, & \text{if } \mathsf{height} < \mathsf{DEPLOYMENT\_BLOCK\_HEIGHT} \\ \mathsf{ceiling}(\mathsf{BLOCK\_SUBSIDY\_FRACTION}(\mathsf{height}) \cdot \mathsf{NSMValueBalance}(\mathsf{height} - 1)), & \text{otherwise} \end{cases} ParseError: Expected 'EOF', got '&' at position 4: 0, &̲ \text{if } \ma…

Define $𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$ as:

$𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍):=𝖲𝖼𝗁𝖾𝖽𝗎𝗅𝖾𝖽𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)+𝖠𝖽𝖽𝗂𝗍𝗂𝗈𝗇𝖺𝗅𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$

Add $𝖫𝖭\mathrm{𝟤}\_𝖲𝖢𝖠𝖫𝖤𝖣$ and $𝖨𝖭𝖨𝖳𝖨𝖠𝖫\_𝖭𝖲𝖬\_𝖵𝖠𝖫𝖴𝖤\_𝖡𝖠𝖫𝖠𝖭𝖢𝖤$ to § 5.3 ‘Constants’ ⁸, and $𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$ and $𝖡𝖫𝖮𝖢𝖪\_𝖲𝖴𝖡𝖲𝖨𝖣𝖸\_𝖥𝖱𝖠𝖢𝖳𝖨𝖮𝖭$, as given under Parameters above, to § 7.8.

All other uses of $𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$ in the protocol specification ($𝖥𝗈𝗎𝗇𝖽𝖾𝗋𝗌𝖱𝖾𝗐𝖺𝗋𝖽$, $𝖿𝗌𝖵𝖺𝗅𝗎𝖾$ and hence $𝗍𝗈𝗍𝖺𝗅𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽𝖮𝗎𝗍𝗉𝗎𝗍$, $𝖬𝗂𝗇𝖾𝗋𝖲𝗎𝖻𝗌𝗂𝖽𝗒$, and the total input value of a coinbase transaction in § 7.1.2 ¹⁶) are unchanged and refer to the redefined function; in particular, funding streams receive their fixed percentage of the total (scheduled plus additional) block subsidy. Note that $𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$ now depends on the NSM Value Balance after block $𝗁𝖾𝗂𝗀𝗁𝗍-1$, and not only on $𝗁𝖾𝗂𝗀𝗁𝗍$.

In § 4.17 ‘Chain Value Pool Balances’ ⁹, add the following definition. Let $𝖭𝖴\mathrm{𝟩}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$ be the NU7 activation height on the relevant network. ¹⁴

0, & \text{if } \mathsf{height} < \mathsf{NU7ActivationHeight} - 1 \\ \mathsf{INITIAL\_NSM\_VALUE\_BALANCE}, & \text{if } \mathsf{height} = \mathsf{NU7ActivationHeight} - 1 \\ \mathsf{NSMValueBalance}(\mathsf{height} - 1) - \mathsf{AdditionalBlockSubsidy}(\mathsf{height}) + \mathsf{NSMValueRemoved}(\mathsf{height}), & \text{otherwise} \end{cases} ParseError: Expected 'EOF', got '&' at position 4: 0, &̲ \text{if } \ma…

The NSM Value Balance is tracked as consensus state alongside the chain value pools. It is not a spendable chain value pool and is not included in $𝖨𝗌𝗌𝗎𝖾𝖽𝖲𝗎𝗉𝗉𝗅𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$: it counts ZEC/TAZ that is not in circulation, consistent with ZIP 233 ¹⁷, which subtracts removed funds from the issued supply. Reissuance moves value from the NSM Value Balance into the Issued Supply through the block subsidy.

Add the consensus rule:

[NU7 onward] If $𝖭𝖲𝖬𝖵𝖺𝗅𝗎𝖾𝖡𝖺𝗅𝖺𝗇𝖼𝖾(𝗁𝖾𝗂𝗀𝗁𝗍)$ would become negative in the block chain created as a result of accepting a block at $𝗁𝖾𝗂𝗀𝗁𝗍$, then all nodes MUST reject the block as invalid.

In § 3.10 ‘Block Subsidy, Funding Streams, and Founders' Reward’ ¹⁸, add:

[NU7 onward] From $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$, the block subsidy also includes value reissued from the NSM Value Balance (§ 4.17), and so depends on the NSM Value Balance after the preceding block as well as on the block height.

In § 3.4 ‘Transactions and Treestates’ ¹⁹, where the remaining value in the transparent transaction value pool of coinbase transactions in blocks prior to NU6 is said to be destroyed, say instead that it is left unclaimed and is not added to any chain value pool, and add:

[NU7 onward] This value is included in $𝖨𝖭𝖨𝖳𝖨𝖠𝖫\_𝖭𝖲𝖬\_𝖵𝖠𝖫𝖴𝖤\_𝖡𝖠𝖫𝖠𝖭𝖢𝖤$, and so is reissued as specified in § 7.8.

#Applicability

All of these changes apply identically to Mainnet and Testnet.

#Rationale

• Leaving the existing schedule in place and applying an exponential decay function only to the NSM Value Balance satisfies Requirements 1, 2 and 4 above.
• No reissuance occurs between NU7 activation and $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$, so the NSM Value Balance accumulates during that interval. The reissuance height is chosen as described in NSM reissuance height and ZIP 259 ¹⁴.
• We round up to the next zatoshi to satisfy Requirement 3 above from $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$ onward. Since $𝖡𝖫𝖮𝖢𝖪\_𝖲𝖴𝖡𝖲𝖨𝖣𝖸\_𝖥𝖱𝖠𝖢𝖳𝖨𝖮𝖭<1$ and the NSM Value Balance is a non-negative integer number of zatoshi, the additional subsidy never exceeds the balance it is calculated from, so from NU7 activation the sum of the Issued Supply and the NSM Value Balance changes by exactly the Scheduled Block Subsidy each block. Issuance therefore never exceeds the supply cap. The change in NU7 reduces the current cap by about 0.50 ZEC on Mainnet (to about 0.68 ZEC below $𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸$), because ZIP 218's rounding lowers the Scheduled Block Subsidy and the NSM does not reissue that shortfall ¹².
• By the previous point the NSM Value Balance can never become negative unless an implementation is in error. The consensus rule above makes such an error a block-validity failure rather than silently clamping the value.
• The issuance formula depends only on $𝖭𝖲𝖬𝖵𝖺𝗅𝗎𝖾𝖡𝖺𝗅𝖺𝗇𝖼𝖾(𝗁𝖾𝗂𝗀𝗁𝗍-1)$ and a single fraction, making it simple to implement, explain, and verify.

#Rationale for Parameters

Because the formula reduces to the existing schedule whenever the NSM Value Balance is zero, the rule itself places no constraint on the deployment height. The only change at deployment is the reissuance of the NSM Value Balance at that point ($𝖨𝖭𝖨𝖳𝖨𝖠𝖫\_𝖭𝖲𝖬\_𝖵𝖠𝖫𝖴𝖤\_𝖡𝖠𝖫𝖠𝖭𝖢𝖤$ plus anything removed from circulation since NU7 activation) at $𝖡𝖫𝖮𝖢𝖪\_𝖲𝖴𝖡𝖲𝖨𝖣𝖸\_𝖥𝖱𝖠𝖢𝖳𝖨𝖮𝖭$ per block. For example, if a total of 100,000 ZEC were removed from circulation between NU7 activation and $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$, then at $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$ the issuance would be larger than the Scheduled Block Subsidy by $100\_000\text{ 𝖹𝖤𝖢}\cdot 𝖡𝖫𝖮𝖢𝖪\_𝖲𝖴𝖡𝖲𝖨𝖣𝖸\_𝖥𝖱𝖠𝖢𝖳𝖨𝖮𝖭$, which equals $0.01375$ ZEC under the post-NU7 schedule. This example is chosen to demonstrate that a very large amount removed from circulation (much larger than expected) would elevate issuance by a relatively small amount, satisfying Requirement 5.

Since NU6, coinbase transactions are required to claim the full miner subsidy and fees ¹¹, so the part of the NSM Value Balance not attributable to funds removed from circulation is a fixed historical amount, $𝖨𝖭𝖨𝖳𝖨𝖠𝖫\_𝖭𝖲𝖬\_𝖵𝖠𝖫𝖴𝖤\_𝖡𝖠𝖫𝖠𝖭𝖢𝖤$: on Mainnet 368.58445520 ZEC, reissued from deployment at an initial rate of about 0.00005 ZEC per block under ZIP 218.

#BLOCK_SUBSIDY_FRACTION

Let $𝖨𝗇𝗍𝖾𝗇𝖽𝖾𝖽𝖥𝗋𝖺𝖼𝗍𝗂𝗈𝗇𝖱𝖾𝗆𝖺𝗂𝗇𝗂𝗇𝗀𝖠𝖿𝗍𝖾𝗋𝖮𝗇𝖾𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖯𝖾𝗋𝗂𝗈𝖽=0.5$, i.e. the NSM Value Balance should halve over the same period as the block subsidy does. The fraction is therefore stated as a function of the halving schedule rather than as a constant, so that it keeps this property whatever the block target spacing:

${(1-𝖡𝖫𝖮𝖢𝖪\_𝖲𝖴𝖡𝖲𝖨𝖣𝖸\_𝖥𝖱𝖠𝖢𝖳𝖨𝖮𝖭(𝗁𝖾𝗂𝗀𝗁𝗍))}^{𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅(𝗁𝖾𝗂𝗀𝗁𝗍)}\approx 𝖨𝗇𝗍𝖾𝗇𝖽𝖾𝖽𝖥𝗋𝖺𝖼𝗍𝗂𝗈𝗇𝖱𝖾𝗆𝖺𝗂𝗇𝗂𝗇𝗀𝖠𝖿𝗍𝖾𝗋𝖮𝗇𝖾𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖯𝖾𝗋𝗂𝗈𝖽$

Solving gives a fraction of approximately $\ln 2/𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅(𝗁𝖾𝗂𝗀𝗁𝗍)$. $𝖫𝖭\mathrm{𝟤}\_𝖲𝖢𝖠𝖫𝖤𝖣$ is ${10}^{10}\cdot \ln 2\approx 6\_931\_471\_805.6$ rounded up to a multiple of $𝖯𝗈𝗌𝗍𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$, so that on the 75-second schedule the numerator is exactly the 4126 of ZIP 234 ¹³, which satisfies the approximation within $\pm 0.003\%$. ZIP 218 ⁷ does not change $𝖯𝗈𝗌𝗍𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$; it defines a separate $𝖯𝗈𝗌𝗍𝖭𝖴\mathrm{𝟩}𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅=5\_040\_000$ for its 25-second blocks, and with that interval the numerator is 1375, which is the value applied from $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$: ${(1-1375/{10}^{10})}^{5\_040\_000}\approx 0.50007$, within $+0.015\%$. A numerator fixed at 4126 would instead halve the balance about every 1.33 years under ZIP 218, because it would apply three times as often.

Without rounding, this implies that after one halving period approximately half of the NSM Value Balance would have been issued as additional block subsidies. Rounding each subsidy up to a zatoshi increases the amount issued by less than one zatoshi per block relative to that curve. The approximation is therefore close for large balances, but not for small ones: a balance of 1 zatoshi is issued in the next block rather than halving over a halving period. More generally, once the rounded additional subsidy is 1 zatoshi, one zatoshi is issued per block until the balance reaches zero.

The largest possible value of the NSM Value Balance is less than $𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸$, in the theoretically possible case that all issued funds are removed from circulation. If this happened, the largest interim product in the block subsidy calculation would be less than $𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸\cdot 1375$ under ZIP 218 ⁷.

This uses at most 61.33 bits, below the 63-bit limit for signed two's complement 64-bit integer amount types.

The numerator could be brought closer to the limit by using a larger denominator, but the difference in the amount issued would be very small. So we chose a power-of-10 denominator for simplicity.

#Appendix: Considerations for the Future

Future protocol changes may not increase the payout rate of the NSM Value Balance to a reasonable approximation beyond the one-halving-period half-life constraint.

#Deployment

This ZIP is proposed to activate with Network Upgrade 7 ¹⁴, with reissuance beginning at $𝖣𝖤𝖯𝖫𝖮𝖸𝖬𝖤𝖭𝖳\_𝖡𝖫𝖮𝖢𝖪\_𝖧𝖤𝖨𝖦𝖧𝖳$. It MUST NOT be deployed together with ZIP 234. ¹³ It does not depend on ZIP 233 ("NSM: Removing Funds From Circulation" ¹⁷): funds removed from circulation by ZIP 233, or by any other mechanism, are credited to the NSM Value Balance if and when that mechanism is deployed. This ZIP requires ZIP 218. ⁷

#Reference implementation

• Zebra: ^{20 21 22}
• Zakura: TBD

#References

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

2. ZIP 200: Network Upgrade Mechanism ↩

3. Zcash Protocol Specification, Version 2026.8.0 [NU6.3] or later ↩

4. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.12: Mainnet and Testnet ↩

5. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 2: Notation ↩

6. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.7.3: Difficulty Adjustment ↩

7. ZIP 218: 25-second Block Target Spacing ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

8. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.3: Constants ↩ ↩²

9. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 4.17: Chain Value Pool Balances ↩ ↩² ↩³

10. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.8: Calculating Block Subsidy, Funding Streams, Lockbox Disbursement, and Founders' Reward ↩ ↩²

11. ZIP 236: Blocks should balance exactly ↩ ↩² ↩³

12. ZIP 218: 25-second Block Target Spacing — Rationale for altering the issuance curve ↩ ↩²

13. ZIP 234: Network Sustainability Mechanism: Issuance Smoothing ↩ ↩² ↩³ ↩⁴ ↩⁵

14. ZIP 259: Deployment of the NU7 Network Upgrade ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

15. ZIP 235: Remove 60% of Transaction Fees From Circulation ↩

16. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.1.2: Transaction Consensus Rules ↩

17. ZIP 233: Network Sustainability Mechanism: Removing Funds From Circulation ↩ ↩²

18. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward ↩

19. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.4: Transactions and Treestates ↩

20. Zebra PR 11454: feat(chain, consensus, state, rpc): add halving-preserving NU7 issuance ↩

21. Zebra PR 11529: feat(consensus)!: implement NU7 spacing, funding schedules, and shielded limits ↩

22. Zebra PR 11530: feat(nsm)!: enable merged issuance and fee accounting ↩