Awesome!! Having more entities capable of making consensus rule changes to Zcash, especially ones not based in the U.S. will go a long way towards making Zcash more resilient.
Without any plans to deprecate zcashd on the horizon, the new consensus rules would also have to be implemented in zcashd prior to activation. Is this part of the work you’re planning, or is that expected to fall on other ecosystem participants (like ECC)?
Hi @earthrise. Implementation into zcashd is part of the work we’re planning. I will make that more explicit in the proposal. Thank you!
Sooo… to make Zcash sustainable, the plan is to conjure up the entire coin supply like 100 years early?
Having the rest of ZEC in a pool controlled by the consensus, is the same as to having the rest of ZEC getting “mined” by the consensus.
Not exactly imo. The constantly changing consensus of ~today is potentially very different than the consensus of the future (think years into the future).
One quick example of consensus differences would be to presume the consensus today who are Proof of Work technicians, vs the consensus of the future (if Proof of Stake is completed) who are greater in number and who are ZEC holders/ wallet users but not necessarily PoW Hardware technicians.
Decision making today by the current consensus (PoW) could be viewed critically by the consensus of the future (PoS).
My guess is that the PoW consensus of today are probably not in support of pre-mining the remaining 7 million ZEC into a large transparent pool… whereas future PoS validators may be comfortable with that concept. Pre-mining all of the ZEC would likely be irrevocable as a technical matter.
Personally speaking, I support the pre-mine solution that would place the remainder of all ZEC into a large and transparent pool, where they are then distributed from; to either PoW miners now, or PoS validators in the future.
Hey folks, we believe this is worth clarifying:
Just a note: one possibility that could be considered is that the value of “reserved” ZEC that @aphelionz mentions could take into account the small existing value of ZEC block rewards and fees that was not properly claimed by miners when the relevant blocks were mined. The total value of these unclaimed rewards is the difference between the theoretical supply and the actual supply as of the current block; these values have been computed from the chain history on a per-block/per-address basis and can be found in zcash/contrib/metrics/supply_check/deltas_mainnet.py at master · zcash/zcash · GitHub
During last week’s Arborist call, Shielded Labs announced it has started development of the Zcash Sustainability Fund in collaboration with engineers from the Equilibrium Group. The first milestone is to draft two ZIPs: (1) to establish the ZSF at the protocol level and (2) to modify the issuance schedule. We also plan to meet with members of the Zcash Foundation’s engineering team in August to discuss building a proof of concept in Zebra.
We’ll continue to use this thread to provide periodic updates on the status of the project and to solicit community feedback. You can follow along with the project at the Discord Zcash R&D’s dedicated #sustainability-fund channel or via the bi-weekly Arborist calls.
What does not properly claimed mean? How many total coins is this today?
My reaction is that valid but unclaimed rewards should remain unclaimed, perhaps the miner intended to unclaim those rewards. It feels like a slippery slope to presume the rightful reward owners intent/ grabbing coins that were not earned as reward via consensus protocol rules
Hi all,
I just responded to a CT post about the blocksize growth, and my thread kept growing longer and ended up tying together multiple pieces:
Since my thread mentioned ZSF, I thought I’d share it here as a brainstorm of how future protocol changes might tie into ZSF.
And to be clear, the third and fourth bullets are speculative on my part, but to me they seem like good steps that relate to ZSF. (For example, I’m not aware of anyone actively working on an EIP-1559-like change currently, and it’s not on ECC’s current roadmap.)
Also, just to repeat a position I shared elsewhere, I don’t advocate trying to bundle a change like EIP-1559 into a ZSF design up front, but instead to approach them as separate options, because I think this simplifies each step both technically and in terms of governance.
I don’t think “pre-mining” is an accurate concept for ZSF, and to illustrate here’s a thought experiment:
I hearby declare that Zcash has a “Zcash Nakamoto Fund”:
Ok. So did we just “premine” 7M ZEC?
No, I just used an accounting terminology to describe the current consensus rules. This isn’t how the current rules are typically described, but it is equivalent to the existing consensus rules.
It doesn’t “premine” anything or change anything about how the ZEC supply, even though it is “a fund” and “withdrawals” are made from it. These are just alternative terms to describe what already exists.
The ZSF is similar, except it changes how funds get distributed into two ways: it “smooths” issuance instead of the 4 year halvings, and it allows “deposits”.
Just like the “Zcash Nakamoto Fund” is an alternative way to describe the current rules, there’s a different way to describe the ZSF that doesn’t use the concept of “a fund” or “withdrawals” or “deposits”.
We could talk only about current block issuance and how that changes when ZEC is contributed to “future block rewards” in such a way that the rate of issuance follows a smooth halving curve and the total supply is still capped at 21M ZEC. I think that alternative description would be a lot harder to understand versus describing a “fund” that the protocol manages because deposits and withdrawals are a convenient way to think of how to describe it.
Does this description about how the “fund” is a way to track accounting and not a “pre-mine” make sense or not?
Makes a lot of sense, and I suppose that I understood the suggestion originally also. Although pre-mine seems like what would happen it really is not. The fund acts as a permanent gatekeeper to assure the floating or non floating supply of ZEC is controlled, auditable, and being held up to the rules of the protocol.
My comment at first regards my general conceptualization of specifics of Proof of Work and how it instantiates new coins over time. The long term supply cap for PoW (or PoS) coins depends on consensus. For Bitcoin, people feel extremely assured that its 21m cap will remain unmodified forever, but for much smaller PoW coins there may be occasional feelings that an eternal hard-cap doesnt make sense… lets take Monero for example and their tail emissions supply implementation. I don’t think Bitcoiners, Zcashers, or Litecoiners to make 3 examples would be in favor of an in-flight change to include some tail emissions like supply change.
With the Zcash Posterity Fund, the wording and communication about what it is may be challenging, particularly so because we’re also having active discussions about changing to Proof of Stake, and there are active discussions about the Dev Fund decision for the next halving cycle.
If the ZPF messaging creates confusion, that likely will create fear, uncertainty, and doubts. So however the ecosystem approaches this topic, my opinion is that we should be deliberate in our choice of terms, branding, narrative, short-hand, et al… in order to hopefully mitigate against communications and marketing challenges. We all love the upgrade beyond trusted setups known as Halo but we can also probably all agree that the marketing and messaging around the upgrade was possibly convoluted, delayed, and too technical to pique the interest of common crypto adjacent users and journos.
I’ve never heard Bitcoin described as having its supply in a Nakamoto Fund (?) was that your choice of words for the sake of the thought exercise? I feel that the use of the word fund conjures up the idea of a room with a safe and some security guards… it feels like all of the ZEC today or ever would be stashed in the safe, and that the fund managers then exercise their power to distribute new floating coins or call-back-in existing floating coins.
After thinking about this more, I’m in favor of avoiding the word Fund altogether in the messaging and discussions around this potential protocol upgrade, because Fund is such a well known term, that will carry a ton of (possibly incorrect) assumptions when used to describe the ZPF.
From here on I’ll try my best to use emissions smoothening & fee allocation upgrade ;0
The Zcash ESFA upgrade …ohhh wait, I see a better ordering.
The Zcash SAFE upgrade… Smoothening the Allocation of Fees, & Emissions
this is great but still does not solve the long term issue of supply cap. please see my post here:
what can we do to guarantee sustainability of the protocol far into the future. Even Vitalik said himself in the above tweet that Monero gets this right ( supply cap)
I am for fees/gas the are designed to support the blockchain and ecosystem in a highly decentralized manner. Paypal exists because the US goverment doesn’t even try to come up with the solutions people can create on their own. Ethereum also appears to have a highly decentralized model. Push as much as possible to self funding and development as possible to 3rd parties and give them an incentive to build. Internally focus on the core blockchain.
This makes sense for a portion of the fees. But to really open up the network, don’t the developers of applications need a way to generate and earn fees from the products they create? Development needs to be largely decentralized with condition being that the fees a developer gets are connected from ZEC or ZStablecoin transactions their application generates. This still sounds like centralized funding and development. Isnt it?
I would like to see the fee splits more like below or to use Ethereum as a model as it seems to work very well; but instead of a burn, the amount otherwise used to burn can be used to buy ZEC and return to ZEC holders as yield.
I have put together a poll to gauge interest in moving harder and faster on stablecoins and improving ZEC economics. Please take a look and vote.
From the perspective of coins which are not mined yet it’s indeed difficult to see it as a fund.
But ZPF enables the possibility of depositing funds in it (ZEC at first and probably others coins/tokens later) makes it look more like a fund.
That said « SAFE » looks really cool !
Below is the first draft of our ZIP to develop the Zcash Sustainability Fund (ZSF) at the protocol layer. We invite you to review it and provide your thoughts, feedback, and suggestions. We will allow a comment period for at least one month. Since we are building consensus as we go, community feedback is crucial. Please post your comments to this thread or DM me if you’d prefer to provide feedback in private.
Please note that this is the first of two ZIPs we will be posting for feedback. The second ZIP will be posted next week and relates to replacing the traditional block reward halving system with a smoothed out emissions curve that maintains an approximate issuance rate. If there is general community support for both ZIPs and no significant objections to moving forward with this project, we plan on starting the development phase shortly after the comment period.
You can read our original project proposal here.
Title: Establish the Zcash Sustainability Fund on the Protocol Level
Owners: Jason McGee, Mark Henderson, Tomek Piotrowski, Mariusz Pilarek
Credits: Nathan Wilcox
Status: Draft
Category: Ecosystem
Created: August 2023
License: BSD-2-Clause
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]
The term “network upgrade” in this document is to be interpreted as described in ZIP 200. [2]
The term “Block Rewards” refers to the algorithmic issuance of ZEC to every block’s creator – part of the consensus rules.
“Issuance” - The method by which unmined or unissued ZEC is converted to ZEC available to users of the network
“We” - the ZIP authors, owners listed in the above front matter
“MAX_MONEY” is the ZEC supply cap. For simplicity, this ZIP defines it to be 21,000,000 ZEC, although this is slightly larger than the actual supply cap of the original ZEC issuance mechanism.
This ZIP describes the motivation, the necessary changes for, and the implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF is a proposed alteration to the block rewards system and accounting of unmined ZEC that allows for other sources of funding besides unissued ZEC. This new mechanism for deposits – that new applications or protocol designs can use to strengthen the long-term sustainability of the network – will likely 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.
The changes in this ZIP are ultimately minimal, only requiring for the node to track state in the form of a ZSF_BALANCE, and for a new transaction field to be added, called ZSF_DEPOSIT. While wallet developer would be encouraged to add the ZSF_DEPOSIT field to their UIs, no changes or new behavior are absolutely required for developers or ZEC holders.
The Zcash network’s operation and development relies fundamentally on the block reward system inherited from Bitcoin. This system currently looks something like this:
The Zcash Sustainability Fund is a proposed replacement to that payout mechanism, with the relevant parts in bold below:
ZSF_BALANCEZSF_DEPOSIT field. Thus, at Every New Block:
ZSF_BALANCEZSF_DEPOSIT amountThis design gives similar clarity and algorithmic control benefits, while also allowing other sources of funds for Block Rewards in addition to newly issued ZEC, via ZSF Deposits.
For example, an end-user wallet application could have an option to contribute a portion of a transaction to the ZSF, which would be included in a ZSF_DEPOSIT field in the transaction, to be taken into account by the Zcash nodes.
This ZIP is explicitly agnostic as to the recipients of block rewards so that acceptance or adoption of the Sustainability Fund does not introduce or bundle reallocation decisions with the primary proposal.
This quite simple alternation has – in our opinion – a multitude of benefits:
ZSF_BALANCE mechanism described below.Disclaimer 1: Long term success depends on the specific mechanisms of deposits, the quantities involved, and broader economic considerations. For such as if the payout rate is both sufficient and not excessive enough to threaten sustainability.
In practice, the Zcash Sustainability Fund is a single global balance maintained by the node state and contributed to via a single transaction field. This provides the economic and security support described in the motivation section, while also importantly keeping the fund payouts extremely simple to describe and implement.
The two modifications are:
ZSF_BALANCEZSF_DEPOSITPlease note that a network upgrade is required for this work to be fully implemented.
ZSF_BALANCE
Upon activation at height H, the ZEC issuance mechanism is permanently suspended, the value of ZSF_BALANCE[H] is set to the remainder of unissued ZEC. This must be done before the Block Rewards Payout Rule is enforced for the block at height H. This is not a pre-mine. This is simply a re-accounting of unissued ZEC that comes with the benefit of other possible sources of funding.
Consensus nodes are then required to track new per-block state:
ZSF_BALANCE[H] : u64 [zatoshi]The state is a single 64 bit integer (representing units of zatoshi ) at any given block height, H, representing the Sustainability Fund balance at that height, H. The ZSF_BALANCE can be calculated using the following formula:
TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS
This formula holds for all future blocks. It is safe and semantically consistent to consider all blocks prior to the activation height to have a value of 0 in this field. This is not required by this proposal but may be convenient in designs or implementations.
ZSF_BALANCE Requirements
ZSF_BALANCE SHOULD equal 0 for all blocks prior to the activation height H .TOTAL ZEC TO EXIST (MAX_MONEY) - CLAIMED BLOCK SUBSIDIES OF PAST BLOCKS + SUM OF ALL ZSF DEPOSITS FROM PAST TRANSACTIONS MUST hold for all future blocks.ZSF_DEPOSIT
Each transaction can dedicate some of its excess funds to the ZSF, and the remainder becomes the miner fee, with any excess miner fee/reward going to the ZSF.
This is achieved by adding a new field to all transactions:
ZSF_DEPOSIT : u64 [zatoshi]The ZSF_BALANCE[H] for a block at height H can be calculated given a value of ZSF_BALANCE[H-1] and the set of transactions contained in that block. First, the ZSF_DEPOSIT[H] is calculated based solely on ZSF_BALANCE[H-1]. This is subtracted from the previous block’s balance to be distributed as part of the block reward. Second, the sum of all the ZSF_DEPOSIT fields of all transactions in the block is added to the balance.
It is safe and consistent to treat older transactions using pre-Sustainability Fund formats as if they have this field implicitly present with a value of 0 where that simplifies designs or implementations.
Note: this field is not generally considered an “output” because it differs from other outputs in several significant ways:
ZSF_DEPOSIT fields contribute to a single global balance rather than a user-specific output state,ZSF_BALANCE[H] and do not need to track any transaction field specific state after this accounting in contrast to e.g. UTXOs which must be tracked until spent.ZSF_DEPOSIT Requirements
ZSF_DEPOSIT field per transaction.ZSF_DEPOSIT. ZIP 244 MAY be updated as well.All technical decisions in this ZIP are balanced between the necessary robustness of the
ZSF mechanics, and simplicity of implementation.
ZSF_BALANCE as node state
Tracking the ZSF_BALANCE value as a node state using the above formula is very simple in terms of implementation, and should work correctly given that the node implementations calculate the value according to the specifications.
Alternative: ZSF_BALANCE as block header commitment
An alternative to node state could be to include the ZSF_BALANCE field as a block header and require a block header commitment.
Requiring block-header-rooted commitments of global fund balances such as the Sustainability Fund ensures that any consensus deviating bugs in accounting of this balance are immediately detected in the earliest impacted block. It also removes some of the need for explorer sites and other analytics services from tracking this value independently, assuming the committed value is made available by common APIs. This helps ensure that all explorers track and report the correct value.
ZSF_DEPOSIT as explicit transaction field
An explicit value distinguishes the ZEC destined to Sustainability Fund deposits from the implicit transaction fee. Explicitness also ensures any arithmetic flaws in any implementations are more likely to be observed and caught immediately.
[1]: Key words for use in RFCs to Indicate Requirement Levels (RFC 2119: Key words for use in RFCs to Indicate Requirement Levels)
[2]: ZIP 200: Network Upgrade Mechanism (ZIP 200: Network Upgrade Mechanism)
[3]: ZIP 225: Version 5 Transaction Format (ZIP 225: Version 5 Transaction Format)
I believe it sounds interesting; but its not really that clear either. Can you define a fee structure that would work for everyone within the context of decentralizing development and how the fees get paid and split up? For example, I know if I create an application that runs on iOS, apple is going to get 30% of the in app purchases and I get to keep 70%. Or, if I pay with my Visa at a retailer, the hardware provider might get 0.5%, Visa gets its share, and a few other in between all split of the 3% fee. Can you propose how your system would work in this context?
How much goes to
a) blockchain (the foundation)
b) L2 (in this case ECC/ZEC)
c) creator of the use case (eg the wallet creator)
d) ZEC holders
e) anyone else?
I am personally against any funding based on block rewards. I think the current block rewards framework was a useful tool in the infancy of ZEC; and eventually needs to go away (and the sooner the better). I am for a fee structure that is pushed down to the transaction level. So, for example, if ZEC has a wallet that generates fees, the creator of the wallet gets a cut. In this case, it would be ZEC. But even if third parties were able to generate gas/fees for creating products, ECC should get a cut of the fees for use of ZEC as well as the Foundation for use of the blockchain
Why not just keep the existing framework (and let it run off either naturally or sooner if POS is introduced), and build a gas/fee system that incentivizes 3rd party - self funded development where the foundation/ECC/ZEC holders get a cut of the gas and the third party keeps the majority of fees for taking the risk of development and pays for the ongoing maintenance?
Hi @jgx7. Thanks for your question. I think you’re confusing the Zcash Sustainability Fund (ZSF) with the Dev Fund. The ZSF introduces a new approach to issuing block rewards that enables the ability to deposit ZEC from the circulating supply into the ZSF to contribute to future block rewards. Once implemented, unissued ZEC would pay out to block reward recipients directly from the ZSF in a manner consistent with the current process, and with 80% allocated to the block miner and 20% distributed to existing Dev Fund recipients. It’s important to note that we’re not suggesting modifications to how the current disbursements are allocated or changes to existing fee structures. Those matters are for the community to decide. This change provides a mechanism to contribute ZEC to future block rewards through deposits into the ZSF. The deposits can be distributed over time to help sustain and secure the network.
The below thread is an active discussion about the Dev Fund that you might find interesting:
I don’t like block rewards as a mechanism to fund. I think the sooner it’s replaced by gas/transaction fees the better. Now if there was some type of way the gas is used to create a type of “treasury” acccount. then the treasury account is the source of funding; that starts to make more sense to me. But the current structure is not good for the ecosystem or making sure development is as focused on creating products people want as it could be. when the ecosystem is supported by gas/fees, it highly aligns development with creating products people want. and if developers don’t create the products people want, they have their own money at staked as opposed to someone else’s (eg zec holders) so this kind of sounds like another tax on zec holders.
hopefully i’m just not understanding the source of funding…
It’s starting to feel like the community is dominated by grant recipients as opposed to independent developers. i say no more centralized funds. My belief is ZEC holders are just voting by selling as opposed to trying to guide or vocalize the flaws in block rewards as a funding mechanism. Move to gas ASAP: the funds should come directly from gas. so if wallet A creates 1m in transactions and wallet B creates 1 in transactions, wallet A gets a direct slice of the fees based on its transactions. wallet B gets basically nothing no matter how much we like them. Block rewards funds both equally.
In my view Block Rewards is a total loser and will kill ZEC (there is no philosopher king here to make all the right decisions). So the next best alternative is a market based mechanism. Now block rewards was good in the beginning; but I strongly believe it will be bad in the end. No successful businesses survive based on issuing stock constantly to fund losses. And economically, that is what we have when there is no gas…Currently there is no objective measure of performance and that’s mainly due to the economics of the ecosystem, which is more like a centralized tax as opposed to free market mechanisms (which to me is gas based).
My laymen’s understanding is
I like the idea of the Posterity Fund, I’m just a bit skeptical that people will actually decide to fund it. It will end up being decided by whatever the wallets decide to be the default.
If I understand correctly. this is exactly what the Zcash Posterity Fund is. If 20% stops going to the dev fund, the ZPF would still keep existing, the only change is that would only be funded by people deciding to fund it when doing transactions, like the miner’s fee.