NU 7 discussions: NSM

Forum thread to discuss the NSM

Question 2: Network Sustainability Mechanism
ZIP 233
ZIP 234
Shielded Labs NSM Proposal
ECC post about a Zcash Posterity Fund
Forum Topics:
Network Sustainability Mechanism , Coinholder Poll

Importantly this combines two parts:

  • Changing the block issuance from the 4 year halvening model, to a smooth issuance curve
  • Introducing a new “Network Sustainability Mechanism”, which can collect funds from voluntary burns, and potentially other sources (Question 3 / ZIP 235). These funds go to miners under a smooth issuance curve as well.
1 Like

We’ve bundled two very separate things in this proposal. My thoughts is that making a new account to allow voluntary burns + some component of tx fees to long term help secure the network is fantastic.

However, bundling changing the network emissions to be continuous is radical. The prior discussions were also made in a very different situation for Zcash. The motivations of ZIP-234 do not outline why the block reward should be continuous, and instead the requirements + motivations (imo) would lead you to believe that the issuance was kept the same. This as a change is a huge departure from historical ZCash, and Bitcoin. This is should be the slowest moving part of all of ZCash, and anything trying to be money. Any change to it should at minimum be very clear that its changing issuance.

This is the image from ZIP-234 to showcase what is happening. (Blue is current, Red is new)

Removing the halvening also removes the incredibly valuable discrete halvening date that the community can orient around. Changing the block subsidy to be continuous is also a short term increase to emissions, which is short term bad for the network and supply economics.

In contrast, I am in support of the new voluntary burn, and that being distributed to miners along a smooth issuance curve. Its especially nice for this to be smooth, in order to offset the halving structure of block emissions..

If the token holder voting proposal for this remains as bundling both changing the network emissions and the new voluntary system for burns, I will be voting NO, and strongly hope others do. Even if you want the issuance to change, I hope you’d agree we need far more discussion in the community based on the present conditions we are in.

Prior discussions were full of very different factors, years ago. (The meme of what is ZCash, different price and activity levels, a roadmap very clearly set on a POS transition)

3 Likes

Sorry, I got something wrong in the prior post. This was quite discussed, but should not be bundled still. I had missed that discussions did occur in the initial Network Security Model thread. (The links were ZCash Posterity Fund, and conversations + blog were justifying it as a step towards POS, and related to the question of if ZSA) I edited the prior post to be more correct on this.

However these conversations didn’t get re-discussed, or analyzed in light of ZCash’s very different current economic situation. Namely higher fees, price, or “encrypt your bitcoin narrative”. At minimum the question asked to governance should be dis-entangling issuance from the voluntary burn/tx fee decision.

Thanks for taking the time to share your perspective. I appreciate you engaging with the NSM proposal, and, in particular, ZIP 234.

There have been ongoing discussions over the past couple of years about smoothing the issuance curve, both on the forum and during the biweekly engineering Arborist calls. These discussions have covered the motivation for the NSM, the mechanics of ZIP 234, and alternative designs. For example, there’s a long forum thread that goes into the NSM in detail, including trade-offs around issuance smoothing, supply accounting, and activation timing.

ZIP 233 and ZIP 234 are the two core components of the NSM: ZIP 233 defines a standardized and auditable mechanism for voluntary ZEC burning, while ZIP 234 specifies how new ZEC is issued into future block rewards in response to that activity, using a predictable issuance rule that preserves the 21 million supply cap. Together, these ZIPs define how burn activity is accounted for and how issuance is managed over time.

Regarding your suggestion to preserve the existing halving schedule while allocating newly issued ZEC from the NSM along a separate, smoothed curve: this option was considered and discussed, but ultimately not preferred. The main issue is that it adds complexity by effectively maintaining multiple categories of unissued ZEC, which complicates supply accounting and increases the risk of confusion for exchanges, data providers, and users. ZIP 234 instead treats unissued ZEC as a single pool and applies a simple, deterministic issuance rule, which we believe reduces both conceptual and implementation complexity while still approximating the existing four-year halving cycle.

On the point about the ceremonial value of discrete halving events, it’s fair to acknowledge that halvings have symbolic significance, particularly in Bitcoin. However, for Zcash, the economic effects associated with halving events have been less pronounced, and the protocol is designed to maintain a total supply cap of 21 million ZEC. ZIP 234 maintains that cap and replaces abrupt step changes in issuance with a predictable, continuous curve. A four-year halving anniversary could still be recognized socially, independent of the exact issuance mechanics.

I’m not sure how the NSM is inconsistent with the “encrypt your Bitcoin” narrative. If the concern is that Bitcoin has discrete halvings while Zcash, under the NSM, would not, it’s worth noting that Bitcoin’s long-term security budget remains a significant unresolved issue. The NSM is explicitly intended to address that problem. In that sense, the NSM helps make Zcash much more “unstoppable” than Bitcoin.

1 Like

That image is incorrect. This is the correct image (from GitHub - daira/nsm-simulator: Network Sustainability Mechanism simulator ):

I’ll file a PR to fix ZIP 234 (I had been waiting for someone from Shielded Labs to do so since I did point this out to them, but I guess I shouldn’t wait).

The motivations of ZIP-234 do not outline why the block reward should be continuous.

They do:

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.

You can dispute the argument and/or say that this motivation isn’t sufficient (and I did), but it is an argument. I see that my suggestion to flesh it out a bit more wasn’t acted on, though. (I didn’t see it as part of my role to file a PR to do that; it’s Shielded Labs that is promoting this proposal and I’m somewhat ambivalent about it.)

Changing the block subsidy to be continuous is also a short term increase to emissions, which is short term bad for the network and supply economics.

The issuance schedule currently specified in the ZIP fixes this, as shown in the corrected graph.

The NSM needs to happen if Zcash is going to have any long-term (read: decades / centuries) survivability, with the critical constraint that we never raise the 21M supply cap by introducing e.g. inflation or tail emission as we see on other chains.

The NSM is a carefully designed solution to this, amounting to a single new transaction field and exactly two simple updates to consensus logic: the new issuance schedule (simply a ratio of available coins), and the transaction fee recycling (out of scope here)

Recognizing the interactions between ZIP-233 and ZIP-234 helps us understand why they are bundled together. Essentially, they are two sides of the same coin: one removes funds from circulation (ZIP-233) and the other returns them to circulation via issuance (ZIP-234). All while still respecting the 21M supply cap.

Regarding the short term increase: Yes, as @daira points out, the proposed activation block ensures that issuance will not be “pulled forward” as you observed.

3 Likes

Thank you for pointing out the updated graph! That meaningfully changes the concrete change (to be better imo)

Re motivations of ZIP-234, I was looking at the 6 bullet points in Motivations, and 6 bullet points in Requirements. Your right the text paragraph does make that argument. (Though the bulletpoints of motivation suggest “don’t change anything” to me)

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

(W/ 5 arguing no change, just because Bitcoin and historic ZCash have done the education for us. Its aesthetic taste for whats apriori easier between continuous and discrete, if we didn’t have the history.)

Thank you for pressing in the ZIP for a better reason!

1 Like

Recognizing the interactions between ZIP-233 and ZIP-234 helps us understand why they are bundled together. Essentially, they are two sides of the same coin: one removes funds from circulation (ZIP-233) and the other returns them to circulation via issuance (ZIP-234). All while still respecting the 21M supply cap.

Agreed! Though neither needs the issuance to be smoothed. These justify the creation of the NSM , for funding from voluntary donations and transaction fees. That as a design is brilliant! (As is keeping it smoothed)

My biggest contention here is the governance / THV choice for this being a bundled decision. The decision were bundling is the governance point to be most clear on to token holders (the emission schedule)

The new NSM mechanism is fundamentally different from the question of “Do you make the current mining reward change away from halvenings to continuous decreases”

1 Like

As I mentioned above, we’ve considered alternatives to issuance smoothing, but they were either infeasible to design or impractical to implement. If you have a specific alternative that you believe would work, please propose it and we will consider it. That said, we’ve spent considerable time evaluating this topic over several years and believe the current design is the most practical approach available.