ZIP: 234
Title: Network Sustainability Mechanism: Issuance Smoothing
Owners: Jason McGee <jason@shieldedlabs.net>
        Zooko Wilcox <zooko@shieldedlabs.net>
        Tomek Piotrowski <tomek@eiger.co>
        Mariusz Pilarek <mariusz@eiger.co>
        Paul Dann <paul@eiger.co>
Original-Authors: Nathan Wilcox
Credits:
Status: Draft
Category: Consensus
Created: 2023-08-23
License: BSD-2-Clause

Terminology

The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, “OPTIONAL”, and “REQUIRED” in this document are to be interpreted as described in RFC 2119. [1]

“Network upgrade” - to be interpreted as described in ZIP 200. [2]

“Block Subsidy” - the algorithmic issuance of ZEC on block creation. Part of the consensus rules. Split between the miner and the Dev Fund. Also known as Block Reward.

“Issuance” - The method by which ZEC becomes available for circulation on the network.

Let PostBlossomHalvingInterval be as defined in [#protocol-diffadjustment]_.

“Money Reserve” - MAX_MONEY - ChainValue, where ChainValue includes all ZEC available on the network, across all value pools.

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 is burned during that time, and retains the overall supply cap of MAX_MONEY.

Motivation

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 burned to be recreated 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. While this has been foundational, halvings can lead to abrupt changes in the rate of new coins being introduced to the market. Such sudden shifts can potentially disrupt the network’s economic model, potentially impacting its security and stability. Furthermore, the halvings schedule is fixed and does not provide any way to “recycle” funds into future issuance.

This new NSM-based issuance scheme solves 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. At the same time, it introduces the first mechanism to recreate and distribute ZEC that has been removed from circulation, as well as unclaimed transaction fees, across future block subsidies.

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 burned during those 4 years
5. Decrease the short-term impact of the deployment of this ZIP on block reward recipients, and minimize the potential reputation risk to Zcash of changing the block reward amount.

TODO daira: add a requirement that makes the initial total issuance match the previous total issuance

Specification

Parameters

BLOCK_SUBSIDY_FRACTION = 4126 / 10,000,000,000 or 0.0000004126

DEPLOYMENT_BLOCK_HEIGHT = TBD

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 the second halving at which the NSM issuance would be less than the current BTC-style issuance neglecting any burnt ZEC (ie. assuming the amount of ZEC burnt is exactly 0).

This selection is intended to achieve Key Objective 6 while still being a constant 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 whether or not burns are accounted for (since future burns 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 burnt prior to that height times BLOCK_SUBSIDY_FRACTION. For example, if a total of 100,000 ZEC were burnt prior to the pre-defined constant activation height, then at activation the issuance would be larger than BTC-style issuance by 100_000 ZEC * BLOCK_SUBSIDY_FRACTION which we calculate equals 0.04126 ZEC. This example is chosen to demonstrate that a very large burn amount (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.

MoneyReserveAfter(block_height) = The value of the Money Reserve after the specified block height.

Issuance Calculation

At the DEPLOYMENT_BLOCK_HEIGHT, nodes should switch from the current issuance calculation, to the following:

BlockSubsidy(block_height) = ceiling(BLOCK_SUBSIDY_FRACTION * MoneyReserveAfter(block_height - 1))

Rationale

• Using an exponential decay function satisfies Requirements 1 and 2 above.
• We round up to the next zatoshi to satisfy Requirement 3 above.

BLOCK_SUBSIDY_FRACTION

Let IntendedMoneyReserveFractionRemainingAfterFourYears = 0.5.

The value 4126 / 10_000_000_000 satisfies the approximation within +0.002%:

(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedMoneyReserveFractionRemainingAfterFourYears

Meaning after a period of 4 years around half of Money Reserve will be issued as block subsidies, thus satisfying Requirement 4.

The largest possible value in the Money Reserve is MAX_MONEY, in the theoretically possible case that all issued funds are burned. If this happened, the largest interim sum in the block subsidy calculation would be MAX_MONEY * 4126 / 10000000000.

This uses 62.91 bits, which is just under the 63 bit limit for 64-bit signed two’s-complement 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.

Deployment

The implementation of this ZIP MUST be deployed at the same time or after the Network Sustainability Mechanism Burning function is deployed (ZIP-0233).

Appendix: Simulation

The NSM 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 burned, 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.

References

[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119

[2] ZIP-200: Network Upgrade Mechanism

[3] ZIP_233: Network Sustainability Mechanism: Burning