ZIP: 1014 Title: Establishing a Dev Fund for ECC, ZF, and Major Grants Owners: Andrew Miller <socrates1024@gmail.com> Zooko Wilcox <zooko@electriccoin.co> Original-Authors: Eran Tromer Credits: Matt Luongo @aristarchus @dontbeevil Daira-Emma Hopwood George Tankersley Josh Cincinnati Andrew Miller Status: Active Category: Consensus Process Created: 2019-11-10 License: MIT Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560> Pull-Request: <https://github.com/zcash/zips/pull/308>
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.
The term "network upgrade" in this document is to be interpreted as described in ZIP 200 6 and the Zcash Trademark Donation and License Agreement (4 or successor agreement).
The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. 2
"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric Coin Company, LLC.
"Bootstrap Project", also called "BP", refers to the 501(c)(3) nonprofit corporation of that name.
"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit corporation of that name.
"Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). 12
"Community Advisory Panel" refers to the panel of community members assembled by the Zcash Foundation and described at 11.
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.
This proposal describes a structure for 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 subsidies, split into 3 slices:
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 subsidies will be allocated to miners, and no further funds will be automatically allocated to any other entities. Consequently, no substantial new funding may be available to existing teams dedicated to furthering charitable, educational, or scientific purposes, such as research, development, and outreach: 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 crucial charitable, educational, and/or scientific aspects, such as research, 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.
For these reasons, the Zcash Community desires to allocate and contribute a slice of the block subsidies otherwise allocated to miners as a donation to support charitable, educational, and scientific activities within the meaning of Section 501(c)(3).
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 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, nor cause them 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 mechanisms (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.
Consensus changes implied by this specification are applicable to the Zcash Mainnet. Similar (but not necessarily identical) consensus changes SHOULD be applied to the Zcash Testnet for testing purposes.
Starting at the first Zcash halving in 2020, until the second halving in 2024, 20% of the block subsidy of each block SHALL be allocated to a "Dev Fund" that consists of the following three slices:
The slices are described in more detail below. The fund flow will be implemented at the consensus-rule layer, by sending the corresponding ZEC to the designated address(es) for 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 as charitable contributions from the Zcash Community to the Bootstrap Project, the newly formed parent organization to the Electric Coin Company. The Bootstrap Project is organized for exempt educational, charitable, and scientific purposes in compliance with Section 501(c)(3), including but not limited to furthering education, information, resources, advocacy, support, community, and research relating to cryptocurrency and privacy, including Zcash. This slice will be used at the discretion of the Bootstrap Project for any purpose within its mandate to support financial privacy and the Zcash platform as permitted under Section 501(c)(3). The BP slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.
This slice of the Dev Fund will flow as charitable contributions from the Zcash Community to ZF, to be used at its discretion for any purpose within its mandate to support financial privacy and the Zcash platform, including: development, education, supporting community communication online and via events, gathering community sentiment, and awarding external grants for all of the above, subject to the requirements of Section 501(c)(3). The ZF slice will be treated as a charitable contribution from the Community to support these educational, charitable, and scientific purposes.
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 the Zcash ecosystem, to the extent that such teams are available and effective.
The funds SHALL be received and administered by ZF. ZF MUST disburse them for "Major Grants" and expenses reasonably related to the administration of Major Grants, but subject to the following additional constraints:
The Major Grant Review Committee's decisions relating to the allocation and disbursement of funds from the Discretionary Budget will be final, requiring no approval from the ZF Board, but are subject to veto if the Foundation judges them to violate U.S. law or the ZF's reporting requirements and other (current or future) obligations under U.S. IRS 501(c)(3).
ZF SHALL recognize the 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.
ZF SHALL strive to define target metrics and key performance indicators, and the Major Grant Review Committee SHOULD 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 for some or all grantees, if agreed upon by both ECC and ZF before Network Upgrade 4 (Canopy) 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.
BP, ECC, ZF, and Major Grant recipients (during and leading to their award period) SHALL all accept the obligations in this section.
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. As BP is the parent organization of ECC it is expected they may publish joint reports.
It is expected that ECC, ZF, and Major Grant recipients will be focused primarily (in their attention and resources) on Zcash. Thus, they MUST promptly disclose:
BP, ECC, ZF, and grant recipients MUST promptly disclose any security or privacy risks that may affect users of Zcash (by responsible disclosure under confidence to the pertinent developers, where applicable).
BP's reports, 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 5), 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.
BP, ECC, and ZF MUST 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 MG (whose integrity is legally protected by the Restricted Fund treatment).
Decentralized community governance is used in this proposal via the Community Panel as input into the Major Grant Review Committee which governs the MG slice (Major Grants).
It is highly desirable to develop robust means of decentralized community voting and governance –either by expanding the Community Advisory Panel or a successor mechanism– and to integrate them into this process by the end of 2021. BP, ECC, and ZF SHOULD place high priority on such development and its deployment, in their activities and grant selection.
Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current business or employment relationships with ECC, except as provided for by the grace period described below.
Grace period: members of the ZF 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 November 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 Zcash Foundation SHOULD endeavor to use the Community Advisory Panel (or successor mechanism) as advisory input for future board elections.
This proposal is a limited modification of Eran Tromer's ZIP 1012 10 by the Zcash Foundation, the ECC, further modified by feedback from the community and the results of the latest Helios poll.
Eran's proposal is most closely based on the Matt Luongo 'Decentralize the Dev Fee' proposal (ZIP 1011) 9. Relative to ZIP 1011 there are substantial changes and mixing in of elements from @aristarchus's '20% Split Evenly Between the ECC and the Zcash Foundation' (ZIP 1003) 7, Josh Cincinnati's 'Compromise Dev Fund Proposal With Diverse Funding Streams' (ZIP 1010) 8, and extensive discussions in the Zcash Community Forum.
The authors are grateful to all of the above for their excellent ideas and any insightful discussions, and to forum users @aristarchus and @dontbeevil for valuable initial comments on ZIP 1012.
1 | Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" |
---|
2 | Zcash Protocol Specification, Version 2021.2.16 or later |
---|
3 | Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet |
---|
4 | Zcash Trademark Donation and License Agreement |
---|
5 | The Open Source Definition |
---|
6 | ZIP 200: Network Upgrade Mechanism |
---|
7 | ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate |
---|
8 | ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams |
---|
9 | ZIP 1011: Decentralize the Dev Fee |
---|
10 | ZIP 1012: Dev Fund to ECC + ZF + Major Grants |
---|
11 | ZF Community Advisory Panel |
---|
12 | U.S. Code, Title 26, Section 501(c)(3) |
---|