Merge pull request #324 from ZcashFoundation/ecc-zf-zip-1014-changes
Mutually agreed modifications to zip-1014
This commit is contained in:
commit
4aea56d915
211
zip-1014.rst
211
zip-1014.rst
|
@ -1,8 +1,9 @@
|
|||
::
|
||||
|
||||
ZIP: 1014
|
||||
Title: Dev Fund to ECC + ZF + Major Grants
|
||||
Owner: Josh Cincinnati <josh@zfnd.org>
|
||||
Title: Establishing a Dev Fund for ECC, ZF, and Major Grants
|
||||
Owners: Josh Cincinnati <josh@zfnd.org>
|
||||
Zooko Wilcox <zooko@electriccoin.co>
|
||||
Original-Author: Eran Tromer
|
||||
Credits: Matt Luongo
|
||||
Howard Loo
|
||||
|
@ -10,7 +11,7 @@
|
|||
@dontbeevil
|
||||
Daira Hopwood
|
||||
George Tankersley
|
||||
Status: Draft
|
||||
Status: Proposed
|
||||
Category: Consensus / Process
|
||||
Created: 2019-11-10
|
||||
License: MIT
|
||||
|
@ -23,29 +24,43 @@ Terminology
|
|||
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and "MAY"
|
||||
in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
||||
|
||||
The term "network upgrade" in this document is to be interpreted as
|
||||
described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License
|
||||
Agreement ([#trademark]_ or successor agreement).
|
||||
|
||||
The terms "block subsidy" and "halving" in this document are to be interpreted
|
||||
as described in sections 3.9 and 7.7 of the Zcash Protocol Specification.
|
||||
[#protocol]_
|
||||
|
||||
"Electric Coin Company", also called "ECC", refers to the Zerocoin Electric
|
||||
Coin Company, LLC.
|
||||
|
||||
"Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit
|
||||
corporation of that name.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
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 rewards, split into 3 slices:
|
||||
of 20% of the block subsidies, 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
|
||||
==========
|
||||
|
||||
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
|
||||
subsidies 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
|
||||
|
@ -79,9 +94,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
|
||||
|
@ -115,13 +130,13 @@ Dev Fund allocation
|
|||
-------------------
|
||||
|
||||
Starting at the first Zcash halving in 2020, until the second halving in 2024,
|
||||
20% of the block rewards SHALL be allocated to a "Dev Fund" that consists of
|
||||
the following three slices:
|
||||
20% of the block subsidy of each block SHALL be allocated to a "Dev Fund" that
|
||||
consists of the following three slices:
|
||||
|
||||
* 35% for the Electric Coin Company (denoted **ECC slice**);
|
||||
* 25% for the Zcash Foundation, for general use (denoted **ZF-GU slice**);
|
||||
* 25% for the Zcash Foundation, for general use (denoted **ZF slice**);
|
||||
* 40% for additional "Major Grants" for large-scale long-term projects
|
||||
(denoted **ZF-MG slice**).
|
||||
(denoted **MG slice**).
|
||||
|
||||
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
|
||||
|
@ -152,18 +167,18 @@ This obligation MUST be made irrevocable, e.g., within ECC's corporate
|
|||
governance structure (i.e., its Operating Agreement) or contractual obligations.
|
||||
|
||||
|
||||
ZF-GU slice (Zcash Foundation, for general use)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
ZF slice (Zcash Foundation's general use)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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 online
|
||||
and via events, gathering community sentiment, and external awarding grants
|
||||
including: development, education, supporting community communication online
|
||||
and via events, gathering community sentiment, and awarding external grants
|
||||
for all of the above.
|
||||
|
||||
|
||||
ZF-MG slice (Zcash Foundation, for major grants)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
MG slice (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
|
||||
|
@ -171,71 +186,61 @@ 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
|
||||
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.
|
||||
given to Major Grants that support ecosystem growth, for example 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
|
||||
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 U.S. law or the ZF's reporting requirements and other
|
||||
(current or future) obligations under U.S. IRS 501(c)(3).
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
'''''''''''''''''''
|
||||
|
@ -245,58 +250,13 @@ 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 NU4 activation:
|
||||
|
||||
Prior to each Network Upgrade, the Foundation SHALL publish a list of
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
-------------------------------
|
||||
|
||||
|
@ -304,7 +264,7 @@ Obligations
|
|||
~~~~~~~~~~~
|
||||
|
||||
ECC, ZF, and Major Grant recipients (during and leading to their award period)
|
||||
SHALL all accept the following obligations:
|
||||
SHALL all accept the obligations in this section.
|
||||
|
||||
Ongoing public reporting requirements:
|
||||
|
||||
|
@ -351,7 +311,7 @@ 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
|
||||
reassigned to MG (whose integrity is legally protected by the Restricted
|
||||
Fund treatment).
|
||||
|
||||
|
||||
|
@ -359,18 +319,14 @@ 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
|
||||
`MG slice (Major Grants)`_.
|
||||
|
||||
It is highly desirable to develop robust means of decentralized community
|
||||
voting and governance --- either by expanding the Community Panel
|
||||
or a successor mechanism --- and to integrate them into both of these
|
||||
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.
|
||||
voting and governance –either by expanding the Community Panel or a
|
||||
successor mechanism– and to integrate them into this process 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 Board Composition
|
||||
|
@ -394,8 +350,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,14 +366,19 @@ 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
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#protocol] `Zcash Protocol Specification [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
|
||||
.. [#trademark] `Zcash Trademark Donation and License Agreement <https://www.zfnd.org/about/contracts/2019_ECC_ZFND_TM_agreement.pdf>`_
|
||||
.. [#osd] `The Open Source Definition <https://opensource.org/osd>`_
|
||||
.. [#zip-1003] `20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate <zip-1003.rst>`_
|
||||
.. [#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>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||||
.. [#zip-1003] `ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate <zip-1003.rst>`_
|
||||
.. [#zip-1010] `ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams <zip-1010.rst>`_
|
||||
.. [#zip-1011] `ZIP 1011: Decentralize the Dev Fee <zip-1011.rst>`_
|
||||
.. [#zip-1012] `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