Dev Fund Proposal: Dev Fund to ECC + Zfnd + Major Grants

I submit the following Dev Fund proposal, forking off @mhluongo’s Decentralizing the Dev Fee.

Also filed as ZIP pull request 291. I’ll keep these consistent. See change log at bottom.

Dev Fund to ECC + Zfnd + Major Grants


This proposal describes a structure for a the Zcash Development Fund, to be enacted in Network Upgrade 4 and last for 4 years. This Dev Fund would consist of 20% of the block rewards, split into 3 slices:

  • 35% for the Electric Coin Company
  • 25% for Zcash Foundation (for internal work and grants)
  • 40% for additional “Major Grants” for large-scale long-term projects (decided by the Zcash Foundation, with extra community input and scrutiny)

Funding is capped at $700k/month per slice. Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged.


Starting at Zcash’s first halving in October 2020, by default 100% of the block rewards will be allocated to miners, and no further funds will be automatically allocated to research, development and outreach. Consequently, no substantial new funding may be available to existing teams dedicated to Zcash: the Electric Coin Company (ECC), the Zcash Foundation (Zfnd), and the many entities funded by the Zfnd grant program.

There is a need to strike a balance between incentivizing the security of the consensus protocol (i.e., mining) versus other crucial aspects of the Zcash security and functionality, such as development and outreach.

Furthermore, there is a need to balance the sustenance of ongoing work by the current teams dedicated to Zcash, with encouraging decentralization and growth of independent development teams.

Difference from Matt Luongo’s proposal

This proposal is based on Matt Luongo’s Decentralizing the Dev Fee proposal, which has similar motivations. The major changes are as follows:

  • The Dev Fund slice intended for external recipients (beyond ECC, Zfnd and existing Zfnd grants) may be used to fund ECC if no competitive alternatives present themselves, to mitigate unwarranted loss of existing capabilities.
  • For simplicity, the above slice is combined with the Foundation’s existing grant system; but is accompanied by explicit requirements to achieve its goals, independent advisory input, and a Restricted Funds mechanism to enforce these requirements.
  • The “easing function” coin value cap is removed, in favor of capping each slice at $700k/month funding target. Any excess is kept in a reserve, from which it can be withdrawn only to maintain the funding target in the future.
  • Strengthened the transparency and accountability requirements, and harmonized them across ECC, Zfnd and major grantees.
  • Removed Zfnd’s supervisory role in determining the “principal developer”, fixing it to be ECC (changing this would be sufficiently dramatic to merit a fork).
  • Small differences in prescribed changes to the Zfnd board.
  • Call for, and incentivize, development of decentralized voting and governance.
  • Clarity and brevity.


The Dev Fund should encourage decentralization of the work and funding, by supporting new teams dedicated to Zcash.

The Dev Fund should maintain the existing teams and capabilities in the Zcash ecosystem, unless and until concrete opportunities arise to create even greater value for the Zcash ecosystem.

There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.

Major funding decisions should be based, to the extent feasible, on inputs from domain experts and pertinent stakeholders.

The Dev Fund mechanism should not modify the monetary emission curve (and in particular, should not irrevocably burn coins).

In case the value of ZEC jumps, the Dev Fund recipients should not be allowed to wastefully use excessive amounts of funds. Conversely, given market volatility and eventual halvings, it is desirable to create rainy-day reserves.

The Dev Fund mechanism should not reduce users’ financial privacy or security. In particular, it should not cause them to expose their coin holdings, or to maintain access to secret keys for much longer than they would otherwise. (This rules out some forms of voting, and of disbursing coins to past/future miners).

The new Dev Fund system should be simple to understand and realistic to implement. In particular, it should not assume the creation of new mechanisms (e.g., election systems) or entities (for governance or development) for its execution; but it should strive to support and use these once they are built.

Comply with legal, regulatory and taxation constraints in pertinent jurisdictions.


General on-chain governance is outside the scope of this proposal.

Rigorous voting mechanism (whether coin-weighted, holding-time-weighted or one-person-one-vote) are outside the scope of this proposal, though there is prescribed room for integrating them once available.


Dev Fund allocation

Starting at the first Zcash halving in 2020, until the second halving in 2024, 20% of the block rewards will be allocated to a “Dev Fund” that consists of the following three slices:

  • 35% to the Electric Coin Company (denoted ECC slice)
  • 25% to the Zcash Foundation, for general use (denoted Zfnd-GU slice)
  • 40% to the Zcash Foundation, for major grants (denoted Zfnd-MG slice)

Details below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address in each block. This Dev Fund will end at the second halving (unless extended/modified by a future ZIP).

ECC slice (Electric Coin Company)

This slice of the Dev Fund will flow to ECC.

ECC must undertake a firm obligation to use the Dev Fund only in support of the Zcash cryptocurrency and its community.

In particular, ECC must commit to not distribute the Dev Fund proceeds to its partners (“shareholders”), other than:

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

(ECC is encouraged to transition to a corporate structure that would avoid the latter taxes.)

This obligation must be made irrevocable, e.g., within ECC’s corporate governance structure (i.e., its Operating Agreement) or contractual obligations.

Zfnd-GU slice (Zcash Foundation, for general use)

This slice of the Dev Fund will flow to Zfnd, to be used at its discretion for any purpose within its mandate to support Zcash and financial privacy, including: development, education, support community communication on-line and via events, gathering community sentiment, and external awarding grants for all of the above.

Zfnd may award grants as profit-sharing contracts, in which case any resulting profits will be added to the Zfnd-GU slice (to fund its ongoing operations and any future grants).

Zfnd-MG slice (Zcash Foundation, for major grants)

This slice of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of Zcash ecosystem, to the extent that such teams are available and effective.

The funds will be received and administered by Zfnd. Zfnd will disburse them as “Major Grants”, within the framework of Zfnd’s grant program but subject to the following additional constraints:

  1. These funds may be only be used to issue Major Grants to external parties that are independent of Zfnd. They may not be used by Zfnd for its internal operations and direct expenses.

  2. Major Grants should support well-specified work proposed by the grantee, at reasonable market-rate costs. They can be of any duration, or ongoing without a duration limit, but have semiannual review points for continuation of funding.

  3. Major Grants may be issued to ECC only if no other parties are available and capable of performing the specified work with similar effectiveness and cost. (The intent is that eventually ECC will not receive Major Grants.)

  4. Priority will be given to Major Grants that bolster new teams with substantial (current or prospective) continual existence, and set them up for long-term success, subject to the usual grant award considerations (impact, ability, risks, team, cost-effectiveness, etc.). Priority will be given Major Grants that support ecosystem growth by mentorship, coaching, technical resources, creating entrepreneurial opportunities, etc.

  5. Major Grants should specifically further the Zcash cryptocurrency and its ecosystem; this is more restrictive than Zfnd’s general mission of furthering financial privacy.

  6. Major Grants awarding is subject to individual approval by Zfnd’s Board of Directors, by a majority excluding any members with a conflict of interest.

  7. Zfnd shall seek advisory input on its choice of Major Grant awards, by all effective and reasonable means (e.g., on-line discussion forums, the community Advisory Board, on-chain voting by holders and miners, and proactive consultation with experts). The Zfnd Board of Directors shall strive to follow this advisory input (within the confines of the Foundation’s charter and duties).

  8. Zfnd shall strive to create an independent grant committee to evaluate and publicly recommend Major Grant proposals, based on the committee’s expertise and the above inputs.

Zfnd shall recognize the Zfnd-MG slice of the Dev Fund as a Restricted Fund donation under the above constraints (suitably formalized), and keep separate accounting of its balance and usage under its Transparency and Accountability obligations defined below.

From grant proposers’ side, proposals for such grants will be submitted through Zfnd usual grant process, allowing for public discussion and public funding. It is intended that small one-time grants will be funded by drawing on the Zfnd-GU slice (where they also compete with other Zfnd activities), whereas large long-duration will be funded from the dedicated Zfnd-MG slice; though this is at Zfnd’s discretion.

Zfnd shall strive to define target metrics and key performance indicators, and utilize these in its funding decisions.

Direct-grant option

It may be deemed better, operationally or legally, if the Major Grant funds are not accepted and disbursed by Zfnd, but rather directly assigned to the grantees. Thus, the following mechanism may be used in perpetuity, if agreed upon by both ECC and Zfnd before NU4 activation:

Prior to each Network Upgrade, the Foundation shall publish a list of grantees’ addresses and the total number of Dev Fund ZEC per block they should receive. ECC and Zfnd shall implement this list in any implementations of the Zcash consensus rules they maintain. This decision will then be, effectively, ratified by the miners as the network upgrade activates.

Funding Target and Volatility Reserve

Each Dev Fund slice has a Funding Target, initially US $700,000 for each slice. At the end of each calendar month, the fair market value of the Dev Fund ZEC received during that month will be computed, and the excess over the Funding Target will be put into a dedicated Volatility Reserve account by the funds’

Funds may be withdrawn from the Volatility Reserve account only by that same party, in months where the aforementioned monthly ZEC value falls short of the Funding Target, and only to the extent needed to cover that shortfall.

The Volatility Reserve may be kept as ZEC, or sold and held as fiat currency or investments (whose profits will remain in the Volatility Reserve).

The Funding Target may be changed only by unanimous agreement of Zfnd, ECC and the majority vote of a voting mechanism weighted by ZEC coin holding. (This is meant to encourage the creation of such a voting mechanism. Moreover, in case of excessive accumulation of reserves, the community can condition an increase of the Funding Target on the redirection of some of the reserves to a different entity, miners or an airdrop).

Dev Fund ZEC that has been received, not placed in the Volatility Reserve, and has not yet been used or disbursed, will be kept by the corresponding party (as ZEC, or sold and invested) for later use under the terms of the corresponding slice.

Irrevocable obligations to the above must be made by the recipients (e.g., using their Operating Agreements or by receiving the slice as Restricted Funds).

Transparency and Accountability


ECC, Zfnd and Major Grant recipients (during and leading to their award period) shall all accept the following obligations:

Ongoing public reporting requirements:

  • Quarterly reports, detailing future plans, execution on previous plans, and finances (balances, and spending broken down by major categories).
  • Monthly developer calls, or a brief report, on recent and forthcoming tasks. (Developer calls may be shared.)
  • Annual detailed review of the organization performance and future plans.
  • Annual audited financial report (IRS Form 990, or substantially similar information).

These reports may be either organization-wide, or restricted to the income, expenses and work associated with the receipt of Dev Fund.

It is expected that ECC, Zfnd and Major Grant recipient will be focused primarily (in their attention and resources) on Zcash. Thus, they must promptly disclose:

  • Any major activity they perform (even if not supported by the Dev Fund) that is not in the interest of the general Zcash ecosystem.
  • Any conflict of interest with the general success of the Zcash ecosystem

ECC, Zfnd and grant recipients must promptly disclose any security of privacy risks that may affect users of Zcash (by responsible disclosure under confidence to the pertinent developers, where applicable).

ECC’s reports, and Zfnd’s annual report on its non-grant operations, should be at least as detailed as grant proposals/reports submitted by other funded parties, and satisfy similar levels of public scrutiny.

All substantial software whose development was funded by the Dev Fund should be released under an Open Source license (as defined by the Open Source Initiative), preferably the MIT license.


For grant recipients, these conditions should be included in their contract with Zfnd, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to Zfnd.

ECC and Zfnd will contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other party to issue a modified version of Zcash node software that removes the violating party’s Dev Fund slice, and use the Zcash trademark for this modified version. The slice’s funds will be reassigned to Zfnd-MG (whose integrity is legally protected by the Restricted Fund treatment).

Future Community Governance

Decentralized community governance is used in this proposal in the following places:

  1. As advisory input to the Zfnd-MG slice (Zcash Foundation, for major grants).

  2. For changing the Funding Target and Volatility Reserve (which is an
    incentive for ECC and Zfnd to create the voting mechanism).

  3. In Zfnd’s future board composition (see below).

It is highly desirable to develop robust means of decentralized community voting and governance, and to integrate them into all of the above processes, by the end of 2021. ECC and Zfnd should place high priority on such development and its deployment, in their activities and grant selection.

Zfnd Board Composition

Zfnd should formally integrate robust means of decentralized community voting into its Board of Director elections, in a way that is consistent with Zfnd’s mission and values. Zfnd should lead the process for determining and implementing this, legally and technically, by the end of 2021.

Members of Zfnd’s Board of Directors must not hold equity in ECC or have current business or employment relationships with ECC.

Grace period: members of the board who hold ECC equity (but do not have other current relationships to ECC) may dispose of their equity, or quit the Board, by 1 March 2021. (The grace period is to allow for orderly replacement, and also to allow time for ECC corporate reorganization related to Dev Fund receipt, which may affect how disposition of equity would be executed.)


The author is

  • a coauthor of the Zerocash academic paper underlying Zcash
  • a technical adviser to the Zcash Foundation
  • a founding scientist, a shareholder, and formerly a technical adviser to the
    Electric Coin Company
  • an academic researcher and adviser to various other organizations

This proposal is his private opinion and does not represent any of the above.


This proposed is most closely based on the Matt Luongo Decentralizing the Dev Fee proposal, with substantial changes and mixing in elements from @aristarchus’s 20% split between the ECC and the Foundation proposal, Josh Cincinnati (@acityinohio) A Grand Compromise/Synthesis ZIP Proposal proposal and extensive discussions in the Zcash Community Forum. The author is grateful to all of the above for their excellent ideas and many insightful discussions, and to Howard Loo (@hloo) and forum users @aristarchus and @dontbeevil for valuable initial comments on this proposal.

Change log

2019-11-12 14:48 UTC: improved forum rendering (no content change)

2019-11-14 08:48 UTC: Made the following changes, following community discussions and forum polls:

  • Dev Fund will last for 4 years, and terminate at the 2nd halving in 2024, rather than continuing in perpetuity.
  • Forbid ECC equity holders from serving on Zfnd’s Board of Directors.
  • Zfnd should formally integrate robust means of decentralized community voting into its Board of Director elections by 2021.
  • Major Grants are no longer limited in duration, and can be ongoing, but have semiannual review points.
  • Require ECC and Zfnd to publish “grant proposals” and reports that are at least as detailed as other Dev Fund recipients.
  • Strive for metrics and KPIs in funding decisions.
  • Clarify that Volatility Reserve investment profits stay in it, and remove the investment constraints.
  • Discussed profit-sharing provisions in grants.
  • Another grant priority: supporting ecosystem growth.

2019-11-15 10:59 UTC: Made the following changes:

  • Changed slice percentages from third-third-third to 35% ECC, 25% Zfnd-GU, 40% Zfnd-MG (harmonizing with Matt Luongo’s updated proposal).
  • Updated the comparison to Matt Luongo’s proposal.
  • Minor/typo tweaks.

One point I’m unsure about is what should happen by default after 4 years (in the 2024 halving). @mhluongo’s proposal intentionally kept this open, but I feel that the ZIP must be well-specified and define what the consensus code will do by default.

So in my proposal I took the easiest path and made the Dev Fund perpetual until changed by a new ZIP. But it would not be unreasonable to switch this over: stop funding after 4 years unless reinstated by a new ZIP.



I think it should expire.

Four years is a very long time in crypto & the reasons for the initial funding to expire are just as valid today. Just my humble opinion.

Having said that, I like this proposal :slight_smile:


What should happen by default to the Dev Fund instated by this proposal?

  • Stop this Dev Fund in 2024
         (unless reinstated by a new ZIP)
  • Continue this Dev Fund in perpetuity
         (unless stopped by a new ZIP)

0 voters

Edit: Note that “in perpetuity” is still subject to the block reward halving schedule (being a fixed percentage), so it diminishes over time.


I like the way this thread is going. these votes help. makes me think there might be a way to join stuff.

I’d like to know what @mhluongo thinks of this and @ttmariemia - Removing governance is good. imho.

Although, can you explain how extending the emission curve would compromise security of users in a similar manner that making them keep their private keys from xyz past period would.




I voted to stop the dev fund in 2024, but only because I believe a dev fund that would continue into perpetuity should not favor any particular organization.

I would support a perpetual dev fund where no one organization is given any special status in the protocol.

Overall I like this proposal. :slight_smile:


Extending the emission curve is not a security problem (and I didn’t mean to imply that).

But there are widespread objections to changing the emission curve (most recently, @zooko’s), and there are also implementation problems with changing the emission rate depending on external events like ZEC/USD price.


The only issue I have is whether or not the removal of the trust component better serves the interest of the project. It is the removal of basically the only failure point in the funding Stream and essentially is one less thing. However I think that the preemptive nature of the zcash Foundation directly allocating funds to itself could be perceived or, if not, even misperceived as a conflict of interest whereas with the trust model creates a higher level of required contractual accountability between all parties. I think this also embodies the spirit of the project better as far as “attempt to comply” is concerned.

Other than that I do agree the Perpetual fund should not intrinsically continue and that’s kind of based on that it should be absolutely no less hard than this has been to do.

Note that even if we keep the “in perpetuity” phrasing, it’s still a percentage of the block rewards. So it’s still subject to the halving of block rewards, and thus diminishes over time, eventually to zero. Just very slowly. So it’s a matter of pace.

As proposed by @ChileBob in Continued from block rewards with a halving schedule, it’s also possible to decouple the two and have the Dev Fund shrink faster than the block reward.

How can this happen without on-chain governance?

I’m still working through this, and will have a full response. One question though

I’m quite surprised we disagree here. The requirement to change the board was based on the fact that the ECC and the ZF should be arms-length entities. The ZF board being composed of ECC shareholders is completely inappropriate going forward, in my opinion; and I believe your concerns can be addressed otherwise, by the ZF proposing a transition plan that takes into account board churn and the technical difficult of a coin vote.

Very interested in your rationale here @tromer

My proposal is meant to strengthen this. Your proposal would have 1 seat for the “principal developer” (ECC), whereas my version removes the ECC representative, and moreover specifies that if other board members have a CoI when voting about a Major Grant (as would be the case for ECC shareholders voting for a grant to ECC) then they’ll be excluded from the vote.

Now, we could just decree a blanket ban on all ECC shareholders/representatives (which goes further than either of our proposals). I think it would be harmful, because factually, many of the best-informed and most-involved people in the community are “tainted” by some sort of ECC affiliation or historically-held stake (for their early role, or for some advising they did years ago); and it would be a shame to exclude all of them from the board pool.

1 Like

What I proposed is this, with a compromise that’s an explicit board seat and still required to sit out when there’s a CoI. I’d strongly suggest a blanket ban and removal of the explicit seat over allowing shareholders of recipients to sit on the ZF board.

There are easy fixes for this in the other direction – board members should divest ECC holdings if they want to keep sitting on the board. I prefer an orderly board refresh and a more “professional” board rather than one that’s so heavily weighted toward researchers and founders today, but either can happen in my proposal (or another) and give us two arms-length organizations.


@mhluongo, I think having an ECC representative on the Zfnd board is much worse. This representative would be there to represent ECC’s interests. Whereas people like @Matthewdgreen and @imichaelmiers, while they happen to historically hold ECC equity, are not representing ECC: they care about Zcash’s success first and foremost, and have been critical of ECC on many occasions.

As for divesting, I suppose that’s an option, if there’s adequate liquidity and appetite, and if the tax implications are manageable… I frankly don’t know.

1 Like

What ECC affiliates should be allowed to serve on the Zfnd board?

  • None. Zfnd board member must not hold ECC shares.
  • Zfnd board members may hold ECC shares, if disclosed and excluded from votes concerning ECC.
  • An explicit Zfnd board seat to ECC, but no other ECC shareholders.

0 voters

can you add an abstain/don’t know option please :slight_smile: because I voted against in the first poll, but im not so sure after thinking about it a bit more. there are arguments both ways.

For the perpetuity I kinda would like to see the code default to nothing, but it could also follow a halving schedule or something else. Im going to look over blocktowns proposal again. I am more flexible on this than I first thought I was.

It might be useful to let the ECC have a “get out” clause for example. where zec and zcash can continue without them. (sure I am thinking 8 years out) but it does feel like setting precedent with whatever decision is made now. (even though it isn’t meant to be)

@mistfpga, I can’t edit those polls, but I will add “I don’t have a strong opinion” option to future polls (what should these be?). In any case, when updating my proposal, I’ll weigh out-of-poll input like yours.


It does require some form of on-chain governance, which is why I chose to include a mandate in my proposal to build a voting system for future dev funds.

I think that anyone else with a dev fund proposal should consider adding a similar mandate, if they want a perpetual dev fund and they think that dev fund should not favor any particular organization. :slight_smile:


@aristarchus, I’d love to see a purely decentralized on-chain voting system. But I am not at all sure that a good one can be agreed on and technically implemented. That’s why my proposal is full of incentives and urging, but stops short of mandating the perhaps-impossible.

Oh I love on-chain governance theoretically, but I don’t think it’s a good differentiator for Zcash in the short term.