mirror of https://github.com/zcash/zips.git
ZIP 1014: RFC 2119 conformance language.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
a23752742b
commit
fe161c5537
87
zip-1014.rst
87
zip-1014.rst
|
@ -8,12 +8,21 @@
|
|||
Howard Loo
|
||||
@aristarchus
|
||||
@dontbeevil
|
||||
Daira Hopwood
|
||||
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>
|
||||
|
||||
|
||||
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]_
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
|
@ -131,7 +140,7 @@ Dev Fund allocation
|
|||
-------------------
|
||||
|
||||
Starting at the first Zcash halving in 2020, until the second halving in 2024,
|
||||
20% of the block rewards will be allocated to a "Dev Fund" that consists of
|
||||
20% of the block rewards SHALL be allocated to a "Dev Fund" that consists of
|
||||
the following three slices:
|
||||
|
||||
* 35% for the Electric Coin Company (denoted **ECC slice**);
|
||||
|
@ -150,10 +159,10 @@ ECC slice (Electric Coin Company)
|
|||
|
||||
This slice of the Dev Fund will flow to ECC.
|
||||
|
||||
ECC must undertake a firm obligation to use the Dev Fund only in support of the
|
||||
ECC MUST undertake a firm obligation to use the Dev Fund only in support of the
|
||||
Zcash cryptocurrency and its community.
|
||||
|
||||
In particular, ECC must commit to not distribute the Dev Fund proceeds to its
|
||||
In particular, ECC MUST commit to not distribute the Dev Fund proceeds to its
|
||||
partners ("shareholders"), other than:
|
||||
|
||||
1. In fair-market-value compensation for specific new work (e.g., to employees
|
||||
|
@ -164,7 +173,7 @@ partners ("shareholders"), other than:
|
|||
(ECC is encouraged to transition to a corporate structure that would avoid the
|
||||
latter taxes.)
|
||||
|
||||
This obligation must be made irrevocable, e.g., within ECC's corporate
|
||||
This obligation MUST be made irrevocable, e.g., within ECC's corporate
|
||||
governance structure (i.e., its Operating Agreement) or contractual obligations.
|
||||
|
||||
|
||||
|
@ -186,15 +195,15 @@ 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
|
||||
and effective.
|
||||
|
||||
The funds will be received and administered by ZF. ZF will disburse them as
|
||||
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:
|
||||
|
||||
1. These funds may be only be used to issue Major Grants to external parties
|
||||
that are independent of ZF. They may not be used by ZF for its internal
|
||||
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.
|
||||
|
||||
2. Major Grants should support well-specified work proposed by the grantee,
|
||||
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, but have semiannual review points for
|
||||
continuation of funding.
|
||||
|
@ -217,28 +226,28 @@ following additional constraints:
|
|||
specific than furthering financial privacy in general).
|
||||
|
||||
6. Major Grants awarding is subject to approval by a five-seat Major Grant
|
||||
Review Committee. The Major Grant Review Committee will be selected by the
|
||||
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.
|
||||
|
||||
7. Major Grant Review Committee members have a one-year term and can sit
|
||||
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
|
||||
(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 will continue to operate the Community Panel and will work
|
||||
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 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 will be submitted
|
||||
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
|
||||
|
@ -246,8 +255,8 @@ 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).
|
||||
|
||||
ZF shall strive to define target metrics and key performance indicators, and
|
||||
hopes the Major Grant Review Committee will 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
|
||||
|
@ -258,12 +267,12 @@ 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
|
||||
grantees. Thus, the following mechanism MAY be used in perpetuity, 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
|
||||
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.
|
||||
|
||||
|
@ -287,14 +296,14 @@ the Funding Target, 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 Funding Target may be changed only by unanimous agreement of ZF, ECC, and
|
||||
the majority vote of the Community Panel. (In case of excessive
|
||||
accumulation of reserves, the community can condition an increase of the
|
||||
The Funding Target 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
|
||||
Funding Target 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, will be kept by the corresponding
|
||||
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.
|
||||
|
||||
|
@ -306,7 +315,7 @@ 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.,
|
||||
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).
|
||||
|
||||
|
@ -318,7 +327,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 following obligations:
|
||||
|
||||
Ongoing public reporting requirements:
|
||||
|
||||
|
@ -334,22 +343,22 @@ These reports may be either organization-wide, or restricted to the income,
|
|||
expenses, and work associated with the receipt of Dev Fund.
|
||||
|
||||
It is expected that ECC, ZF, and Major Grant recipients will be focused
|
||||
primarily (in their attention and resources) on Zcash. Thus, they must
|
||||
primarily (in their attention and resources) on Zcash. Thus, they MUST
|
||||
promptly disclose:
|
||||
|
||||
* Any major activity they perform (even if not supported by the Dev Fund) that
|
||||
is not in the interest of the general Zcash ecosystem.
|
||||
* Any conflict of interest with the general success of the Zcash ecosystem.
|
||||
|
||||
ECC, ZF, and grant recipients must promptly disclose any security or privacy
|
||||
ECC, ZF, and grant recipients MUST promptly disclose any security or privacy
|
||||
risks that may affect users of Zcash (by responsible disclosure under
|
||||
confidence to the pertinent developers, where applicable).
|
||||
|
||||
ECC's reports, and ZF's annual report on its non-grant operations, should be
|
||||
ECC's reports, and ZF's annual report on its non-grant operations, SHOULD be
|
||||
at least as detailed as grant proposals/reports submitted by other funded
|
||||
parties, and satisfy similar levels of public scrutiny.
|
||||
|
||||
All substantial software whose development was funded by the Dev Fund should
|
||||
All substantial software whose development was funded by the Dev Fund SHOULD
|
||||
be released under an Open Source license (as defined by the Open Source
|
||||
Initiative), preferably the MIT license.
|
||||
|
||||
|
@ -357,11 +366,11 @@ Initiative), preferably the MIT license.
|
|||
Enforcement
|
||||
~~~~~~~~~~~
|
||||
|
||||
For grant recipients, these conditions should be included in their contract
|
||||
For grant recipients, these conditions SHOULD be included in their contract
|
||||
with ZF, such that substantial violation, not promptly remedied, will cause
|
||||
forfeiture of their grant funds and their return to ZF.
|
||||
|
||||
ECC and ZF will contractually commit to each other to fulfill these
|
||||
ECC and ZF MUST contractually commit to each other to fulfill these
|
||||
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
|
||||
|
@ -384,15 +393,16 @@ Panel in the following places:
|
|||
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
|
||||
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.
|
||||
|
||||
|
||||
ZF Board Composition
|
||||
--------------------
|
||||
|
||||
Members of ZF's Board of Directors must not hold equity in ECC or have current
|
||||
business or employment relationships with ECC.
|
||||
Members of ZF's Board of Directors MUST NOT hold equity in ECC or have current
|
||||
business or employment relationships with ECC, except as provided for by the
|
||||
grace period described below.
|
||||
|
||||
Grace period: members of the board who hold ECC equity (but do not have other
|
||||
current relationships to ECC) may dispose of their equity, or quit the Board,
|
||||
|
@ -400,7 +410,7 @@ by 1 November 2021. (The grace period is to allow for orderly replacement, and
|
|||
also to allow time for ECC corporate reorganization related to Dev Fund
|
||||
receipt, which may affect how disposition of equity would be executed.)
|
||||
|
||||
The Foundation will endeavor to use the Community Panel (or successor
|
||||
The Foundation SHOULD endeavor to use the Community Panel (or successor
|
||||
mechanism) as advisory input for future board elections.
|
||||
|
||||
|
||||
|
@ -435,3 +445,10 @@ initial comments on this proposal.
|
|||
.. _20% split between the ECC and the Foundation: https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862
|
||||
.. _A Grand Compromise/Synthesis ZIP Proposal: https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812
|
||||
.. _Zcash Community Forum: https://forum.zcashcommunity.com/
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
|
||||
|
|
Loading…
Reference in New Issue