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

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

I think the solution here is somewhat simpler actually @tromer @aristarchus; if something like this gets adopted in we’d just need the Foundation board to vote to modify its purpose to include “disburse funding according to the results of [future voting mechanism].” I’m not concerned about making that work and agree it shouldn’t stop anyone from supporting it @aristarchus.


@tromer raised the following issues about this proposal on GitHub PR 276 that were not addressed in the merge:

Locking funds into the future is problematic from a security perspective. If the owner’s wallet is compromised, or a security-related movement of funds becomes desirable (e.g., consider the Sprout bug), then the owner would be unable to move their funds to protect them.

Additional considerations are discussed at Decentralized Participatory Voting through VESTING .

So it may make sense to weaken these requirements leaving them up to future community discussion.

and also, in response to the text “Because I share the foundation’s concern that the ECC could be “beholden to its shareholders”, I am mandating that the ECC should be working in the service of the Zcash community and shall serve no other masters. The original investors/founders who are not still working in the service of the Zcash community should not have control over the use of the new dev funds.”:

Under ECC’s current structure, I think the first requirement is impossible to meet as phrased: as a partnership, ECC is inherently “beholden to its shareholders”, and its board is determined by shareholders. Here’s an idea for alternative phrasing (jointly for these two requirements):

ECC must undertake a firm obligation to use the Dev Fund only in support of the Zcash cryptocurrency and its community, and to not distribute the Dev Fund proceeds to its partners (“shareholders”), other than

  1. In fair compensation for ongoing work
  2. For covering pass-through tax obligations to partners caused by ECC’s receipt of the Dev Fund

This obligation must be made irrevocable within ECC’s corporate governance (i.e., its Operating Agreement and Board of Directors), and backed by a contractual obligation to the Zcash Foundation.

Addressing this was beyond the scope of my editing role, so I left it as-is for now, but I agree there is a problem.


Thanks, @daira, for keeping track!

@aristarchus, note that my Dev Fund to ECC + Zfnd + Major Grants proposal also addresses these two points, so the phrasing there (which fleshes out my suggestions above) may prove useful.

See the Future Community Governance section and the ECC slice (Electric Coin Company) sections there.

I’m in favor of a creating voting mechanisms. However, I have fundamental concerns about coin-holding-time-weighted voting. And also, security concerns about the version where coins are locked in advance. The public discussion of this, so far, hasn’t convinced me that the downsides are acceptable. So at present, I don’t support committing to this voting method as the sole means of deciding dev funding in the future. The aforementioned Future Community Governance section in my proposal is the strongest version I could come up with that leaves the requisite flexibility.


I agree @tromer raised some good points that will need to be addressed in detail if this proposal is selected by the community. I still personally believe that coin holder voting is a good idea and can be made workable. In the case of security issue like the sprout bug, I would expect there would be some way to deterministically move funds into new safe voting addresses. That is to say we could have a method derive new safe addresses from the unsafe old ones.

As far as legal requirements for the ECC go, if this proposal is accepted then I agree that it would probably require some contractual agreements to ensure the ECC is only working on behalf of ZEC holders, as this proposal mandates.


Another comment from @tromer on Github:

“What does “a stake in upside of the success of Zcash” mean? Simply paying some of the salaries in ZEC? Since ZEC can be easily converted to/from other currencies, and the receipt of ZEC is anyway taxable, I’m not sure what this requirement achieves other than headaches.”

I did not intend to mean that salaries should be paid in ZEC. I just wanted so make the ECC team financially incentivized to want the price of ZEC to go up. The mechanism to do this is not specified…I’m thinking of a couple different ways we could do this…


This proposal has been published as ZIP 1003.