diff --git a/zip-1014.rst b/zip-1014.rst index 1e2f36ce..f7934189 100644 --- a/zip-1014.rst +++ b/zip-1014.rst @@ -2,7 +2,8 @@ ZIP: 1014 Title: Dev Fund to ECC + ZF + Major Grants - Owner: Josh Cincinnati + Owners: Josh Cincinnati + Zooko Wilcox Original-Author: Eran Tromer Credits: Matt Luongo Howard Loo @@ -33,12 +34,12 @@ 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). +* 40% for additional "Major Grants" for large-scale long-term projects + (administered by the Zcash Foundation, with extra community input and + scrutiny). -Funding is capped at USD 700,000/month per slice. Governance and accountability -are based on existing entities and legal mechanisms, and increasingly -decentralized governance is encouraged. +Governance and accountability are based on existing entities and legal mechanisms, +and increasingly decentralized governance is encouraged. Motivation @@ -79,9 +80,9 @@ 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. +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 @@ -171,23 +172,19 @@ 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 as -"Major Grants", within the framework of ZF's grant program but subject to the -following additional constraints: +"Major Grants", but subject to the following additional constraints: 1. These funds MUST only be used to issue Major Grants to external parties that are independent of ZF. They MUST NOT be used by ZF for its internal - operations and direct expenses. + operations and direct expenses. Additionally ECC and ZF are ineligible + to receive Major Grants. 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. Grants of indefinite duration SHOULD have semiannual review points for continuation of funding. -3. Major Grants may be issued to ECC only if there are no other proposals - to perform the specified work with similar capabilities, effectiveness and - cost. (The intent is that eventually ECC will not receive Major Grants.) - -4. Priority SHOULD be given to Major Grants that bolster teams with +3. Priority SHOULD be given to Major Grants that bolster 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 SHOULD be @@ -196,46 +193,40 @@ following additional constraints: If one proposal substantially duplicates another's plans, priority SHOULD be given to the originator of the plans. -5. Major Grants SHOULD be awarded based on ZF's mission_ and values_, restricted - to furthering of the Zcash cryptocurrency and its ecosystem (which is more - specific than furthering financial privacy in general). +4. Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and + its ecosystem (which is more specific than furthering financial privacy in + general). -6. Major Grants awards are subject to approval by a five-seat Major Grant +5. Major Grants awards are subject to approval by a five-seat Major Grant Review Committee. The Major Grant Review Committee SHALL be selected by the - ZF's Community Panel. The Major Grant Review Committee's funding - decisions will be final, requiring no approval from the ZF Board, but are - subject to veto if the Foundation judges them to violate the ZF's operating - documents or U.S. law. + ZF's (Community Panel) [#zf-community]_ or successor process. + +6. The Major Grant Review Committee's funding decisions will be final, requiring + no approval from the ZF Board, but are subject to veto if the Foundation + judges them to violate the ZF's reporting requirements under U.S. IRS + 501(c)(3) or U.S. law. 7. Major Grant Review Committee members SHALL have a one-year term and MAY sit for reelection. The Major Grant Review Committee is subject to the same - conflict of interest policy that governs the ZF Board of Directors - (i.e. they MUST recuse themselves when voting on proposals where they have - a financial interest). Additionally, no one with interest in or association - with the ECC may sit on the Major Grant Review Committee --- since the ECC - can be a beneficiary, this avoids those potential conflicts altogether. - The ZF SHALL continue to operate the Community Panel and SHOULD work - toward making it more representative and independent (more on that below). + conflict of interest policy that governs the ZF Board of Directors (i.e. they + MUST recuse themselves when voting on proposals where they have a financial + interest). At most one person with association with the ECC, and at most one + person with association with the ZF, are allowed to sit on the Major Grant + Review Committee. "Association" here means: having a financial interest, + full-time employment, being an officer, being a director, or having an + immediate family relationship with any of the above. The ZF SHALL continue to + operate the Community Panel and SHOULD work toward making it more + representative and independent (more on that below). 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 SHALL be submitted -through ZF's 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 or long-duration grants will be funded from the dedicated -ZF-MG slice; though this is at ZF's discretion (e.g. if there are no Major -Grant applications the ZF may opt to direct the ZF-MG to smaller grants). - ZF SHALL strive to define target metrics and key performance indicators, and the Major Grant Review Committee SHOULD utilize these in its funding decisions. -.. _mission: https://www.zfnd.org/about/#mission -.. _values: https://www.zfnd.org/about/#values Direct-grant option ''''''''''''''''''' @@ -252,51 +243,6 @@ of the Zcash consensus rules they maintain. This decision will then be, effectively, ratified by the miners as the network upgrade activates. -Monthly Funding Cap and Volatility Reserve -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Each Dev Fund slice has a Monthly Funding Cap, initially USD 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 Monthly Funding Cap SHALL be deposited into a dedicated Volatility Reserve -account by the funds' recipient. ECC and ZF SHALL describe the methodology -used to calculate fair market value in relevant reports described under -`Transparency and Accountability`_. - -Each slice has its own separate Volatility Reserve account, owned and -managed by the recipient (ECC or ZF), but limited in how it may be used -(i.e., analogously to some types of retirement or trust accounts). -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 Monthly Funding Cap, 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 Monthly Funding Cap SHALL NOT be changed other than by unanimous agreement -of ZF, ECC, and the majority vote of the Community Panel. (In case of excessive -accumulation of reserves, the community MAY condition an increase of the -Monthly Funding Cap 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, SHALL be kept by the corresponding -party (as ZEC, or sold and invested) for later use under the terms of the -corresponding slice. - -Note that grantees of Major Grants are not directly subject to the Monthly -Funding Cap, and do not have to manage a Volatility Reserve account; this is -addressed upstream by the Zcash Foundation, which awards these grants. The -hope is that the Foundation-managed ZF-MG Volatility Reserve will ultimately -form a large long-term "endowment" pool that cushions the volatility for the -various grantees, so grantees can focus on their work instead of hedging -short-term price risks. - -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 ------------------------------- @@ -359,12 +305,8 @@ Future Community Governance --------------------------- Decentralized community governance is used in this proposal via the Community -Panel in the following places: - -1. As input into the Major Grant Review Committee which governs - the `ZF-MG slice (Zcash Foundation, for major grants)`_. - -2. For changing the `Monthly Funding Cap and Volatility Reserve`_. +Panel as input into the Major Grant Review Committee which governs the `ZF-MG +slice (Zcash Foundation, for major grants)`_. It is highly desirable to develop robust means of decentralized community voting and governance --- either by expanding the Community Panel @@ -394,8 +336,8 @@ Acknowledgements ================ This proposal is a limited modification of Eran Tromer's ZIP 1012 [#zip-1012]_ -by the Zcash Foundation, based on feedback from the Foundation's board and -the community. +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) [#zip-1011]_. Relative to ZIP 1011 there are @@ -410,6 +352,7 @@ any insightful discussions, and to Howard Loo and forum users *@aristarchus* and *@dontbeevil* for valuable initial comments on ZIP 1012. .. _Zcash Community Forum: https://forum.zcashcommunity.com/ +.. _latest Helios poll: https://vote.heliosvoting.org/helios/elections/43b9bec8-39a1-11ea-914c-b6e34ffa859a/view References @@ -421,3 +364,4 @@ References .. [#zip-1010] `Compromise Dev Fund Proposal With Diverse Funding Streams `_ .. [#zip-1011] `Decentralize the Dev Fee `_ .. [#zip-1012] `Dev Fund to ECC + ZF + Major Grants `_ +.. [#zf-community] `ZF Community Advisory Panel `_