zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 1014: updates from review with Gtank. 

Update Discussions-To: URL.
Delete section on differences from Matt Luongo's proposal.
Clarify wording on large or long-duration Major Grants.
Reporting requirement for how "fair market value" is computed.
RFC 2119 conformance language.
"$" -> USD.
Copyediting.

Co-Authored-By: Daira Hopwood <daira@jacaranda.org>
Co-Authored-By: George Tankersley <george@zfnd.org>
Co-Authored-By: Josh Cincinnati <acityinohio@users.noreply.github.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-01-07 18:29:42 +00:00
parent 6a86d4a853
commit 5e44e622a7
1 changed files with 38 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

99
zip-1014.rst
View File

@ -9,11 +9,12 @@
@aristarchus
@dontbeevil
Daira Hopwood
George Tankersley
Status: Draft
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>
Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>
Terminology
@ -35,9 +36,9 @@ of 20% of the block rewards, split into 3 slices:
* 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.
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.
Motivation
@ -58,33 +59,6 @@ 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, ZF and
existing ZF 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, an independent body to disburse funds, 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 by each
organization, 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, ZF, and major grantees.
* Removed ZF's supervisory role in determining the "principal developer",
fixing it to be ECC (changing this would be sufficiently dramatic to merit a
fork).
* Calls for the development of decentralized voting and governance.
* Clarity and brevity.
.. _Decentralizing the Dev Fee: https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252
Requirements
============
@ -110,9 +84,10 @@ to wastefully use excessive amounts of funds. Conversely, given market volatilit
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).
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
@ -128,7 +103,7 @@ Non-requirements
General on-chain governance is outside the scope of this proposal.
Rigorous voting mechanism (whether coin-weighted, holding-time-weighted or
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.
@ -148,10 +123,10 @@ the following three slices:
* 40% for additional "Major Grants" for large-scale long-term projects
(denoted **ZF-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).
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).
ECC slice (Electric Coin Company)
@ -192,7 +167,7 @@ ZF-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
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
@ -212,20 +187,20 @@ following additional constraints:
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
4. 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
given to Major Grants that support ecosystem growth by mentorship, coaching,
technical resources, creating entrepreneurial opportunities, etc. If one
proposal substantially duplicates anothers' plans, priority should be
for long-term success, subject to the usual grant award considerations
(impact, ability, risks, team, cost-effectiveness, etc.). Priority SHOULD be
given to Major Grants that support ecosystem growth through mentorship,
coaching, technical resources, creating entrepreneurial opportunities, etc.
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
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).
6. Major Grants awarding is subject to approval by a five-seat Major Grant
6. 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
@ -234,7 +209,7 @@ following additional constraints:
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.
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
@ -244,19 +219,19 @@ 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
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 long-duration 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).
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
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
@ -267,8 +242,8 @@ Direct-grant option
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:
grantees. Thus, the following mechanism MAY be used in perpetuity for some
or all grantees, 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
@ -280,11 +255,13 @@ 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
Each Dev Fund slice has a Funding Target, 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 Funding Target will be deposited into a dedicated Volatility Reserve
account by the funds' recipient.
the Funding Target 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