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 2019) 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 2020)
|
|||
|
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>`_
|