It’s important to consider the inflationary impact of block rewards in USD, not just ZEC. Currently, at $30, ZEC inflation generates about $40 million USD annually to support development and mining. This proposal reduce issuance by 20% through an Unissued Reserve. The remaining 80% is equally split between miners and development. This results in roughly $20 million for mining (versus the current $32 million). While this reduces miner rewards, I believe a declining ZEC price poses a greater long-term threat to network security. Focusing on governance, competition, and accountability offers the best chance to reach its full potential to drive adoption of Zcash and ZEC.
This ZIP GGuy proposal is like using quantum mechanics to calculate the fire time to fry a steak, but the steak is burnt. What kind of bullshit suggestion is?
Currently, the zcash team or some community members are very unfamiliar with blockchain and business operations, and are not even qualified to play in the blockchain field.
Emphasize that after this year’s halving, the development fund should disappear and should be 0
This is a very important point; we’ve got to be measuring the future paths for the ecosystem in the context of ZEC value (or in this case, annual ZEC issuance multiplied by price).
Aside: I’m surprised that the bully who is anonymously flagging my posts that involve mention of ZEC value, hasn’t flagged this comment too. So much for consistency of applying this new “Price Speculation” rule*
This proposal is like CIA undercover’s whose mission is to destroy zcash.
- You can’t ruin security like this
- You can’t ruin value of ZEC like this
There should be focus on creating value for ZEC, ZEC rising in price, that will solve all your issues as you’ll have all the needed funding.
Just destroying the dev tax as it was planned (important!), together with halving, NU6 and Josh in the lead, will let ZEC go nuclear up and you’ll have no troubles with funding or getting new talent with the ZEC you already have or will mine till the end of the dev tax in November.
Yes this actually addresses the concerns I brought up that are not necessarily mine but ones I’ve read over time here and in crypto twitter
What’s your thesis around removing funds for developers immediately rising the price of ZEC?
Will people donate ZEC to the Orgs that will have to liquidate it immediately after they chewed up their reserves?
If they are expecting the price to go up, why should they undo their ZEC positions to donate?
the belief that defunding development of a security critical project like a cryptocurrency protocol will make it more valuable seems delusional. Can you bring examples that actually prove this hypothesis of yours?
One follow up thought to @visefi223 's thesis.
Shall Orgs receive donations in other currencies than ZEC so they have to either spend the donation or buy ZEC with it?
I am in agreement with @daira 60% is way too much and would compromise security.
Zec does dominate the hash power available for equihash so there is capacity to increase it, and I am in favour of that but up to a maximum of 40% only.
I would also like to see a portion of the block reward of approximately 10% paid out to users holding funds in orchard pool until POS comes along to incentivize miners to not dump zec for btc and increase orchard adoption.
So my numbers would roughly be
60% miners
10% orchard fund holders
12% ECC
8% ZF
10% ZCG with a mandate to seek out explicit projects to fund rather than wait for people to apply for funding
Not sure how the community (holders) will feel about again activating dev funds after November.
But the idea by @zkcroc that a certain % of it would be distributed to Orchard fund holders is very appealing. It would 1) incentivize shielding ZEC, 2) incentivize holding ZEC, for both normal people and miners until the PoS activates. And since Orchard pool is very small at the moment, the initial APR, even if you gave only 10% of the dev fund here, would be astronomical => more people coming and shielding, hitting the news, more talk about PoS, etc. I think this way, the community would accept/swallow the dev fund again.
@zkcroc’s idea might actually be genius and bring us 1) significantly higher % of ZEC shielded, 2) more speculation and holding. The question is, why this hasn’t been brought up by someone already? It could be a temporary solution how to incentivize holders/miners before the PoS activates.
I don’t see how could this be implemented. How would it know where to send the ZEC to? Unless it would not directly send but allow Orchard holders to claim a % of the reward in each block based on the total Orchard pool at the time of that block. But there’s no way to know how much ZEC they hold unless in zero knowledge, and that would require changing the circuit and that totally won’t happen in time for the next halvening. (I could be totally wrong about all of this though)
Adding some historical context:
When the original dev fund discussions were happening there were 13 proposals which ended up as ZIPs 1001 to 1013. These were discussed and the community was polled on their preference. ZiP 1012 was the most popular and ZIP 1014 emerged from that which went through a number of revisions based on community feedback.
I don’t know if we need to repeat that process exactly, but I think it worked quite well so maybe a similar approach would help here. It would be good to see a number of proposals have their own threads (and become ZIPs), ranging from “remove all funding” to “keep it the same” to “increase it to 60%” etc.
Seeing as this is the 2nd halving I’d be inclined to call them ZIPs 2001, 2002 etc. but would leave that up to the ZIP editors/managers.
It seems like we have some differing opinions already in the forums so maybe we have the basis for a number of initial options already…
A possible method has been breifly discussed here
And here
I’m really liking this allocation. I’d even like to see 12% vs 10% to Orchard Fund Holders and 8% to ZCG vs 10%. I think we likely get a very substantial boost in the ZEC price such that the development fund ends up with more money (even though its less ZEC tokens). But more focused development, tigher spending controls, and better governance is critical. Especially towards establishing more trust.
The problem with the dev fund is that it went wildly off course with funding of non blockchain development activities. We need to get back to developing DeFi and core blockchain work. Too much media, videos, and even so far as funding third party projects (agoric, starkware) and investing in Eth, BTC etc etc…too many wallets, too much fluff spending. If the dev fund continues, we need to make sure its tied to better governance (coin weighted voting), and tighte controls on what development means (EG a min of 90% goes to engineering).
I’ll discuss mining concerns in a subsequent post.
@str4d Regarding Funding Streams hopefully the following description more clearly defines a numerator, denominator, start height, and end height for each of the streams. I’d be grateful to know if there is any ambiguity in my description.
Dev Fund allocation
To ensure the sustainable financing of Zcash Development, 60% of the block reward will be allocated to the Development Fund. This allocation, aimed at funding the Bootstrap Project, Zcash Foundation, and Zcash Community Grants, is designed to decrease by approximately 3% every 35064 blocks (~1 month). This reduction is calculated by multiplying the denominator in the split calculations below, starting at 1000, by 1.03^(blocks_since_halving / 35064) and rounding down the result. The Unissued Reserve’s calculation is an estimate and should be calculated at the leftover unallocated rewards. Beginning with the second Zcash halving in 2024, the development fund’s allocation for the ensuing 35064 blocks will be as follows:
- 240/1000 (24%) Unissued Reserve/Zcash Sustainability Fund (denoted UR slice);
- 266/1000 (26.6%) for the Bootstrap Project (denoted BP slice);
- 190/1000 (19%) for the Zcash Foundation, for general use (denoted ZF slice);
- 304/1000 (30.4%) for additional “Major Grants” for large-scale long-term projects
(denoted ZCG slice).
After 35064blocks the Dev Fund SHALL continue for another 35064blocks and be allocated as follows:
- 260/1030 (~26.21%) Unissued Reserve/Zcash Sustainability Fund (denoted UR slice);
- 266/1030 (~25.83%) for the Bootstrap Project (denoted BP slice);
- 190/1030 (~18.45%) for the Zcash Foundation, for general use (denoted ZF slice);
- 304/1030 (~29.51%) for additional “Major Grants” for large-scale long-term projects
(denoted ZCG slice).
This calculation will continue until the dev fund allocation effectively reaches 0. Implementations of this development fund SHALL use the numerators and denominators above to calculate the slice.
Can you give some justification about why you believe these three organizations deserve such a huge increase of their aquisition of ZEC issuance? (in spite of ongoing project/ deliverable underperformance)
As I’ve said thousands of times, giving away free money creates moral hazard, and it perverts the otherwise natural incentives of capitalist business behaviors/ decision making.
I understand that you have a totally different belief about this topic, so I’m asking for a clear explanation. (My guess is that you’re recommending this issuance % increase based solely on the fiscal bottom line/ in relation to perpetual ZEC value decay)
As others have also noted, if we step in this extreme direction to further centralize the distribution of ZEC, we risk severely breaking market faith in ZEC/ the project mission could be permanently damaged.
To the topic about speculating that this allocations change would cause the market to reprice ZEC upwards (?) I actually don’t disagree, I think that it is conceivable that the market would read ZEC as becoming significantly more scarce, if after the halving, the majoritiy of the ZEC emitted went directly into the treasuries of the big 3.
I’d also like to know your opinion about whether or not the NU6 ~contract should include limitations on block rewards recipients, to disallow them from taking their ZEC rewards and reinvesting them into competing crypto projects. (Agoric, StarkWare, Ethereum, Bitcoin, et al)
Has anyone laid out what the ramifications would be of letting the current dev fund expire in November and forcing the existing orgs to seek other funding sources until and if PoS actually comes to fruition?
With proper governance and controls, I believe there is a place for the Dev Fund. But, the Dev Fund was only meant to be a short term bridge to an ecosystem that is self sustaining and not based on inflation as a funding source over the long term. So if there is a dev fund, something like below makes the most sense to me.
I would like to see something like above that is tied to much tighter controls on uses of funds. No more blank check funding.
a) Scheduled critical projects where teams are forced to prefund future costs. Critical projects include POS (or other solution to reduce costs and improve processing speeds and scalability), ZSAs, Stablecoins, Programmability, Zcash blockchain improvements, coin weighted voting,and 1 Zcash wallet (Zashi) with a clear roadmap. No money can be spent on anything else until these and other core blockchain projects are fully funded.
b) A restriction on non critical blockchain spending such as marketing, videos, customer education (not developer to help build on the blockchain) and non engineering related expenses until POS is implemented, as well as ZSAs and stablecoins are brought to market and Zashi is fully functional and ready for prime time. If we had prefunded these projects, we would be in much better shape going into the halving. It is too early, sync times too slow, wallets not working well, and we are too far from realizing the vision to be spending on non critical development.
c) Restriction on funding third party projects.
d) Hedge 6 months of committed costs in USD only. No ability to fund any additional projects until the critical projects are fully funded regardless of which org is taking responsibility for the development. Hold funding in ZEC until projects are started.
e) Development and Implementation of a fee based structure so third party wallets can have a way to fund themselves and recover their funding from fees. This forces pepole to create products that have a payback and customers actually want to use as no one will invest their own money in products that have no payback. A fee based ecosystem so that gas/fees replace inflation. With more assets like ZSAs and stablecoins, this takes the burden off ZEC transactions as a sole source to fund mining and development.
f) Elimination of all non core projects that are not specifically related to the Zcash blockchain for DeFi purposes.
g) Cancellation of all non core projects that do not fit into the current vision, and where the grantee has not delivered on time.
It would help to list Critical Projects along with estimated costs. If everyone gets on the same page that dev fund is for development and we prefund the critical projects it removes substantial risk from orgs funding non critical projects (espeically those that are not Zcash development related of which there are still several large projects being funded outside the scope of Zcash blockchain)
I appreciate you bringing this up. This is a scenario that the community has to think about and let it sink in.
What if orgs have no dev fund whatsoever?
How many donations would they need to keep things as they are now? What would be the outcome of needing to take money from “investors” in order to have a budget that lets the Orgs keep operating?
How much weight will investors have in the Orgs’ roadmap and goals?
It is very important that Zcash leaders like @Dodger and @joshs talk about this. I think it’s critical input to be able to discuss the possible outcomes of going through the halving and deciding how to move forward in terms of development funding.
It’s not about making a “fear campaign”, all the scenarios have to be considered. I read people saying “there should not be a dev fund” and I don’t see a follow-up on what’s their idea of how that void would be filled.
Agree with this statement. Don’t know what are the right percentages, but the fact that there has to be good control, audit and accountability is crucial to start mending the relationship between dev fund recipient orgs and the community.