zips/zip-1014.rst

455 lines
20 KiB
ReStructuredText
Raw Normal View History

::
ZIP: 1014
Title: Dev Fund to ECC + ZF + Major Grants
Owner: Josh Cincinnati <josh@zfnd.org>
Original-Author: Eran Tromer
Credits: Matt Luongo
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
========
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:
* 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).
Funding is capped at $700k/month per slice. 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
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.
Difference from Matt Luongo's proposal
--------------------------------------
This proposal is based on Matt Luongo's `Decentralizing the Dev Fee`_ proposal,
which has similar motivations. The major changes are as follows:
* The Dev Fund slice intended for external recipients (beyond ECC, ZF and
existing ZF grants) may be used to fund ECC if no competitive alternatives
present themselves, to mitigate unwarranted loss of existing capabilities.
* For simplicity, the above slice is combined with the Foundation's existing
grant system; but is accompanied by explicit requirements to achieve its
goals, an independent body to disburse funds, and a Restricted Funds
mechanism to enforce these requirements.
* The "easing function" coin value cap is removed, in favor of capping each
slice at $700k/month funding target. Any excess is kept in a reserve by each
organization, from which it can be withdrawn only to maintain the funding
target in the future.
* Strengthened the transparency and accountability requirements, and
harmonized them across ECC, ZF, and major grantees.
* Removed ZF's supervisory role in determining the "principal developer",
fixing it to be ECC (changing this would be sufficiently dramatic to merit a
fork).
* Calls for the development of decentralized voting and governance.
* Clarity and brevity.
.. _Decentralizing the Dev Fee: https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252
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 be allowed
to 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, or 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 mechanism (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 rewards 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**);
* 40% for additional "Major Grants" for large-scale long-term projects
(denoted **ZF-MG slice**).
Details below. The fund flow will be implemented at the consensus-rule layer,
by sending the corresponding ZEC to the designated address in 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-GU slice (Zcash Foundation, for 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
for all of the above.
ZF-MG slice (Zcash Foundation, for 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 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:
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,
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.
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
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 by mentorship, coaching,
technical resources, creating entrepreneurial opportunities, etc. If one
proposal substantially duplicates anothers' 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).
6. Major Grants awarding is 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.
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).
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 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 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
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
'''''''''''''''''''
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
upon by both ECC and ZF before NU4 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.
Funding Target and Volatility Reserve
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Each Dev Fund slice has a Funding Target, initially US $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 Funding Target will be deposited into a dedicated Volatility Reserve
account by the funds' recipient.
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 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 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, 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 Funding
Target, 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
-------------------------------
Obligations
~~~~~~~~~~~
ECC, ZF, and Major Grant recipients (during and leading to their award period)
SHALL all accept the following obligations:
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 audited 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), 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 ZF-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 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 `Funding Target and Volatility Reserve`_.
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.
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.
Disclosures
===========
The author is
* a coauthor of the Zerocash_ academic paper underlying Zcash;
* a technical adviser to the Zcash Foundation;
* a founding scientist, a shareholder, and formerly a technical adviser to the
Electric Coin Company;
* an academic researcher and adviser to various other organizations.
This proposal is his private opinion and does not represent any of the above.
.. _Zerocash: https://eprint.iacr.org/2014/349
Acknowledgements
================
This proposed is most closely based on the Matt Luongo `Decentralizing the Dev
Fee`_ proposal, with substantial changes and mixing in elements from
*@aristarchus*'s `20% split between the ECC and the Foundation`_ proposal, Josh
Cincinnati's `A Grand Compromise/Synthesis ZIP Proposal`_ proposal and
extensive discussions in the `Zcash Community Forum`_. The author is grateful to
all of the above for their excellent ideas and many insightful discussions, and
to Howard Loo and forum users *@aristarchus* and *@dontbeevil* for valuable
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>`_