mirror of https://github.com/zcash/zips.git
mutually agreed modifications to zip-1014
This commit is contained in:
parent
206ff55aff
commit
4f5f2aa4c3
134
zip-1014.rst
134
zip-1014.rst
|
@ -2,7 +2,8 @@
|
|||
|
||||
ZIP: 1014
|
||||
Title: Dev Fund to ECC + ZF + Major Grants
|
||||
Owner: Josh Cincinnati <josh@zfnd.org>
|
||||
Owners: Josh Cincinnati <josh@zfnd.org>
|
||||
Zooko Wilcox <zooko@electriccoin.co>
|
||||
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-1010.rst>`_
|
||||
.. [#zip-1011] `Decentralize the Dev Fee <zip-1011.rst>`_
|
||||
.. [#zip-1012] `Dev Fund to ECC + ZF + Major Grants <zip-1012.rst>`_
|
||||
.. [#zf-community] `ZF Community Advisory Panel <https://github.com/ZcashFoundation/zfnd/blob/bdd3ec9434e90f436acc9655ece70f634cb47681/governance/community-advisory-panel.md>`_
|
||||
|
|
Loading…
Reference in New Issue