-
Notifications
You must be signed in to change notification settings - Fork 159
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1 from daira/ecc-zf-zip-1014-changes
Editorial changes to Dev Fund ZIP
- Loading branch information
Showing
1 changed file
with
52 additions
and
35 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,7 @@ | ||
:: | ||
|
||
ZIP: 1014 | ||
Title: Dev Fund to ECC + ZF + Major Grants | ||
Title: Establishing a Dev Fund for ECC, ZF, and Major Grants | ||
Owners: Josh Cincinnati <[email protected]> | ||
Zooko Wilcox <[email protected]> | ||
Original-Author: Eran Tromer | ||
|
@@ -11,7 +11,7 @@ | |
@dontbeevil | ||
Daira Hopwood | ||
George Tankersley | ||
Status: Draft | ||
Status: Proposed | ||
Category: Consensus / Process | ||
Created: 2019-11-10 | ||
License: MIT | ||
|
@@ -24,13 +24,27 @@ 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); | ||
|
@@ -46,7 +60,7 @@ 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 | ||
|
@@ -116,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 | ||
|
@@ -153,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 | ||
|
@@ -188,23 +202,23 @@ The funds SHALL be received and administered by ZF. ZF MUST disburse them as | |
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. | ||
|
||
4. Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and | ||
its ecosystem (which is more specific than furthering financial privacy in | ||
general). | ||
|
||
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) [#zf-community]_ or successor process. | ||
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. | ||
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 | ||
|
@@ -218,7 +232,7 @@ The funds SHALL be received and administered by ZF. ZF MUST disburse them as | |
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. | ||
|
@@ -236,7 +250,7 @@ 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, | ||
|
@@ -250,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: | ||
|
||
|
@@ -297,22 +311,22 @@ 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). | ||
|
||
|
||
Future Community Governance | ||
--------------------------- | ||
|
||
Decentralized community governance is used in this proposal via the Community | ||
Panel as input into the Major Grant Review Committee which governs the `ZF-MG | ||
slice (Zcash Foundation, for major grants)`_. | ||
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 | ||
|
@@ -359,9 +373,12 @@ 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>`_ |