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

Merge pull request #324 from ZcashFoundation/ecc-zf-zip-1014-changes 

Mutually agreed modifications to zip-1014
This commit is contained in:
Daira Hopwood 2020-02-27 17:46:11 +00:00 committed by GitHub
parent a27f08ab90 1a0d105a2c
commit 4aea56d915
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 86 additions and 125 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

211
zip-1014.rst
View File

@ -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>`_