zips/zip-1010.rst

::

  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: Obsolete
  Category: Consensus Process
  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] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#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>`_