ZEC circulating supply buy back protocol
this names describes buying back zec and removing the zec from the circulating supply and putting it back into the unissued zec supply at the protocol level. no human interaction and it’s all automated.
Except that there’s no “buying back” going on here. This is purely about explicitly defining the pool of ZEC from which future issuance will be drawn (instead of it being implicit in the supply cap), and permitting explicit deposits into that pool from the other pools. Nobody’s buying anything. The sum of value in all the pools must then always be equal to 21,000,000 ZEC.
2 Likes
then it sounds more like a
zcash treasury protocol
hopefully you guys can figure it out that fees are going to be a requirement to get zcash funded in the future and just get it done sooner than later
Zcash Reserve?
Is the idea behind this that if Zcash has to move to PoS that this will be where the yet-to-be-mined coins would go to get 21M coins issued?
For example if Zcash goes PoS in 2025, and only has ~18M coins mined, then upon switch the remaining 3M coins could go into the reserve?
Zcash Null space, its empty until assigned.
No, the ZSF is not specifically designed to serve as a repository for all unmined coins in the event of a switch to Proof of Stake. It is compatible with both PoW and PoS consensus protocols. The primary purpose of the ZSF is to replace the existing issuance mechanism with one that allows ZEC to be removed from circulation—effectively making it “unissued”—and deposited into the ZSF to be used in future block rewards to support the network.
At a high level, the ZSF is designed to address the challenge of maintaining network security as the block subsidy decreases and ultimately ends. The mechanism helps ensure that there is still a means of incentivizing network support activities.
Potential sources for deposits could include donations (in ZEC or other assets), transaction fees, fees from minting or storing ZSAs, or slashing penalties if a transition to PoS occurs. Disbursement of these funds will be governed by future protocol upgrades. Currently, our focus is on developing the ZSF’s deposit mechanism. Decisions about deposit sources and disbursement strategies will be decided by the community in the future after the ZSF is implemented.
1 Like
Am I understanding correctly that ZSF in its first instance would only disburse ZEC from the pool as block rewards (PoW) and/or validator rewards (PoS), but could not disburse based on a hypothetical voting outcome from something like what Josh is mandating? (a Zcash Ecosystem Decentralized Autonomous Funding Congress ZEco DAFC)
Is support correct here, in that the ZSF intends to incentivize more than just network security? (i.e. support meaning paying protocol R&D engineers, ZCG grantees, Qedit, et al)
1 Like
No, it could disburse based on something like what Josh has proposed.
The ZSF itself does not “intend” to incentivize any specific activities. It is a mechanism within the protocol that can be adapted for various purposes. The actual disbursement of funds is subject to decisions made by community governance. Hypothetically, the community could choose to allocate disbursements in a manner similar to the current block rewards payout scheme, where a portion of the rewards goes to miners for network security and another portion could be directed towards the Dev Fund or other initiatives.
3 Likes
No, this is also not a treasury. Just as the remaining unissued Zcash value is not a treasury.
It’s just treating the remaining unissued portion of the 21M cap as an explicit value that can grow via deposits from the other pools, not just diminish as it is issued in coinbase transaction block rewards.
It’s likely that for something like what Josh has proposed, a better design would be to transfer the per-block dev fund value to a separate pool of issued funds that would then be disbursable via a multi-sig transaction, just because the UTXO model is pretty inconvenient for a multi-sig dev fund (as has been discussed in the Arborist calls.) And that pool would then be a treasury.
3 Likes
How about the “zcash recycle pool” as the tokens have been taken from circulation in the form of fees and are waiting to go around again and be re mined
recycle doesnt sound good imo
1 Like
Ok how about “block reward pool”. Since all unmined zec will be moved to the pool after its activated
2 Likes
We want to share some updates we’ve made to the Zcash Sustainability Fund (ZSF) to clarify its purpose and improve the community’s understanding of how it functions. Nothing material has changed under the hood; we’ve just refined our terminology and approach to make it easier for the community to understand.
We have changed the name from Zcash Sustainability Fund (ZSF) to Network Sustainability Mechanism (NSM) because, as we’ve previously stated, the word “fund” creates confusion. The NSM is not a fund. Rather, it modifies the issuance mechanism to enable the removal of ZEC from circulation, which is later recreated as future block rewards to help sustain the network. The ZEC that is removed from circulation is accounted for by the network’s consensus rules.
Consequently, we no longer refer to “deposits” or “distributions,” but instead use the terms “burning” to describe the process of removing ZEC from circulation to support network sustainability, and “minting” to describe the re-creation of ZEC, which honors the 21 million coin cap. Burning and minting are common terms used in other crypto projects and are easier for the community to understand.
We have updated and finalized the three ZIP specifications and completed the code for the zcashd and zebra implementations. We would like the NSM to be considered as a candidate for Network Upgrade 7 (NU7), if possible. We acknowledge the concerns Daira raised regarding the possible implementation of the NSM and are working to address and resolve those issues.
Please refer to the FAQ below for answers to common questions about the NSM.
Frequently Asked Questions (FAQ)
What is the Network Sustainability Mechanism (NSM)?
The NSM is an upgrade to the issuance mechanism that maintains the 21 million coin cap and enables the burning of ZEC from the circulating supply, which can later be reintroduced as future block rewards to help sustain the network.
There are three ZIPs associated with the implementation of the NSM. ZIP 233 establishes a voluntary burn mechanism that allows users to contribute to network sustainability. ZIP 234 smooths the issuance curve, which enables burned coins to be reintroduced into circulation in a straightforward and predictable manner. ZIP 235 proposes to burn 60% of transaction fees to help sustain the network.
Why is the NSM important?
Recently, there has been increased attention around Bitcoin’s future security budget due to concerns that miner revenue from transaction fees may not be sufficient to provide adequate network security after the block subsidy decreases. Discussions in the Bitcoin community have focused on solutions like adding tail emissions, which could breach Bitcoin’s 21 million coin cap, or whether Bitcoin’s price will rise enough for transaction fees to adequately compensate miners. Zcash faces a similar problem as its network is sustained by block rewards and operates with a supply cap of 21 million coins.
The Network Sustainability Mechanism is an attempt to address this issue of network security. It’s a modification to the issuance mechanism that maintains the 21 million coin cap and enables ZEC to be removed from the circulating supply and re-created in future block rewards in order to help sustain the network.
What does the NSM accomplish?
The NSM enables burned ZEC to support network sustainability. This enhancement enables “donations” to be made directly to the Zcash network instead of solely to development organizations or individuals. The ZEC that’s removed from circulation can be re-created in future block rewards to support miners, stakers, and Dev Fund recipients, which enhances the long-term sustainability of the network.
There are two significant impacts related to the removal of ZEC from circulation.
First, by removing ZEC from circulation, the overall supply decreases in the short term, resulting in a deflationary effect. In this context, deflationary means that the reduced supply increases scarcity, which can potentially result in a higher value for existing ZEC.
Second, removing ZEC from circulation allows for a higher rate of coin creation in the long term. This means that there will be more ZEC available for future block rewards further along the emissions curve, supporting incentives for miners, stakers, and Dev Fund recipients while still respecting the 21 million coin cap.
What are the immediate benefits and use cases of implementing the NSM?
As mentioned above, the primary benefit of implementing the NSM is the ability for donations to be made directly to the Zcash network, and the 60% transaction fee burn proposal that is bundled with the NSM proposal. The NSM provides a credibly-neutral way to contribute to long-term sustainability without favoring any specific organization or individual. Wallet apps, for example, could give users an option to burn ZEC as a donation to support network sustainability when making a transaction. Organizations or individuals can also demonstrate that they are donating to the Zcash network by verifiably burning ZEC.
Additionally, the NSM enables applications or systems outside of the consensus protocol to respond to burn events. For example, an application could provide a specific identity badge that represents your contribution to the network based on a donation of a certain amount of ZEC. This could enable token-gated communities, for example a forum where all user accounts are proven donors to Zcash’s long term sustainability.
What are some examples of future use cases?
The following example use cases will be decided by the community in the future and will require thorough discussion, as they involve important governance decisions.
Donations in Other Assets: Following the announcement of a strategic alliance between Zcash and Namada, Chris Goes highlighted the potential for contributing NAM across a bridge to the Zcash ecosystem via the NSM. This can also be achieved through other bridges, such as the Avalanche Red Bridge.
Legacy Support Fees: These fees can be implemented to ensure that users relying on older protocol technology compensate the network for the risks and costs associated with supporting that technology. For example, users storing their funds in an older pool may incur fees that could incentivize them to move their funds to the newer pool.
Zcash Shielded Assets (ZSAs): A portion of the fees associated with minting, destroying, transacting, storing, or bridging ZSAs could be burned via the NSM to contribute to the network’s security. For instance, if someone holds shielded Bitcoin (or zBTC), they could burn a small percentage of their stored asset to compensate ZEC holders, or perhaps there is a fee burned when sending zBTC over a bridge.
Privacy Incentivization Fees: Users who transact or store their ZEC in transparent addresses could be charged a fee to compensate the Zcash network for the opportunity cost of a larger anonymity set.
Ethereum EIP-1559 Style Fees: A base transaction, dynamic fee mechanism similar to Ethereum’s EIP-1559 could be established, automatically adjusting based on network congestion. A portion of these fees could be burned, providing a consistent and predictable contribution to long-term network sustainability.
How and when will burned ZEC be reintroduced as future block rewards?
Removing ZEC from circulation provides an increased rate of coin creation over the long term further along the emissions curve. This approach ensures that there will be more ZEC available for future block rewards further along the emissions curve, all while adhering to the 21 million coin cap. One way to think of this is that burning 1 ZEC now causes 0.5 additional ZEC to be issued in the next 4 years, 0.25 additional ZEC to be issued in the following 4 years, and so on.
What other ways could the future ZEC be spent?
The NSM does not change anything about the destination of newly issued ZEC, although it changes the amount. The destination of newly issued ZEC is a critical aspect of consensus design and deserves thorough discussion and consensus for any changes. What the NSM enables is new sources of issuance support via different mechanisms for burning ZEC.
Why aren’t we talking about fees and other long-term burning use cases now?
From the beginning, Shielded Labs’ goal has been to develop a modest version of the NSM that modifies the issuance schedule while keeping the 21 million supply cap and approximate halving rate, in order to issue more ZEC in the future to compensate for ZEC that has been burned, and to leave the conversation about future changes about fee burning mechanisms for the community to decide at a later point in time after the NSM is up and running.
Activating the NSM does not change any discussion or decision about where newly issued ZEC goes, such as to miners or potential future Dev Fund successors, or potentially stakers or other new kinds of destinations in future upgrades. Those discussions should be approached thoughtfully, but separate from discussions about the NSM.
This approach allows us to separate the technical development of the NSM from discussions about its potential use cases. By focusing first on the development of the underlying technology, we can keep the project manageable without complicating the development process. This enables the community to have focused discussions about its applications and any changes to fees once the NSM is operational.
What is the reason for smoothing the issuance curve?
The primary objective of the NSM is to create an automated mechanism that enables users to contribute to the long-term sustainability of the Zcash network. As part of this process, burned ZEC can be reintroduced into future block rewards. Smoothing the issuance curve with an exponential decay model offers a straightforward and dependable way to reintroduce burned coins back into circulation. This approach allocates the necessary coins at a steady, declining rate, allowing for predictable issuance while preventing sudden changes that could disrupt the network. The issuance mechanism is designed to approximate a four-year half-life, and future protocol upgrades may not increase the payout rate beyond this four-year constraint.
We’ve developed a simulator that allows you to visualize the impact of smoothing the issuance curve:
How will burning transaction fees impact miners?
The impact of ZIP 235, which proposes to burn 60% of transaction fees, is minimal. This is because transaction fees are currently low, resulting in an estimated annual reduction of only about 210 ZEC. Our intention has always been to implement a modest version of the NSM to introduce the basic functionality and to leave the conversation about future changes about fee burning mechanisms for the community to decide at a later point in time after the NSM is up and running. This approach allows us to decouple the technical implementation of the NSM from governance discussions regarding future use cases.
Currently, transaction fees are very low, and the proposal to burn a portion of them into the NSM will not have a significant impact on network sustainability. This makes it an ideal time to implement the burn mechanism, before block producers have any strong economic incentive to oppose it, as was the case with Ethereum’s EIP-1559. In Ethereum’s case, there was uncertainty around how fee burning would affect miners, leading to discussions about the potential for chain-splitting forks, but the developer community ultimately reached a consensus to move forward. By implementing this now, we avoid similar issues and ensure a smooth integration of the fee burning mechanism.
What’s changed in the updated versions of the ZIPs?
ZIP 233 has been updated to introduce a voluntary mechanism for burning ZEC. The ZSF_DEPOSIT field has been replaced with burnAmount. ZSF_BALANCE is no longer reflected and defined in relation to MAX_MONEY by ZIP 234.
ZIP 234 has been updated to allow for the burning of ZEC, enabling it to be reintroduced as future block rewards while maintaining the 21 million supply cap. We’ve revised the motivation section to make it clear that an adjustment to the issuance mechanism is necessary to account for burned ZEC. Additionally, “Money Reserve” replaces ZSF_BALANCE and is defined as MAX_MONEY – ChainValue.
ZIP 235 remains largely unchanged, except that it now specifies the burning of 60% of transaction fees to support network sustainability.
What’s the urgency for implementing this now?
There is no immediate urgency to implement the NSM, but it is crucial to improve long-term sustainability before it becomes a problem. We prefer to do so sooner rather than later. The NSM provides Zcash with a proactive approach to managing its security budget, addressing potential future challenges similar to those faced by Bitcoin. By implementing the NSM now, Zcash can introduce the functionality for burning and minting ZEC, allowing the community to directly contribute to the long-term sustainability of the network.
With ZIP 235, we establish the precedent of burning a portion of transaction fees. If subsequent changes to fees enable Zcash to effectively handle demand spikes with increased fees before achieving the necessary scalability, then a silver lining is that these fee spikes will contribute to future issuance. Once those subsequent fee improvements are implemented, Zcash’s monetary policy will resemble Ethereum’s current monetary approach, except Zcash would limit issuance by the 4-year decay rule and would impose a 21 million supply cap.
In addition, the NSM provides an opportunity for Zcash to continue to improve on Bitcoin’s design. Privacy and the development fund are two important features that define Zcash’s identity and differentiate it from Bitcoin. This upgrade allows Zcash to continue that tradition by providing a mechanism for long-term network sustainability.
While it can be tempting to defer implementation by citing a lack of urgency, this mindset may lead to continuous postponements, potentially until it is too late to help, or resulting in missed opportunities that benefit Zcash holders and users. Early implementation opens the door immediately to donations, creates a foundation for future enhancements, enables the community to engage in discussions and governance decisions about potential future use cases, and allows the network to continue its evolution as unstoppable private money.
16 Likes
Wrt “In some instances, such as miners not claiming all available rewards,” exactly what other instances would qualify for Soft-Burn?
1 Like
Hi! I’m your friendly neighborhood Discourse Trust Level 0 Shielded-Labs-associated Nate, jumping into the forum to share some of my thinking about NSM that we’ve realized isn’t well documented.
My goal with this post is to convince you the NSM is a potential Zcash super-power that could be a top-tier feature of ZEC along with the likes of privacy. After you read this post, let me know if you agree or have other reservations.
It turns out, when designing on-chain protocols, token burning can be a valuable mechanism, because (a) it’s hard to argue it is not fair, whereas sending funds to any recipient requires a high bar of justifying why particular classes of recipients have protocol-enshrined revenue and (b) protocol-enforced burning cannot be gamed by miners or block producers.
For (a), given the appetite I perceive for future improvements to Zcash, I expect there will be future areas where ZEC burning is an appealing option. Speculatively, maybe for ZSA issuance or transfer, a new transaction fee system (*), protocol-enforced (aka trust-minimized) bridges, any kind of future programmability, etc…
It’s also important to understand that a verifiable burn on-chain which can be proven to offchain systems may be really valuable, which @aquietinvestor 's FAQ includes an example of with a forum system. That’s just a speculative brainstorm. The really important thing to understand about this category is that it doesn’t require Zcash consensus changes.
So sometimes people ask me what’s the next step to support economic sustainability for Zcash, and I don’t know. What I do know is we’re all hard at work trying to determine what that is, and my bet is that down the road, protocol-enforced burning may become valuable for it’s own reason, such as to support a specific feature.
Now all of that discussion so far is about why it can be beneficial to burn ZEC. But some people do not like such generalizations and want to know more concrete plans or examples, so I want to share a personal vision I have for a future mechanism: improving our transaction fee system.
Any of us who have been around a while remember the “dusting attack” that persisted for a long time, made shielded wallets effectively useless, and interfered or made implausible many full node use cases. I am directly partially at fault for letting Zcash get into that precarious position by thinking “Hm, let’s wait to improve scalability until there is demand, then it will be a good problem to have.” I severely under-estimated the amount of time it would take to respond to such an issue. And yes, we already knew about and discussed the problem with how fees in Zcash wouldn’t work well if there was “significant transaction demand” (legit or not).
Finally, finally, we rolled out ZIP-317, thanks to a lot of sustained focus and effort across orgs. (Part of the long roll out time was decision making slowness in ECC, which I’m also partially responsible for.) And the dusting attack stopped! So what did I learn? (1) Don’t underestimate how long it takes to roll out high load resilience mechanisms, and especially scalability improvements, and (2) start those before you need them! Remember, there’s no difference from the protocol’s point of view between “DOS attackers” vs “many users quickly flocking to Zcash”. I am especially concerned that Zcash needs to be ready for the latter, because things can go bad quickly in the real world, and Zcash offers what can be a crucial life-line. Let’s make sure if the shit hits the fan, we’re not failing people when they need Zcash most.
Here’s the problem: ZIP-317 did not fix the dusting attack and it did not fix the problem of many new legitimate users adopting Zcash. What it did is it raised the cost for a denial of service attack to a new higher number (from an admittedly basically 0 cost). The moment any attacker values denying service to Zcash users more than that number, the dusting attack is back. But also, even if there is no attacker, the moment enough users want to use Zcash, we’ll be in the similar predicament as the dusting attack, except for the huge caveat that Shielded wallets scanning/syncing performance has been radically improved.
So, a future change I’m personally keen on is introducing a dynamic network wide fee mechanism, similar to Ethereum. (I can go into a variety of motivations for that kind of design, but it deserves a separate post. The super quick version is the best mix of good usability and security.) Such a new fee system would prevent a future dusting-style DOS attack longer than some reasonable window (maybe somewhere in the “hours” range). It would not magically make Zcash suddenly usable for a massive influx of users. Instead what it would do is make Zcash usable for only the subset of users willing to pay the most. This sucks, but it is much much better than making Zcash usable for no one. The true solution is scalability improvements. The purpose of this dynamic fee system is just to ensure Zcash remains usable for someone during those events.
Ok, so what about burning? Remember above with I mentioned why burning is important for two reasons and the second is security? It turns out it is crucial for security in a dynamic network-wide fee system, because that system responds to existing fees and if fees go straight to a miner without burning, then a malicious miner can now execute the attack relatively cost-free. (Even without a new nice UX-improving dynamic fee system, the same is true of Bitcoin style first-price auctions for fees.) So we require burning if we want to make the protocol secure against a malicious miner (or in a PoS or any other consensus protocol, whoever makes a block the new consensus state). Any protocol that reacts to fees is likely to become vulnerable to certain attacks or manipulation unless some of those funds are burnt and placed outside the control of any potential attacker, so I expect burning will be valuable for security in other areas (e.g. ZSAs).
Finally, we arrive all the way back to NSM. NSM isn’t necessary for any of that stuff above. We could just do burns. The difference is that if the NSM is in place, then every case of a burn also supports the network into the future.
But notice this by itself doesn’t guarantee NSM will provide economic sustainability. Here’s the secret: if Zcash cannot find economic sustainability, it cannot survive, regardless of whether or not we adopt the NSM. One difference between the current status quo and the addition of NSM is that in the latter case at least we have a specific way to support sustainability: just burn ZEC.
Final tangents:
-
The current txn fees are miniscule, so the current proposal to burn a portion into NSM doesn’t add up to much. That’s precisely why we should do it now, before block producers have an economic incentive to push back against fee burning, as happened in Etherem. (For example, in Ethereum there was a some amount of uncertainty around chain-splitting forks of EIP-1559, and I recall listening live to a core developer call where someone nervously asked about the fate of miners, to be rebuffed by the dev consensus in the room.)
-
I sometimes hear people saying Zcash will need to use tail emission, since the issuance curve doesn’t work in the (very) long term. My answer is: not if there’s NSM in place and sufficient transaction fees. Also, the txn fees are smoothed over a four-year half life, so it’s resilient to periods of drought and demand spikes.
Notice that Ethereum has both issuance and burns, as do many other protocols. What is unique about the NSM? It maintains the 21M ZEC cap, while potentially enabling indefinite sustainability.
So I hope when you read this you either agree the NSM is very important for Zcash, or you can provide some more specific criticisms. More specific ones are very appreciated!
11 Likes
Does code exists and or do you have a precise definition of Burning used as described above? I think the details will matter when discussing some of these ideas.
Excited to dig in 
3 Likes
Hi @autotunafish. I believe you’re quoting an earlier version of ZIP 233, which stated:
Recovery of “Soft-Burned” Funds: In some instances, such as miners not claiming all available rewards, some ZEC goes unaccounted for, though not formally burned. This proposal would recover it through the ZSF_BALANCE mechanism described below.
The idea here is that unclaimed transaction fees could be identified and confirmed by the consensus rules, allowing them to be reissued as future block rewards via the NSM.
A similar use case of ZEC that might qualify for soft burns include legacy support fees, which could be implemented to ensure that users relying on older protocol technology compensate the network for the risks and costs associated with supporting that technology. For instance, the Sprout pool could be depreciated by introducing fees that gradually burn the ZEC held in that pool if users do not withdraw those funds to a newer pool.
While the Sprout pool example is out of scope for our proposal, it represents a potential future use case. Ultimately, these considerations require serious discussion and will be decisions for the community to make after the NSM is operational.
1 Like
Hi @dismad. Here’s a link to ZIP 233, which defines the voluntary burning mechanism:
Here’s the relevant code from the Zebra implementation:
1 Like
Sprout qualifies as defunct. Besides what gets sent to the burn address, how could you guarantee you have correctly indetified lost funds?
Thank you!
Another question:
- Point #3
What happens if consensus can’t be found with who gets to mint from ZSF? Does this mean, in that case, all ZSF funds would default to this plan:
or would it all go to miners?
I ask this question because getting lost in the detail is extremely likely here. You can’t start with the how, before the why, IMHO. That is, in many ways the why is a subset of the how, and typically its the sub spaces that actually matter.