mirror of https://github.com/zcash/zips.git
354 lines
17 KiB
ReStructuredText
354 lines
17 KiB
ReStructuredText
::
|
||
|
||
ZIP: 1010
|
||
Title: Compromise Dev Fund Proposal With Diverse Funding Streams
|
||
Owner: Josh Cincinnati <josh@zfnd.org>
|
||
Credits: Matt Luongo
|
||
Eran Tromer
|
||
Andrew Miller
|
||
mistfpga
|
||
lex-node
|
||
and many others
|
||
Status: Draft
|
||
Category: Consensus
|
||
Created: 2019-08-31
|
||
License: MIT
|
||
Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812/>
|
||
|
||
|
||
Terminology
|
||
===========
|
||
|
||
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" 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]_
|
||
|
||
|
||
Abstract
|
||
========
|
||
|
||
I try to put the best pieces of various proposals together. A 20% of the block
|
||
reward for a 4-year development fund that disburses to a trust controlled by
|
||
both the Electric Coin Company (ECC) and Zcash Foundation (ZF), but with
|
||
stringent controls on how funds may be allocated. It sidesteps code complexity
|
||
in implementation by off-loading disbursements to a legal trust; funds the
|
||
ECC/ZF; ECC stays a for-profit with restrictions; funds external parties
|
||
through ZF Grants; all while carving out a limited-scoped opportunity for
|
||
extending governance to more groups than the ECC/ZF.
|
||
|
||
|
||
Motivation and Requirements
|
||
===========================
|
||
|
||
.. role:: editor-note
|
||
|
||
Zcash won't thrive without a dev fund. I wish this wasn't true (I really do),
|
||
and for the longest time I was against the idea. But I've come to fear the
|
||
alternative without one; I fear the privacy technology pioneered by Zcash may
|
||
never reach its true potential — not just for our community, but for others
|
||
interested in novel approaches to private money.
|
||
|
||
The Foundation, ECC, and broader community has offered many suggestions and
|
||
guidelines for a potential dev fund, below is my attempt at synthesizing them
|
||
into a compromise that's greater than the sum of its parts:
|
||
|
||
* The ECC and Zcash Foundation shouldn't get a blank check; accountability is
|
||
a prerequisite for any disbursement, based on the Foundation's statement
|
||
[#zfnd-guidance]_ and other proposals being suggested.
|
||
* It's possible for the ECC to remain a for-profit, but with (legally
|
||
enforced) restrictions that ensure accountability and add teeth to their
|
||
claim that no early investors are enriched by a new dev fund / no new
|
||
investors are beneficiaries.
|
||
* A nontrivial portion of the funds should be directed to users/organisations
|
||
outside of the ECC/Zcash Foundation, and the ECC/Zcash Foundation should be
|
||
in the minority in deciding how these funds are disbursed (e.g. through some
|
||
process with broader input beyond ECC/Zcash Foundation employees, like a
|
||
more constrained version of Placeholder or Blocktower's "third party"
|
||
proposals).
|
||
* The actual code changes for the NU4 network upgrade should be minimal and
|
||
the "governance complexity" should be offloaded to legal agreements, not
|
||
engineering hours. The dev fund would be deposited into a single address
|
||
for the fund (ideally shielded with a viewing key) controlled through a
|
||
trust (originally Andrew Miller’s idea), disbursed quarterly based on the
|
||
accountability requirements and shielded adoption metrics described below.
|
||
Trustees will be mutually agreed upon by the ECC and Zcash Foundation, and
|
||
the Zcash Foundation will bear the cost of operating the trust.
|
||
* The gross amount of the dev fund should still be 20% of the block reward,
|
||
and it should end in 4 years. (Unless we go through another process like
|
||
this one to extend it, though I personally hope we don’t.)
|
||
|
||
:editor-note:`for security reasons, it may be useful to refine the
|
||
"single address" to a list of rolling addresses as described in
|
||
section 7.8 of the current protocol specification. Other references to
|
||
a "single address" in this document have not been changed.`
|
||
|
||
*Please note: a previous version of this proposal included a portion of the
|
||
funds being tied to shielded adoption, based on ideas brought forward by
|
||
Eran Tromer in* [#tromer-comment]_. *After many discussions I came to worry
|
||
about the gameability of the metric and decided to drop it entirely.*
|
||
|
||
|
||
Specification
|
||
=============
|
||
|
||
Upon the NU4 network activation, 20% of the mining reward (post-Blossom /
|
||
post-halvening = 0.625 ZEC per block) MUST go to a single shielded address
|
||
with a viewing key widely distributed and known to the community and
|
||
controlled by a trust established by the ECC and Zcash Foundation. If the
|
||
trust and associated address aren't established by the NU4 activation
|
||
deadline, then there MUST NOT be any change to the mining reward. Every
|
||
quarter-year (105,000 blocks at the post-Blossom rate), until 4 years after
|
||
NU4 activation (1,680,000 blocks at the post-Blossom rate), the trust SHOULD
|
||
disburse funds the following way, requiring a public report with every
|
||
disbursement:
|
||
|
||
* 30% of the fund to the ECC, if they meet the accountability requirements
|
||
set by the trust/described below;
|
||
|
||
* 30% of the fund to the Zcash Foundation, if they meet the accountability
|
||
requirements set by the trust/described below;
|
||
|
||
* 40% of the fund to the Zcash Foundation as a RESTRICTED donation
|
||
[#restricted-funds]_ purely for disbursement through ZF Grants
|
||
[#zfnd-grants]_, with additional restrictions and stipulations described
|
||
below.
|
||
|
||
:editor-note:`When this proposal was written it was expected that NU4
|
||
activation would correspond exactly to the first (October 2020) halvening.
|
||
Since that may not be the case, I have resolved a potential ambiguity in
|
||
the original wording by specifying that the trust disburses funds for
|
||
4 years, rather than that it disburses funds until the second (October 2024)
|
||
halvening.`
|
||
|
||
Example disbursements by the trust for a hypothetical 105000-block period
|
||
-------------------------------------------------------------------------
|
||
|
||
0.625 ZEC * 105000 = 65625 ZEC accrued in the trust every quarter. If both
|
||
the ECC and Zcash Foundation met the accountability requirements set by the
|
||
trust, then disbursements would look like this:
|
||
|
||
* 19687.5 ZEC to the ECC for meeting accountability requirements.
|
||
|
||
* 19687.5 ZEC to the Zcash Foundation for meeting accountability requirements.
|
||
|
||
* 26250 ZEC to ZF Grants to be disbursed to external individuals and
|
||
organizations (via the Zcash Foundation as a restricted donation, but
|
||
determined by an independent body to both organizations).
|
||
|
||
This example assumes no change to target block spacing.
|
||
|
||
The trust's accountability requirements
|
||
---------------------------------------
|
||
|
||
Here I'm borrowing from the Foundation's guidance [#zfnd-guidance]_ but
|
||
adding some stipulations to cement the Foundation's independence, prevent
|
||
the Foundation from hoarding its endowment, and handle the ECC as a
|
||
for-profit. Before disbursing funds each quarter, the trust MUST validate
|
||
that both the ECC and Zcash Foundation:
|
||
|
||
* Published quarterly technical roadmap reports and financial reports,
|
||
detailing spending levels/burn rate and cash/ZEC on hand;
|
||
|
||
* (if the first disbursement in a calendar year) Published a yearly
|
||
review of organization performance, along the lines of the Zcash
|
||
Foundation's "State of the Foundation" report [#zfnd-state]_.
|
||
|
||
For the Zcash Foundation, the trust MUST further require:
|
||
|
||
* No board member may have an interest in the ECC (current board members
|
||
with an interest would need to divest of their ECC holdings prior to
|
||
the beginning of this dev fund or leave the board);
|
||
|
||
* Excluding money restricted for ZF Grants, the Foundation's total assets
|
||
MUST stay below $100mm (if its assets ever exceeded this amount from a
|
||
disbursement, the trust could direct the funds toward an additional
|
||
restricted ZF Grants donation).
|
||
|
||
Additionally, for the ECC, the trust MUST validate the following before
|
||
each disbursement:
|
||
|
||
* (if the first disbursement in a fiscal year) The ECC published yearly
|
||
audited financial statements at the same level of detail as a public
|
||
company (to mirror the Foundation's Form 990 requirement as 501(c)(3));
|
||
|
||
* No outside investment was received while they are obligatory recipients
|
||
of this dev fund;
|
||
|
||
* No portion of the dev fund went to dividends, profit-sharing, or
|
||
share/equity buybacks while they are obligatory recipients of this dev
|
||
fund;
|
||
|
||
* No dilution of ECC's equity except in the case of options/RSUs for
|
||
new/existing employees while they are obligatory recipients of this
|
||
dev fund;
|
||
|
||
* There's no change-of-control (majority control changes) at the ECC
|
||
while they are obligatory recipients of this dev fund;
|
||
|
||
The ECC MUST share necessary information with the trust to ascertain no
|
||
violations of the above, but the information itself (i.e. cap table and
|
||
detailed financials) SHOULD remain private between the ECC and the
|
||
trustees unless there is a violation that is not cured.
|
||
|
||
What happens in the case of a violation
|
||
---------------------------------------
|
||
|
||
The violating party has 30 days to attempt to cure the violation (if it's
|
||
possible). If they cannot, future funds MUST be redirected to ZF Grants via
|
||
a restricted donation to the Zcash Foundation. (That is, not usable by either
|
||
the Zcash Foundation or ECC, more on that below.)
|
||
|
||
The ZF Grants portion
|
||
---------------------
|
||
|
||
A portion of the dev fund goes to the Foundation but with the express (and
|
||
restricted) purpose of being distributed via ZF Grants (a restriction that
|
||
MUST be legally enforced by the trust). The Foundation would continue to
|
||
administer ZF Grants and distribute funds, but it SHOULD NOT decide where
|
||
those funds go and would not allowed to be recipients of these funds;
|
||
instead, the trust MUST demand that the ZF Grants process include broader
|
||
input in the manner described below. In the discussions around the various
|
||
"third party" proposals, some have suggested a 3-of-5 approach where the ECC
|
||
and Zcash Foundation are in the minority; I think that structure would work
|
||
well for these funds. It's not the full dev fund so we are limiting the
|
||
downside risk of selecting the "wrong" third parties, which also means we
|
||
can give those third parties more voice (by making them outnumber the
|
||
ECC/Zcash Foundation). The Foundation MAY also chose to fund ZF Grants
|
||
*beyond* the restricted donations from the trust, but doing so would be at
|
||
their discretion.
|
||
|
||
Thanks to the discussion on Matt Luongo's proposal there's a good blueprint
|
||
for how this group would work. I'm borrowing some comments I made on Matt's
|
||
proposal thread [#acityinohio-comment]_ and modifying them to apply to a
|
||
ZF Grants-specific Grant Review Committee, rather than the Foundation's
|
||
board.
|
||
|
||
The ZF Grant Review Committee would be compromised of five members, voted on
|
||
in the following manner:
|
||
|
||
* 1 seat for the ECC. Though the appointed member may change, they retain
|
||
power to choose the seat for 4 years.
|
||
* 1 seat for the Zcash Foundation. Though the appointed member may change,
|
||
they retain power to choose the seat for 4 years.
|
||
* 2 seats voted on by ZEC holders directly, elected every year. There would
|
||
be open elections held by the Foundation similar to the 2018 advisory
|
||
process which resulted in Ian and Amber’s election, except using a ZEC
|
||
coin-staked vote directly.
|
||
* 1 seat held by a technical member, elected every year. This member would
|
||
be selected by the combined group (2 coin-staked seats + ZF seat + ECC
|
||
seat) with an express focus on ability to evaluate technical proposals.
|
||
|
||
The group would meet biweekly to make funding decisions, the results of
|
||
which will be made public on ZF Grants. Taking a note from Eran Tromer's
|
||
recent proposal, the group would have a goal of making at least two
|
||
"Large Grants" every year. A "Large Grant" would have an expected scope of
|
||
six months and 1/4th to 1/3rd of the total ZF Grants yearly budget, with
|
||
the goal of getting more dedicated external teams involved.
|
||
|
||
|
||
Rationale
|
||
=========
|
||
|
||
There are scores of great ideas on the forums, and I took the (subjective,
|
||
mind you) best parts of each into a proposal that hopefully meets the
|
||
standards of the ECC, the Zcash Foundation, and the broader community.
|
||
|
||
A word on the enigmatic "third party" floating around
|
||
-----------------------------------------------------
|
||
|
||
With all due respect to the proposers behind some variant of a "2-of-3
|
||
multisig" decision-making process for *all* disbursement decisions:
|
||
I think this is a bad idea. To quote a previous forum post of mine:
|
||
|
||
...2-of-3 multisig [is] better if we find the right third party.
|
||
That in and of itself requires an additional process/mutual agreement
|
||
between the three parties (which is much more difficult than a bilateral
|
||
agreement), and as I’ve mentioned before in presentations in the past,
|
||
2-of-2 with known entities dedicated to Zcash is better than jumping
|
||
straight to 2-of-3 with a third party hastily decided or staying with
|
||
1-of-1 entity trademarks and software development processes.
|
||
|
||
As for why 2-of-2 is still strictly better than 1-of-1: in the case of
|
||
cryptocurrency governance, I believe that inaction in the case of
|
||
disagreement is a better outcome than one party unilaterally exercising
|
||
power.
|
||
|
||
More to the point, I worry that the "third party" in question is being
|
||
idolized into some Platonic ideal, and in reality either the ECC or the
|
||
Zcash Foundation would spend a great deal of their time currying favor in
|
||
either the process or selection of the party in question in the limited time
|
||
between now and that party's selection. Given that the Zcash Foundation is
|
||
charged with representing community interests, I'm not sure why another
|
||
community-focused representative would really make sense from the ECC's
|
||
perspective — they'd be constantly outvoted if interests clashed, so from
|
||
a balance of power perspective I'm not sure why the ECC would find that
|
||
tenable. And I'm not sure the community would want the "third party" to be
|
||
another profit-generating enterprise, like a VC or another startup, which
|
||
would tip power another way.
|
||
|
||
The crux of this proposal still centers around the idea that the Zcash
|
||
Foundation and ECC share responsibility for protocol development, which
|
||
is now bolstered by the 2-of-2 agreement on the trademark. It assumes and
|
||
expects that both continue developing consensus-compatible node software
|
||
that interacts with the Zcash network. But it mandates accountability for
|
||
disbursement of funds to the ECC/Zcash Foundation, and expands outside
|
||
stakeholder input on funds that *wouldn't* be earmarked for the ECC/Zcash
|
||
Foundation (similar to Placeholder's earlier version of their proposal and
|
||
Matt Luongo's current proposal), while it doesn’t preclude the possibility
|
||
of migrating to broader "2-of-3" later on future governance decisions.
|
||
|
||
Why a trust?
|
||
------------
|
||
|
||
The main reason: reducing complexity creep in consensus code. Rather than try
|
||
to incorporate some complex mechanism for dev fund disbursements on-chain, we
|
||
can meet the NU4 with the simplest possible code-change and spend more time
|
||
ironing out the details of the trust "off-chain." Since both the ECC and the
|
||
Zcash Foundation are based in the US, using a trust with well-specified
|
||
criteria for disbursements is a reasonable path. This also fits in nicely
|
||
with lex-node's proposal [#zip-1007]_ for legal covenants on funding.
|
||
|
||
|
||
Security and Privacy Considerations
|
||
===================================
|
||
|
||
The biggest issue is custody of the funds under the trust's control, but
|
||
I suspect this can be managed with a partnership with a custody partner.
|
||
There's also the issue that non-public information would need to be verified
|
||
and validated by the trust, but I view this as a net positive for the
|
||
community ("transparency for organizations, privacy for individuals").
|
||
|
||
|
||
Reference implementation
|
||
========================
|
||
|
||
TBD, but it should be relatively simple to code in both zebra and zcashd.
|
||
|
||
|
||
Issues and further discussion
|
||
=============================
|
||
|
||
* What are the tax implications for setting up the trust?
|
||
* Are the amounts reasonable? Should the dev fund be less than 20% in
|
||
aggregate?
|
||
* Should this or other proposals seek to change the ECC and Zcash
|
||
Foundation's board/makeup, or should we keep those organizations running
|
||
as they are and sandbox a new process to a specific disbursement of the
|
||
dev fund? (This proposal assumes the latter via ZF Grants.)
|
||
|
||
|
||
References
|
||
==========
|
||
|
||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
|
||
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_
|
||
.. [#tromer-comment] `Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019. <https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55>`_
|
||
.. [#restricted-funds] `“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018. <https://www.501c3.org/kb/what-are-restricted-funds/>`_
|
||
.. [#zfnd-grants] `ZF Grants — Funding for Zcash ecosystem projects <https://grants.zfnd.org/>`_
|
||
.. [#zfnd-state] `The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. <https://www.zfnd.org/blog/foundation-in-2019/>`_
|
||
.. [#acityinohio-comment] `Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019. <https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/38>`_
|
||
.. [#zip-1007] `ZIP 1007: Enforce Development Fund Commitments with a Legal Charter <zip-1007.rst>`_
|