ZPF to me feels like what I’d call Decentralized, Reserve Banking (non-fractionalized). It provides some conventionally known traits of Fractional Reserve Central Banking, re: The FED, like M1 M2 supply modification. It reaffirms the cherished long term absolute total supply cap. It smoothens out what is the currently harsh emissions rate. It gives the ecosystem more optionality with regard to long term tokenomics.
I’m not aware of any L1 blockchain using this kind of scheme.
I believe Ethereum is somewhat similar with the combination of [EIP-1559: Fee market change for ETH 1.0 chain] and it’s issuance, because EIP-1559 burns transaction fees, and then issuance creates new units, so there are both flows into and out of the “active/extent” supply. So both schemes have this bidirectional flow.
However, a key difference with Posterity Fund is that it requires these two flows to follow a strict total supply cap, and it rate-limits flows out. I’m not aware of what constraints or limits exist on Ethereum new-token issuance.
Yes, they are very similar. The chart of supply over time shows how similar they are at a long time-scale (where it’s hard to even see a difference). The chart of current issuance (with halvings) vs Posterity Fund (with “disbursements”) makes the difference much clearer.
At some future date, it’s possible that the disbursement rate would be higher than the issuance rate of the halving schedule, but only if significant ZEC was previously removed from the active supply through fees. So the supply remains constrained, and the disbursement rate is always constrained by it’s own “continuous halving” rate limit.
Thanks for sharing your position about PoW vs PoS.
I want to repeat that this proposal is independent of whether Zcash uses PoW or PoS. In fact, one reason I advocate for this proposal is that by keeping the same “spirit” of the original BTC-style issuance, but decoupling it a bit from PoW, we could have more certainty about the issuance schedule regardless of changes to consensus protocols (*).
This proposal is relatively simplistic and only describes ZEC. So for it to enable funds from “outside the network”, that would either mean some way to exchange those funds for on-chain ZEC, or for a more complex extension of this protocol to support multiple assets (which also requires ZSAs and maybe bridges). I think both are very intriguing and worth exploring further! It sounds like @cwgoes is thinking along similar lines.
If this proposal were deployed on the current PoW consensus protocol with no other changes the only difference to miners is that block rewards would be a smoothly declining amount rather than the halving schedule. If that’s the only change, txn fees remain the same.
In this scenario, near the beginning of halving periods, they would receive more than the current schedule. Near the end of halving periods, they woudl receive less than the current schedule. The current schedule is grey, and the ZPF schedule is green (with an imaginary start date):
If, in addition to this proposal, some proportion of txns fees are put into ZPF deposits, this has the effect of redirecting them from the current block miner and spreading those out to future miners over a long time window. This means also, that the current amount of disbursements will be larger than the green line if there have been significant fees deposited into ZPF in the past. Over a long time window, I would expect the revenue of miners is roughly the same, the only difference is that the block rewards are much steadier and predictable and fluctuate less immediately with fees.
Given all of that, does the ZPF still seem like it would be unappealing to miners? My intuition is that it would be either neutral or positive. I thought it may be positive because they’d have more predictable revenue, and need to be less concerned with “playing games” around transaction selection to maximize fees.
I don’t understand why you say this. The ZPF proposal itself, including the fund balances or how many fees are collected, is not any different whether the network uses PoW or PoS.
PoW or PoS can change where fees may come from and where funds are distributed to (miners vs PoS block producers), but not the rate at which funds are distributed (which is fixed by ZPF).
Is it clear that if fees pay into the ZPF in the current PoW system, they are also paid out to miners?
There is one important nuance here: currently block rewards are split 80% to miners and 20% to Dev Fund recipients, but all txn fees go to miners. This base ZPF proposal doesn’t change txn fees, but I allude in the blog post, and in comments here, that I think we would want to consider redirecting txn fees into the ZPF (at least partially). So if we do that it would mean miners would receive only 80% of txn fees paid, since 20% would be disbursed into the Dev Fund.
My belief is that because txn fees are minuscule, making this change now won’t make a significant difference to any party. OTOH, if we considered activating that kind of fee change later after fees are more significant, then it would be harder to come to agreement, because the redirection would impact different stakeholders significantly.
(*) Issuance rate and consensus protocol can’t be completely separate, since issuance/disbursement rates affect the security of different consensus protocols, potentially differently. With ZPF however, a proposed consensus protocol would have to make a really strong case for why it needs to deviate.
Just as a small contribution here (and to allow you to reply again to the thread ) - I believe, at least in the current version of Eth2, there is a cap on annual issuance, but it is denominated in percent rather than a flat amount (around 1.8% if nearly all the ETH is staking) (source). This is a distinction in terms of not having an exact asymptotic maximum supply, and Eth2 (as far as I know) does not have any sort of protocol-specific public goods funding that comes from supply inflation or fees - but the abstract mechanism of decoupling payments and payouts in EIP1559 to smooth out both the demand and supply side gas price movements is similar (this also e.g. makes mining a specific transaction in a block less valuable, and thus reduces incentive to DoS proposers for the next block if there is a really valuable tx that they can include). Similarly, as I understand it, the ZPF mechanism seeks to smooth out payouts to entities funded by the network issuance and provide more predictability.
The Zcash Sustainability Fund
Shielded Labs is interested in developing and supporting the Zcash Sustainability Fund (aka Posterity Fund). Over the next month, we’d like to open up a discussion and encourage community members and ecosystem participants to ask questions and provide feedback on the proposal. Please refer to the following resources for background information: (1) ECC’s blog post announcing the Fund, (2) the draft ZIP written by Nate Wilcox, and (3) Nate’s twitter thread summarizing the Fund.
Please note that Shielded Labs believes the “Zcash Sustainability Fund” is a more appropriate name than the “Zcash Posterity Fund” because it accurately reflects the fund’s purpose of ensuring the long-term sustainability of the Zcash network. “Sustainability” conveys the idea of maintaining the network’s viability over time, whereas “Posterity” refers to future generations and does not necessarily capture the idea of ongoing network support.
Recently, there has been increased attention around Bitcoin’s future security budget due to the possibility that miner revenue from transaction fees may not be sufficient to provide adequate network security after the block subsidy ends. Zcash faces a similar problem as its network is sustained by block rewards and operates with a supply cap of 21 million coins.
The Zcash Sustainability Fund (ZSF) addresses this issue by modifying Zcash’s issuance schedule and introducing a mechanism to direct funds towards sustaining the network. It preserves the 21 million supply cap and smooths out the emissions curve while maintaining an approximate issuance rate that replaces the four-year halving cycle. Fees deposited into the reserve are distributed over time in block rewards to help sustain the network.
In simple terms, the ZSF works like an algorithmic savings account or endowment. Funds are set aside for a specific purpose, to provide a sustainable source of block rewards for the Zcash network. Deposits can come from various sources, including transaction fees, which can be used to fund the network. Disbursements are governed by specific rules and policies that allow ecosystem participants to better plan for the long-term. In this sense, the ZSF is a reserve of funds that is managed separately from the circulating supply of ZEC to help ensure the long-term sustainability of the network.
The ZSF is not dependent on any specific consensus protocol, such as Proof of Stake, and can be implemented within the current Proof of Work consensus protocol. However, since it creates a mechanism for deposits that new applications or protocol designs can use to strengthen the long-term sustainability of the network, it may be an important step for future economic upgrades, such as a transition to Proof of Stake or Zcash Shielded Assets, and other potential protocol fees and user applications.
Shielded Labs was established with the aim of making the Zcash ecosystem more decentralized and more resilient. By developing and implementing the ZSF, it would be initiating the first network upgrade by an independent developer, which would demonstrate that Zcash is a permissionless network and also help lower the barrier to entry to serious development initiatives.
Shielded Labs believes the ZSF can help improve the long-term financial sustainability of the Zcash network. By creating a reserve that acts as an algorithmic savings account, the ZSF makes Zcash more resilient and helps ensure the protocol meets the future needs of its users. Moreover, the ZSF 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 unique identity and differentiate it from Bitcoin. The ZSF allows Zcash to continue that tradition by providing a mechanism for long-term network sustainability while maintaining its supply cap and approximate issuance rate.
In addition, the ZSF is relatively easy to implement from a technical perspective, requiring approximately 6 to 8 months of development work with 1 to 2 engineers. My initial impression is that community sentiment is generally positive based on conversations I’ve had with community members over the past month. Overall, I believe the project is low hanging fruit that is well worth the effort in terms of the benefits it will provide. If community sentiment is in line with my initial expectations, I believe the ZSF would be a non-contentious network upgrade.
If the community supports this initiative, Shielded Labs will incorporate your feedback into a technical specification, which will be written into a ZIP, and look to start development later this year. Since the ZSF is independent from a transition to Proof of Stake, and also works with Proof of Work, implementing the ZSF earlier allows the reserve to accrue value sooner. To that end, it would be reasonable to set the activation block height to coincide with the next halving in Q4 2024.
Please provide questions, comments, and feedback, and let’s get a vibrant discussion going. Specifically, it would be helpful to know (1) general reasons why you support or oppose the ZSF, (2) any questions or concerns you have about the design of the mechanism, and (3) any questions you have related to the economics of the ZSF.
Love this I support the ZSF and would love to dive into the details when ready.
I support this. And great choice of words/title, correlates well with the core purpose - Zcash Sustainability Fund.
After reading the draft proposal from Nate, I am overall pretty happy with the direction of where it is going. Just a couple of Qs/thoughts
After the ZSF is deployed, all unissued ZEC goes into the ZSF, and all future “fees” are paid into it also. I assume the fund will have to be publicly viewable, so how does that affect fungibility? is there any data leakage from a shielded tx paying into the ZSF? Nate goes into it under " Comparison to Transaction Outputs" somewhat, but I am not full bottle on the technicalities
Whilst the emission of ZEC is plentiful, I suggest that any deposits into the ZSF are banked, until say another 2 halving cycles are complete before being brought back into circulation. This will ease some of the inflation pressure we currently get, and have a greater impact on the rewards further down the line
After reflecting on this for some time I think its incredibly important for us all to stay humble and accept that we barely have a glimpse of what the next 5years for Zcash is going to look like. Anything that contributes or strengthens Zcash’s ability to provide sustainable funding for Zcash is probably one of the most important thing the ecosystem can do.
I also think it’s important whatever core decisions are made when implementing the ZSF we consider how ZSAs will fit into the system. Not because we “know” we will need to fit ZSAs into the into the ZSF, but because we “don’t know” if we need to. A large part of sustainability is all about managing risk, and making sure ZSAs fit into the ZSF model reduces that risk. If I had my way I’d like to see them mentioned in the ZIP in some form.
I believe that the long term impact the ZSF will have on Zcash will be enormous, but taken for granted.
Agreed. On the one hand, the current plan for ZSAs is that fees will be paid in ZEC, which simplifies things. On the other hand, should a hypothetical future sustainability fund be able to hold and distribute other assets? What consequences could that have for ZEC’s role in the Zcash network?
However, I think we should take a step back for a moment. It feels somewhat premature at this point to start focusing on implementation details and what should or shouldn’t be in a ZIP.
Fundamentally, the key questions are:
Should Zcash’s emission schedule change?
How should newly-emitted ZEC be distributed amongst:
a. consensus mechanism participants (i.e. miners, stakers, etc.), and
b. developers and other ecosystem contributors (e.g. current and future Dev Fund recipients), versus
c. reserved for future distribution (i.e. the “sustainability” part of the equation).
The answer to (a) is fundamentally about security - i.e. How much does it cost to secure the Zcash blockchain?
There are a bunch of different ways to think about that question, and it’s obviously highly dependent on what consensus mechanism Zcash uses. Right now, the answer is probably dependent on things like the capital cost of PoW mining equipment, miners’ operational and energy costs, and the competitive landscape (in terms of alternative chains that miners could switch their hashpower to), along with the implicit cost of mounting a 51% attack. If Zcash were to switch to an alternative consensus mechanism (like proof of stake), other factors come into play, like the need to incentivize consensus participants (and punish bad actors), the security ratio, and the competitive landscape (i.e. to what other uses could consensus participants’ resources be put to).
Ideally, if we can define the key inputs and a suitable algorithm, we can codify dynamic reallocation of newly-emitted ZEC into the consensus rules. However, that brings its own risks, especially while there’s a significant lead time to make changes to the consensus rules.
There are other considerations, like: How do we increase decentralization? Should minimizing the risk of adverse regulatory consequences be one of the goals?
In effect, this is a continuation or evolution of the discussions that took place in 2019-20 that led to the adoption of ZIP 1014 and the implementation of the Dev Fund. The high-level approach of “Discussion → Ideas → Concrete Proposals → Voting → Adjustment → Voting → Consensus → Implementation → Activation” seemed to work well then.
PS: We’ll look at how best to include this on the agenda for Zcon4.
- Only in the form of smoothing the emission.
- What about adding an extra 1% to the dev portion of emissions? So 8% 7% 5% 1% = 21% .
Are there expectations that these tough decisions are completed going into ZCon4 (and the conference will act as a description of what the implementation will look like) or will ZCon4 be used as a public square to host additional debate?
- Yes ZSAs should pay fees in ZEC.
- Yes the ZSF should be able to hold and distribute other assets.
- It will allow ZCG, ECC, and ZF to negotiate better terms for funding partners/groups. Terms for funding projects/teams could include the “donation” of some newly created ZSA into the ZSF.
I believe the long term value that ZEC is primarily as a scarce asset to enforce a cost of using the Zcash network. The Zcash network will eventually include some form of generalised on-chain proof verification. It makes sense to me that the token used to pay for this be arbitrary and specific to the network in question.
I’d like to share my opinion on this front, although since Shielded Labs is driving their own proposal they may choose to take it in different directions vs my ealier “Posterity Fund” vision. (I already am a big fan of the rebranding to “Sustainability”. I’m not at all a marketing guru. )
IMO, one of the strengths of the idea is explicitly to decouple the question of where funds come from and the issuance schedule vs where funds go to.
The latter question is crucial for multiple reasons: consensus safety, governance, and so forth. Extremely important topics to discuss.
But my opinion is that if we block setting up the fund and beginning to gather deposits on also changing decisions about where funds are distributed to, then it makes it much harder to make forward progress.
This is why in Long-term sustainability with the Zcash Posterity Fund I clarified:
This post and the Posterity Fund proposal focus on the sources and amounts of network funding and are agnostic as to the recipients
So my thinking with that was “keep recipients the same when deploying the fund” to decouple the two decisions.
Of course, since the design changes the issuance rate, it is already impacting the recipients in some way. My simplistic thinking was that the current issuance is divided among various recipients (miners and Dev Fund orgs) in a certain proportion, so the “most neutral” choice for payouts is to maintain the exact same proportions and recipients.
If the fund were deployed in that manner with “neutral” changes to the recipients, then it would enable the possibility of accruing different sources of deposits (transaction fees, various ZSA fees, etc…) without delaying those deposits from accruing while the community decides to alter recipients or proportions.
If the community was behind this approach of “decoupling” where funds come from vs where funds are distributed to, then it seems much easier to me to get the fund up and running without needing to answer important governance questions like “how much of the funds should go to network security versus a development fund” or to “miners vs stakers” (say in a future hybrid consensus change) or how much to Dev Fund recipients or if those recipients should change, etc…
Again, all of those are extremely important questions, I just don’t personally believe we should postpone setting up the fund prior to deciding on those other questions. Another issue here is that some of those questions should be answered at different times.
For example, consider these two questions:
- “Should we establish a new fund like the current Dev Fund after the current one expires, or should we let the current one expire and direct all new funding towards consensus security?”
- “Should we adopt a given PoS transition proposal that redirects consensus security funding from miners to stakers through some transition mechanism with some schedule?”
Now think about when we need to answer those two different questions. We may need or want to answer those questions at the same time, or the first before the second, or the second before the first depending on a lot of factors (for example if there’s any good proposal for a PoS transition before or after the Dev Fund ends). So if we decided to postpone setting up the Sustainability Fund, which other questions about funding destinations would we want to wait to decide on before deploying SF?
There may be a variety of plausible good alternative proposals here, but I’m of the opinion doing one thing at a time is simpler in terms of governance.
@nathan-at-least I applaud your efforts on this. Ill be honest, it wasn’t an exciting or revolutionary first read, but when I finally grasped the difference between the ZSF and raw Dev Fund are it’s striking how important it is we decouple issuance and funds.
@nathan-at-least So your comments got me thinking. How many ZIPs makeup a complete funding pipeline. 1, 2, or 3?
I’m not sure what you mean by a funding pipeline, and I guess how many ZIPs depends on what Shielded Labs is planning.
The most minimal thing I can think of wouldn’t have any deposits, so if only that were deployed, the net effect would be to just smooth issuance to a decay curve (and remove halvings). I would guess that could be a single ZIP.
One kind of deposit that seems simple and safe to me is a rule like “90% of txn fees are deposited into the fund and 10% go to miners”. We want some to go to miners so they have an incentive to include txns. I don’t believe this would be controversial for miners since fees are so tiny today, yet that also means deposits would be small. Meanwhile it gets the ball rolling so that if fees go up (say from more adoption, ZIP-317, ZSAs, etc…) after this change were made everything the Sustainability Fund would start working it’s magic. If we waited until after fees grew large and then attempted to redirect them into deposits, it may be more controversial / political at that time.
I personally would advocate putting that kind of fee change in a separate ZIP from the basic Sustainability Fund definition. It’s conceivable some would want the SF but not that specific fee change, and even if everyone wants both it feels cleaner/more modular and establishes a precedent for “here’s how to introduce SF deposits in a ZIP” for any future protocol changes (e.g. ZSAs, bridging, programmability, …).
With ongoing SEC and CFTC regulatory actions against crypto builders, brokers, and networks, can @nathan-at-least and @Dodger give any remarks about how you are contemplating your 501c3s, and their carried risk involved with both the 1. acceptance of ZEC from the protocol, 2. redistribution of that ZEC for dollars
Based on my review of the Howey Test, and to the context of how the SEC is evaluating crypto currency ecosystem actors, it looks almost certain that they will be capable of taking both Zcash Foundation and Electric Coin Company to court for sales of unregistered securities.
Beyond the above speculation, how are your teams considering the possibility of something like the Zcash Sustainibility Fund being able to act as a potion-pill to reallocate protocol ZEC in a manner that would eliminate regulatory risk to both organizations?
Are you an attorney, @noamchom?
LOL, are you a comedian? When I used the phrase my review I meant that to imply, anyone’s review of the Howey Test based on how the SEC and CFTC are currently reading it.
The regulatory risk to this developer ecosystem isn’t a joke.
I am hopeful that you and Nathan, or whomever are legally skilled team members within ZF and ECC, can share some perspectives about how regulatory risk is being factored into the big picture for Zcash.
ZF and ECC have monthly operating expenses close to 1.5 million dollars, so the community would prefer to have some assurance that serious topics are being treated seriously.
- Obviously yes, I don’t know who acts as broker for ZF and ECC, but in order for block reward ZEC to turn into dollars paid for operating expenses, there is some external entity investing money in order to receive those ZEC.
- Yes, the common enterprise is both among the orgs providing the block reward ZEC (either ZF or ECC), and the broader Zcash ecosystem as a decentralized global enterprise.
- Yes, the entirety of crypto currency markets posit that coins bought today will at some future point in time provide profit on the initial dollar cost.
- Yes, because the block reward ZEC transacted explicitly turn into the dollars that fund the operating expenses of the ZF and ECC. Said efforts being the primary driving forces that sustain and accrue value to Zcash.
Speaking for ECC, I recognize the concern, especially against the backdrop of aggressive actions taken by the SEC under this administration.
In addition to our work with outside counsel on this, my team includes a global head of regulatory relations (Gary Weinstein) and head of US policy and strategic advocacy (Paul Brigner).
We have been on top of this for some time, including a number of activities that I won’t go into here. The most highly regulated exchanges around the world have completed their own analysis as well, and are comfortable that Zcash is not a security. To our knowledge, not a single regulatory or regulated entity considers Zcash to be a security.
As it relates to regulatory risk, my concerns, and where we spend significant time, are related to privacy, defi and self-hosted wallets.