# ZIP 234: Network Sustainability Mechanism: Issuance Smoothing
Status: Draft
Owners: Jason McGee, Zooko Wilcox, Mark Henderson, Tomek Piotrowski, Mariusz Pilarek, Paul Dann
Snapshot: a34cfc091434275120ff017c92c3b50d3cef623a
Source date: 2026-10-16T02:56:04+01:00
[Source revision](https://github.com/zcash/zips/commit/a34cfc091434275120ff017c92c3b50d3cef623a)
[Official source](https://zips.z.cash/zip-0234) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-0234.md) · [Discussion](https://github.com/zcash/zips/issues/923)
Preamble
**ZIP**: 234
**Title**: Network Sustainability Mechanism: Issuance Smoothing
**Owners**:
- [Jason McGee](mailto:jason@shieldedlabs.net)
- [Zooko Wilcox](mailto:zooko@shieldedlabs.net)
- [Mark Henderson](mailto:mark@shieldedlabs.net)
- [Tomek Piotrowski](mailto:tomek@eiger.co)
- [Mariusz Pilarek](mailto:mariusz@eiger.co)
- [Paul Dann](mailto:paul@eiger.co)
**Original-Authors**: Nathan Wilcox
**Status**: Draft
**Category**: Consensus
**Created**: 2023-08-23
**License**: BSD-2-Clause
**Discussions-To**: [https://github.com/zcash/zips/issues/923](https://github.com/zcash/zips/issues/923)
## Terminology
The key word "MUST" in this document is to be interpreted as described in
BCP 14
[1](#user-content-fn-bcp14) when, and only when, it appears in all capitals.
The term "network upgrade" in this document is to be interpreted as described
in ZIP 200.
[2](#user-content-fn-zip-0200)
The character § is used when referring to sections of the Zcash Protocol
Specification.
[3](#user-content-fn-protocol)
The terms "Mainnet" and "Testnet" are to be interpreted as described in
§ 3.12 ‘Mainnet and Testnet’.
[4](#user-content-fn-protocol-networks)
The symbol "$\,\cdot\,$" means multiplication, as described in § 2 ‘Notation’.
[5](#user-content-fn-protocol-notation)
"ZEC/TAZ" refers to the native currency of Zcash on a given network, i.e.
ZEC on Mainnet and TAZ on Testnet.
The terms "Block Subsidy" and "Issuance" are to be interpreted as described in
ZIP 233.
[6](#user-content-fn-zip-0233)
Let $\mathsf{PostBlossomHalvingInterval}$ be as defined in
[7](#user-content-fn-protocol-diffadjustment).
$\mathsf{MAX\_MONEY}$, as defined in § 5.3 ‘Constants’
[8](#user-content-fn-protocol-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 $\mathsf{IssuedSupply}(\mathsf{height})$ defined in
§ 4.17 ‘Chain Value Pool Balances’.
[9](#user-content-fn-protocol-chainvaluepoolbalances)
"Money Reserve" - The Money Reserve at a given height of a block chain is
the total ZEC/TAZ value remaining to be issued, as calculated by
$\mathsf{MAX\_MONEY} - \mathsf{IssuedSupply}(\mathsf{height})$.
## Abstract
This ZIP proposes a change to how nodes calculate the block subsidy.
Instead of following a step function around the 4-year halving intervals
inherited from Bitcoin, we propose a smooth logarithmic curve, defined as a
fixed portion of the current value of the Money Reserve at a given block height.
The new issuance scheme would approximate the current issuance over 4-year
intervals, assuming no ZEC/TAZ is removed from circulation during that time, and
retains the overall supply cap of `MAX_MONEY`.
## Motivation
The current block reward halving schedule is fixed and does not provide a way
to “recycle” funds removed from circulation via 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.
4. We want the issuance rate to remain similar to the historical rate for Zcash
(and before that, Bitcoin).
5. We want issuance to be easy for all network users to understand and predict.
6. We want the new issuance to activate at a block with as minimal a delta from
the current issuance as possible.
The current Zcash economic model, inherited from Bitcoin, includes a halving
mechanism that dictates the issuance of new coins via the mining block reward.
Halvings have since become culturally foundational, but abrupt reductions in
miner revenue can lead to short-term drops in mining participation, as evidenced
by hashrate/difficulty.
In Zcash, difficulty declined materially after recent halving events: following the
2020-11-18 halving, weekly difficulty fell about 20.6% within roughly a week and was
still about 9.1% lower around 30 days later. Following the 2024-11-23 halving,
weekly difficulty fell about 17% within roughly a week and about 23% around 30 days
later.
[10](#user-content-fn-zechub-difficulty) As difficulty adjusts in response to hashrate, these short-term
drops are consistent with discrete subsidy cuts producing measurable reductions in mining
participation.
While Bitcoin halvings are often accompanied by bullish narratives and have
sometimes been followed by strong price performance, Zcash has not consistently
followed the same pattern. Thus, by smoothing out the issuance curve, we
mitigate the risks associated with abrupt changes in issuance rates.
This new NSM-based issuance scheme addresses these problems by ensuring a more
consistent and predictable rate of coin issuance, while preserving the core
aspects of Zcash's issuance policy 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.
## Requirements
Smoothing the issuance curve is possible using an exponential decay formula
that satisfies the following requirements:
1. The issuance can be summarized into a reasonably simple explanation.
2. Block subsidies approximate a continuous function.
3. If the Money Reserve is greater than 0, then the block subsidy must be
non-zero, preventing any final "unmined" zatoshis.
4. For any 4-year period, all paid out block subsidies are approximately equal
to half of the Money Reserve at the beginning of that 4-year period, if no
ZEC is removed from circulation during those 4 years.
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.
6. The immediate change in issuance when this mechanism activates should be
minimal.
## Specification
### Parameters
$\mathsf{BLOCK\_SUBSIDY\_FRACTION} = 4126 / 10\_000\_000\_000 = 0.0000004126$
$\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT} = \mathsf{TBD}$
$\mathsf{MoneyReserveAfter}(\mathsf{height}) =$ The value of the Money Reserve
after the specified block height.
The block height will be chosen by the following criteria:
- It is after NU7 activation height.
- It is calculated to be the lowest height after the second halving at which
the NSM issuance would be less than the current BTC-style issuance *neglecting*
any ZEC removed from circulation (i.e. assuming the amount of ZEC removed from
circulation is exactly 0).
### Issuance Calculation
At the $\mathsf{DEPLOYMENT\_BLOCK\_HEIGHT}$, nodes MUST switch from the current issuance
calculation, to the following:
$\mathsf{BlockSubsidy}(\mathsf{height}) = \mathsf{ceiling}(\mathsf{BLOCK\_SUBSIDY\_FRACTION} \cdot \mathsf{MoneyReserveAfter}(\mathsf{height} - 1))$
### Applicability
All of these changes apply identically to Mainnet and Testnet.
## Rationale
- Using an exponential decay function satisfies **Requirements 1** and **2** above.
- We round up to the next zatoshi to satisfy **Requirement 3** above.
- The issuance formula depends only on `MoneyReserveAfter(height - 1)` and a
single constant fraction, making it simple to implement, explain, and verify.
### Parameters
The selection is intended to achieve Key Objective 6 while still being at
a constant, predictable height. An alternative would be to have a dynamic
"latch"-style activation, which would calculate the activation height by
testing the "less than" conditional with every block after the second halving.
We prefer the pre-defined constant height parameter, to give everyone more
*time* certainty at the cost of *issuance level* certainty.
The difference in up-front calculation versus dynamic calculation is
in whether or not funds removed from circulation are accounted for
(since funds removed from circulation in the future cannot be calculated
up-front). This means with the pre-defined constant parameter approach,
issuance will jump *up* some amount at activation. This amount should be
equivalent to all ZEC removed from circulation prior to that height times
$\mathsf{BLOCK\_SUBSIDY\_FRACTION}$. For example, if a total of 100,000 ZEC
were removed from circulation prior to the pre-defined constant activation
height, then at activation the issuance would be larger than BTC-style
issuance by $100\_000\textsf{ ZEC} \cdot \mathsf{BLOCK\_SUBSIDY\_FRACTION}$,
which we calculate equals $0.04126$ ZEC. 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. For this
reason, we believe a pre-defined constant is a better approach to achieving
Key Objective 6 than a "dynamic latch" logic because it is so much simpler
to implement and reason about.
### BLOCK_SUBSIDY_FRACTION
Let $\mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears} = 0.5$.
The value $4126 / 10\_000\_000\_000$ satisfies the approximation within $\pm 0.002\%$:
$(1 - \mathsf{BLOCK\_SUBSIDY\_FRACTION})^\mathsf{PostBlossomHalvingInterval} \approx \mathsf{IntendedMoneyReserveFractionRemainingAfterFourYears}$
This implies that after a period of 4 years around half of Money Reserve will
have been issued as block subsidies, thus satisfying **Requirement 4**.
The largest possible value in the Money Reserve is $\mathsf{MAX\_MONEY}$, in the
theoretically possible case that all issued funds are removed from circulation.
If this happened, the largest interim sum in the block subsidy calculation would
be $\mathsf{MAX\_MONEY} \cdot 4126 / 10\_000\_000\_000$.
This uses 62.91 bits, which is just under 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.
TODO for ZIP owners: How many ZEC per day?
### Visualization of the Smoothed Curve
The following graph compares issuance for the current halving-based step
function vs the smoothed curve.
The graph below shows the balance of the Money Reserve assuming smooth issuance
is implemented.
## Appendix: Simulation
The [NSM Simulator](https://github.com/eigerco/zsf-simulator) allows us to
simulate the effects of this ZIP on the Money Reserve and the block subsidy, as
well as generate plots like the ones above. Its output:
```
Last block is 47917869 in ~113.88 years
```
indicates that, assuming that no ZEC is ever removed from circulation, the Money
Reserve will be depleted after 113.88 years, and the block subsidy will be 0 ZEC
after that point.
This fragment of the output:
```
Halving 1 at block 1680000:
NSM subsidies: 262523884819889 (~ 2625238.848 ZEC, 1.563 ZEC per block)
legacy subsidies: 262500000000000 (~ 2625000.000 ZEC, 1.562 ZEC per block)
difference: 23884819889 (~ 238 ZEC), NSM/legacy: 1.0001
```
shows that the difference between the smoothed out and the current issuance
schemes is 238 ZEC after 1680000 blocks (around 4 years).
## Appendix: Considerations for the Future
Future protocol changes may not increase the payout rate to a reasonable
approximation beyond the four year half-life constraint.
## Deployment
This ZIP is not deployed in Network Upgrade 7, which instead deploys ZIP 237
("NSM: Halving-Preserving Issuance"
[11](#user-content-fn-zip-0237)).
[12](#user-content-fn-zip-0259) It MUST be
deployed at the same time or after ZIP 233 ("NSM: Removing Funds From
Circulation"
[6](#user-content-fn-zip-0233)).
## 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"](https://www.rfc-editor.org/info/bcp14) [↩](#user-content-fnref-bcp14)
2. [ZIP 200: Network Upgrade Mechanism](/zip/200) [↩](#user-content-fnref-zip-0200)
3. [Zcash Protocol Specification, Version 2025.6.2 [NU6.1] or later](protocol/protocol.pdf) [↩](#user-content-fnref-protocol)
4. [Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) [↩](#user-content-fnref-protocol-networks)
5. [Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 2: Notation](protocol/protocol.pdf#notation) [↩](#user-content-fnref-protocol-notation)
6. [ZIP 233: Network Sustainability Mechanism: Removing Funds From Circulation](/zip/233) [↩](#user-content-fnref-zip-0233) [↩2](#user-content-fnref-zip-0233-2)
7. [Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 7.7.3 Difficulty Adjustment](protocol/protocol.pdf#diffadjustment) [↩](#user-content-fnref-protocol-diffadjustment)
8. [Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 5.3: Constants](protocol/protocol.pdf#constants) [↩](#user-content-fnref-protocol-constants)
9. [Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 4.17 Chain Value Pool Balances](protocol/protocol.pdf#chainvaluepoolbalances) [↩](#user-content-fnref-protocol-chainvaluepoolbalances)
10. [ZecHub weekly difficulty dataset](https://raw.githubusercontent.com/ZecHub/zechub-wiki/refs/heads/main/public/data/zcash/difficulty.json) [↩](#user-content-fnref-zechub-difficulty)
11. [ZIP 237: Network Sustainability Mechanism: Halving-Preserving Issuance](/zip/237) [↩](#user-content-fnref-zip-0237)
12. [ZIP 259: Deployment of the NU7 Network Upgrade](/zip/259) [↩](#user-content-fnref-zip-0259)
## Citation relationships
Cites: [ZIP 200](https://zip-tools-web.harpocrates.workers.dev/zip/200), [ZIP 233](https://zip-tools-web.harpocrates.workers.dev/zip/233), [ZIP 237](https://zip-tools-web.harpocrates.workers.dev/zip/237), [ZIP 259](https://zip-tools-web.harpocrates.workers.dev/zip/259)
Cited by: [ZIP 233](https://zip-tools-web.harpocrates.workers.dev/zip/233), [ZIP 237](https://zip-tools-web.harpocrates.workers.dev/zip/237), [ZIP 259](https://zip-tools-web.harpocrates.workers.dev/zip/259)