mirror of https://github.com/zcash/zips.git
386 lines
17 KiB
ReStructuredText
386 lines
17 KiB
ReStructuredText
::
|
||
|
||
ZIP: 1014
|
||
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
|
||
@aristarchus
|
||
@dontbeevil
|
||
Daira Hopwood
|
||
George Tankersley
|
||
Status: Proposed
|
||
Category: Consensus / Process
|
||
Created: 2019-11-10
|
||
License: MIT
|
||
Discussions-To: <https://forum.zcashcommunity.com/t/community-sentiment-polling-results-nu4-and-draft-zip-1014/35560>
|
||
|
||
|
||
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 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
|
||
(administered by the Zcash Foundation, with extra community input and
|
||
scrutiny).
|
||
|
||
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
|
||
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
|
||
the ZF grant program.
|
||
|
||
There is a need to strike a balance between incentivizing the security of the
|
||
consensus protocol (i.e., mining) versus other crucial aspects of the Zcash
|
||
security and functionality, such as development and outreach.
|
||
|
||
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.
|
||
|
||
|
||
Requirements
|
||
============
|
||
|
||
The Dev Fund should encourage decentralization of the work and funding, by
|
||
supporting new teams dedicated to Zcash.
|
||
|
||
The Dev Fund should maintain the existing teams and capabilities in the Zcash
|
||
ecosystem, unless and until concrete opportunities arise to create even greater
|
||
value for the Zcash ecosystem.
|
||
|
||
There should not be any single entity which is a single point of failure, i.e.,
|
||
whose capture or failure will effectively prevent effective use of the funds.
|
||
|
||
Major funding decisions should be based, to the extent feasible, on inputs from
|
||
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 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
|
||
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
|
||
(e.g., election systems) or entities (for governance or development) for its
|
||
execution; but it should strive to support and use these once they are built.
|
||
|
||
Comply with legal, regulatory, and taxation constraints in pertinent
|
||
jurisdictions.
|
||
|
||
|
||
Non-requirements
|
||
================
|
||
|
||
General on-chain governance is outside the scope of this proposal.
|
||
|
||
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.
|
||
|
||
|
||
Specification
|
||
=============
|
||
|
||
Dev Fund allocation
|
||
-------------------
|
||
|
||
Starting at the first Zcash halving in 2020, until the second halving in 2024,
|
||
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 slice**);
|
||
* 40% for additional "Major Grants" for large-scale long-term projects
|
||
(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
|
||
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)
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
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
|
||
Zcash cryptocurrency and its community.
|
||
|
||
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
|
||
and contractors).
|
||
2. For covering pass-through tax obligations to partners caused by ECC's receipt
|
||
of the Dev Fund.
|
||
|
||
(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
|
||
governance structure (i.e., its Operating Agreement) or contractual obligations.
|
||
|
||
|
||
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, supporting community communication online
|
||
and via events, gathering community sentiment, and awarding external grants
|
||
for all of the above.
|
||
|
||
|
||
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
|
||
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", 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. 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. 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, 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.
|
||
|
||
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). 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 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.
|
||
|
||
ZF SHALL strive to define target metrics and key performance indicators,
|
||
and the Major Grant Review Committee SHOULD utilize these in its funding
|
||
decisions.
|
||
|
||
|
||
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 for some
|
||
or all grantees, if agreed upon by both ECC and ZF before Network Upgrade 4
|
||
(Canopy) 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
|
||
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.
|
||
|
||
|
||
Transparency and Accountability
|
||
-------------------------------
|
||
|
||
Obligations
|
||
~~~~~~~~~~~
|
||
|
||
ECC, ZF, and Major Grant recipients (during and leading to their award period)
|
||
SHALL all accept the obligations in this section.
|
||
|
||
Ongoing public reporting requirements:
|
||
|
||
* Quarterly reports, detailing future plans, execution on previous plans, and
|
||
finances (balances, and spending broken down by major categories).
|
||
* Monthly developer calls, or a brief report, on recent and forthcoming tasks.
|
||
(Developer calls may be shared.)
|
||
* Annual detailed review of the organization performance and future plans.
|
||
* Annual financial report (IRS Form 990, or substantially similar information).
|
||
|
||
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
|
||
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
|
||
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
|
||
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
|
||
be released under an Open Source license (as defined by the Open Source
|
||
Initiative [#osd]_), preferably the MIT license.
|
||
|
||
|
||
Enforcement
|
||
~~~~~~~~~~~
|
||
|
||
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 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
|
||
use the Zcash trademark for this modified version. The slice's funds will be
|
||
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
|
||
`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 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
|
||
--------------------
|
||
|
||
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,
|
||
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 SHOULD endeavor to use the Community Panel (or successor
|
||
mechanism) as advisory input for future board elections.
|
||
|
||
|
||
Acknowledgements
|
||
================
|
||
|
||
This proposal is a limited modification of Eran Tromer's ZIP 1012 [#zip-1012]_
|
||
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
|
||
substantial changes and mixing in of elements from *@aristarchus*'s
|
||
'20% Split Evenly Between the ECC and the Zcash Foundation' (ZIP 1003)
|
||
[#zip-1003]_, Josh Cincinnati's 'Compromise Dev Fund Proposal With Diverse
|
||
Funding Streams' (ZIP 1010) [#zip-1010]_, and extensive discussions in the
|
||
`Zcash Community Forum`_.
|
||
|
||
The authors are grateful to all of the above for their excellent ideas and
|
||
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://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||
.. [#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-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>`_
|