[ZIP 1003] Dev Fund Proposal: 20% split between the ECC and the Foundation

no, i didn’t yet …

1 Like

hey @aristarchus do you think your proposal is better and/or more fair then others suggested?
would you consider withdrawling your proposal?

1 Like

Hi @johnwisdom,

If I didn’t think my proposal was good I wouldn’t be advocating for it.

Why don’t you give me some specific criticisms rather than ask me to withdraw it? That would be more constructive.

1 Like

@johnwisdom First of all I believe that anyone should be able to make a proposal. You are trying to attack people making proposals and that is an attack on this whole process.

Not that is any of your business, but I have been following Zcash since I first read about in Wired in 2016 (months before it launched!). I have owned zec for years and I even run a node. Not everyone who follows and invests in Zcash is active on this forum.

I understand you are concerned about your investment, but I and many others also have invested in zec, and I simply disagree with you about the best way to make zcash better with a dev fund. You and others (mostly miners) are advocating to limit dev fund spending so that miners will receive more zec. I believe that this is short sighted and I am trying to maximize the value of zec over a multiyear timescale while miners often need to make a ROI in a matter of months.

I am truly trying to make zcash better, and it is fine to disagree with my ideas. It’s not ok to say that some ideas are illegitimate because of who you think is proposing them. I’m going to continue to advocate for whatever I think is best for zcash and I’m not going to be bullied into silence.

To answer your question, I do like my proposal the best so far, but I am open to suggestions from anyone to make it better. There are aspects of the Dev Fund Proposal: 20% to a 2-of-3 multisig with community-involved governance proposal that I and several others have already expressed concern about, but I am open to it if they can address the concerns raised.


I have absolutely zero affiliation with the ECC or the Foundation. I’ve never even met zooko. Not going to respond to any more attacks on my motivations for trying to make a good proposal.

I’ve written a lot already about why I believe having a substantial dev fund is good for zec. I do want a large dev fund because there is a lot of things that software engineers can build to make zec better. There is not a fixed set of things to achieve for zec, it can always be made much better with more engineering work.

The onus is on miners to explain why we need to decrease the dev fund substantially just to pay a little more for security.

You could read what I wrote above in my proposal too:

  1. 20% is a large enough percentage that there should be enough dev funding for many different Zec price scenarios. To those who want to decrease this percentage: Overpaying for security is a gift to miners, to the detriment of every other stakeholder in the Zcash community. I will even make the strong statement that intentionally overpaying the miners for security is stealing from the other stakeholders.

Just my personal opinion, but that’s one thing i absolutly agree with. Nobody should be bullied or silenced or forced to withdraw a proposal, no matter how abstract, unlogical ot whatever it might look in the personal view of the reader.

Daniel, i again can only say that i understand absolutly where you are coming from, what your intentions are and that i agree with a lot of the logic behind it. I really like you, believe me, but personal attacks are not doing any good here.

And again a reminder that any proposal has it’s place, even if a Monero guy is suggesting that 20% of the dev fee should go to the Monero Foundation, lol.
The important part is that a fair vote by the community is done and i think most of us should focus on this part as this is the important part where decisions are made, proposals are choosen or not.
If the decision making part is corrupted or flawed it doesn’t matter at all what kind of proposals we all make or how they are argumented.

I hope you take this as a friend-to-friend advice made with best intention and not as a personal attack!


I do and I know of my wrong doing. I won’t be posting anymore in this thread, if @moderators feel it’s better to erase my comments so be it.


That’s not my intention to keep you from asking questions or questioning a proposal, but it should not contain personal attacks. I know it’s a hard line and i myself cross it from time to time or walk borderline. There is enough room to ask a question why it should be $1.1M and not $700k for example, or whatever questions but no author of any proposal should be feeling bullied, forced, attacked or whatever. Maybe i’am very sensible as being myself part of such attacks. I just don’t want to see you get a warning, flagged posts or such.


@johnwisdom Personal attacks against the contributor of a ZIP are out of line.

Everyone is free to discuss the merits of a ZIP, the details are important.

However, personal attacks against the person’s motivation, character, and accusations of somehow colluding with ECC or Foundation with zero evidence is not acceptable.


@daira and I made an initial review pass over this PreZIP. This is not a formal part of the proposal process (in particular, @daira is not acting in hir role as ZIP editor); this is just a joint comment between @daira and myself on the current state of the PreZIP.

Overall this looks reasonable, but needs to be formatted as a ZIP draft. See the ZIP guide for details.

This is ambiguous as to the split. It should specify whether this is an even split, or what the intended percentages are.

It is ambiguous what this means for the consensus rules after the second halving, i.e. the default case if no subsequent NU changed the issuance rules. The above two sentences could be interpreted as:

  • No dev fund allocation in consensus rules from the second halving, and a requirement by this ZIP to implement a dev fund with a voting mechanism in a subsequent NU.
  • 20% dev fund allocation in consensus rules from the second halving (i.e. leaving in place the system in this ZIP), and a requirement by this ZIP to implement a voting mechanism in a subsequent NU to allocate the funds.

This should become / go in the Rationale section.

These would be good subsections of the Specification.

The phrase “even indirectly” makes this too strong; in particular, some employees and contractors are also founders or shareholders of the ECC, and this wording would prevent them from being paid for their work. We don’t think this is the intent of the requirement, so it needs to be reworded.


First of all really good work going through all proposals and make comments. Good job!

While so far all comments on all the proposals you comment are are clearly understandable i have some problems with this one:

  • If an employee is as well a founder or shareholder he gets his wage as an employee, not? I think the proposal is clear that wages are ok, but not additional rewards to founders/shareholders or does he just have to add “additional rewards beside the wage” to make it confirm?
1 Like

There is some context provided at the top which suggests this (hence why we didn’t think the intent of the requirement was to prevent the proper compensation of employees and contractors for their work). However, the wording of the requirement itself (which would be part of the actual specification) does not make that distinction, and that combined with the “even indirectly” is what causes the problem. The requirement could be amended in several ways to address this, such as folding the context into the specification itself.


In theory it shouldn’t matter what the ‘default’ case is, since the intention to have the dev fund after the second halving be voted on by coin holders. It seems the issue is what should the code say happens if somehow a dev fund voting system is not implemented by the second halving? In that case, which I would consider to be a violation of the mandate, I would not want either the ECC, the foundation, or the miners to have any incentive to say ‘let’s just go with the default since a voting system isn’t ready.’ So how about the setting the default case, in the event that the voting system isn’t implemented, to be to burn the 20% of funds intended to go to the ‘voting dev fund’.

How about this?

The revenue received from the Dev Fund should not be used to give further rewards to, even indirectly, the investors, founders, or shareholders of the ECC, who are not working on Zcash after the second halving.

1 Like

Adding this to the specification would resolve this issue, and also make it much clearer that this proposal has a strong requirement for a funding system after the second halving.

The proposal starts from the first halving, so the addition would need to be “after the first halving.” Otherwise yes, this would address the raised issue.


Just out of curiousity, how do you define if someone works on Zcash or not?

For example is an advisor working on Zcash?
Is a founder being an advisor at the foundation working on Zcash?
Is a foundation member working on Zcash working on Zcash due your definition?
Is a shareholder not automaticly working on Zash just for being a shareholder of a company that works on Zcash?

Or how do you define work? Is someone doing a quick review on a Zcash issue for example working on it no matter it may take only 10 minutes a month? And so on.

By the way, just questions out of curiousity as it seems everything must be defined absolute exactly.


Good point. I’ll have to be a little more clear.

Shareholders are definitely not working on zcash just by owning shares.


It’s on GitHub now! https://github.com/zcash/zips/pull/276

1 Like

I’m going to change the part about a burn address, mostly because I agree with what zooko wrote here about having a predictable supply schedule: Protect the integrity of the monetary base supply schedule

So what should happen if there is no voting system ready by year 8? One simple idea is that the Foundation could hold the funds in escrow until the voting system is actually implemented. I’m changing the proposal to say that for now, but am open to other ideas if anyone wants to make a suggestion?


That’s a good direction. You can moreover posit that this will be a restricted donation, as @acityinohio did in his A Grand Compromise/Synthesis ZIP Proposal, to legally bind the foundation to make specific uses of these funds.

But there may be an issue with the Foundation’s non-profit status: once it has received a donation, it may be disallowed from disbursing it at the discretion of a voting mechanism, if that voting mechanism may decide to direct the funds outside the Foundation’s purpose and obligations.

Something inbetween is the Donor Advised Fund model, where the Foundation keeps the funds and is basically expected to use them as “advised” (in this case) by the vote, but will override the vote if incompatible with its (own judgment of) its obligations.


Ok, the Donor Advised Fund makes sense. @acityinohio do you think this would work for the Foundation? It is an edge case of this proposal that I hope we never see, because it would mean a voting system couldn’t be built with more than four years to plan. I don’t want this relatively small detail to prevent anyone from supporting this proposal.

1 Like