ZIP: 1012 Title: Dev Fund to ECC + ZF + Major Grants Owner: Eran Tromer <firstname.lastname@example.org> Status: Obsolete Category: Consensus / Process Created: 2019-11-10 License: MIT Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-dev-fund-to-ecc-zfnd-major-grants/35364>
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:
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 (ZF), and the many entities funded by the ZF 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.
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 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.
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:
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).
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:
(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.
This slice of the Dev Fund will flow to ZF, 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.
ZF may award grants as profit-sharing contracts, in which case any resulting profits will be added to the ZF-GU slice (to fund its ongoing operations and any future 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 ZF. ZF will disburse them as "Major Grants", within the framework of ZF's grant program but subject to the following additional constraints:
ZF shall recognize the ZF-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 ZF 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 ZF-GU slice (where they also compete with other ZF activities), whereas large long-duration will be funded from the dedicated ZF-MG slice; though this is at ZF's discretion.
ZF shall strive to define target metrics and key performance indicators, and utilize these in its funding decisions.
It may be deemed better, operationally or legally, if the Major Grant funds are not accepted and disbursed by ZF, but rather directly assigned to the grantees. Thus, the following mechanism may be used in perpetuity, if agreed upon by both ECC and ZF 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 ZF 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.
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' recipient.
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 ZF, 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).
ECC, ZF and Major Grant recipients (during and leading to their award period) shall all accept the following obligations:
Ongoing public reporting requirements:
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, ZF and Major Grant recipient will be focused primarily (in their attention and resources) on Zcash. Thus, they must promptly disclose:
ECC, ZF 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 ZF'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 ZF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to ZF.
ECC and ZF 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 ZF-MG (whose integrity is legally protected by the Restricted Fund treatment).
Decentralized community governance is used in this proposal in the following places:
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 ZF should place high priority on such development and its deployment, in their activities and grant selection.
ZF should formally integrate robust means of decentralized community voting into its Board of Director elections, in a way that is consistent with ZF's mission and values. ZF should lead the process for determining and implementing this, legally and technically, by the end of 2021.
Members of ZF'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
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's 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 and forum users @aristarchus and @dontbeevil for valuable initial comments on this proposal.