A Grand Compromise/Synthesis ZIP Proposal

Community Collaborations protocol
30

More formal proposal below:

  ZIP: ???
  Title: Compromise Dev Fund Proposal With Diverse Funding Streams
  Owner: Josh Cincinnati <josh@zfnd.org>
  Credits: Eran Tromer, Andrew Miller, mistfpga, lex-node, and many others
  Status: Draft
  Category: Consensus
  Discussions-To: https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812/
  Created: 2019-08-31
  License: MIT

Terminology

The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”,
“OPTIONAL”, and “REQUIRED” 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 reward for 4 year dev fund that disburses to a trust controlled by both the ECC and Zcash Foundation 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, ties some of the payouts to shielded adoption, all while carving out a limited-scoped opportunity for extending governance to more groups than the ECC/ZF.

Motivation

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 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.
  • Based on the ideas brought forward by Eran Tromer, a portion of the funds directed to the ECC / Zcash Foundation should be based on shielded adoption, which is the most pressing issue facing Zcash today and unlike many other metrics is both easily measurable and less likely to be gamed. (compared to a miner-signaling proposal for example)
  • A nontrivial portion of the funds should be directed to users/orgs 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” proposal).
  • 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.
  • 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)

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 view 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 105,000 blocks (a quarter of the year) until 1,680,000 blocks after activation (the next halvening), the trust SHOULD disburse funds the following way, requiring a public report with every disbursement:

  • 4% to the ECC, if they meet the accountability requirements set by the trust/described below

  • 4% to the Zcash Foundation, if they meet the accountability requirements set by the trust/described below

  • Up to an additional 4% to the ECC proportionally based on average amount of shielded value (scaled to 80% shielded as “fully shielded”) over total supply over the last 105,000 blocks, with the remainder held in escrow until Zcash is “fully shielded” for at least a month

  • Up to an additional 4% to the Zcash Foundation proportionally based on average amount of shielded value (scaled to 80% shielded as “fully shielded”) over total supply for the last 105,000 blocks, with the remainder held in escrow until Zcash is “fully shielded” for at least a month

  • 4% to the Zcash Foundation as a RESTRICTED donation purely for disbursement through ZF Grants, with additional restrictions and stipulations described below

Example disbursements by the trust for a hypothetical 105000 block period

0.625ZEC * 105000 = 65625 ZEC accrued in the trust every quarter. For the first quarter/simplicity’s sake, let’s assume that 20% of the total value was shielded on average and that both the ECC and Zcash Foundation met the accountability requirements set by the trust. Then disbursements would look like this:

  • 13125 ZEC to the ECC for meeting accountability requirements

  • 13125 ZEC to the Zcash Foundation for meeting accountability requirements

  • 13125 * minimum(0.2,0.8)/0.8 (80% considered “fully shielded”) shielded adoption = 3281.25 additional ZEC to the ECC for shielded adoption. 9843.75 ZEC would be held in escrow by the trust until Zcash is “fully shielded” whereupon the balance will be disbursed to the ECC.

  • 13125 * minimum(0.2,0.8)/0.8 (80% considered “fully shielded”) shielded adoption = 3281.25 additional ZEC to the Zcash Foundation for shielded adoption. 9843.75 ZEC would be held in escrow by the trust until Zcash is “fully shielded” whereupon the balance will be disbursed to the Zcash Foundation.

  • 13125 ZEC to ZF Grants to be disbursed to external individuals and organizations (via the Zcash Foundation as a restricted donation)

The trust’s accountability requirements

Here I’m borrowing from the Foundation’s 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 a quarterly tech roadmap reports and financial reports, detailing spending levels/burn rate and cash/ZEC on hand

  • (if beginning of calendar year) Published a yearly review of organization performance, along the lines of the Zcash Foundation’s “State of the Foundation” report

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)

  • 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 beginning of 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 portion of the dev fund went into speculative investments in other companies 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.

The shielded adoption metric

I applaud Eran Tromer’s suggestion for tying some portion of the dev fund to shielded adoption. It’s a great tool for adding a protocol-verified accountability metric and I hope it’s considered in many of the other proposals as well. My particular adaptation of it provides for some floor of funding for both the ECC and Zcash Foundation, while providing a variable payout based on shielded uptake (scaled to 80% as “fully shielded” to incorporate the possibility of lost value in transparent balances and protect against a single entity holding veto power against shielded uptake). Rather than reward the remaining ZEC to miners — which could cause perverse behavior where miners might censor shielded transactions — the trust would hold the remaining ZEC in escrow, to be paid out to both organizations in lump sum upon reaching a “fully shielded” world during the next quarterly disbursement.

I define the “fully shielded” condition as follows: we have 35,000 sequential blocks where the shielded value pool is 80%+ shielded for that same time period. The bonus can be held until after the dev fund expires, though I certainly hope we’ll reach that condition before then.

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. (aka 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 SHOULDN’T decide where those funds go; instead, the trust MUST demand that the ZF Grants process expand its decision-making process and include broader input. 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).

In terms of selecting those third parties, I don’t have a silver bullet…which is very much the issue with “third party” selection in general. However, I think the Foundation’s Board election last year was a pretty good model. One possibility is to have a more open community advisory panel next year and follow the same steps for those three seats, and rotate them yearly — perhaps eventually changing the vote to originate from the shielded pool instead of an advisory panel. Those grant reviewers would be charged with judging new grants and selecting RFPs on a weekly basis, and the Foundation would be charged with administering their decisions. The Foundation could also chose to fund ZF Grants beyond the restricted donations from the trust, but doing so would be at their discretion.

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 finds 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, and assumes an eventual 2-of-2 agreement on the trademark and 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), while it doesn’t preclude the possibility of migrating to broader “2-of-3” later on.

Why a trust?

The main reason: reducing complexity creep in consensus code so the ECC and Zcash Foundation can budget for other features in NU4. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 deadline 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 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?
  • Who bears the cost of running the trust? (I think jointly split between the ECC and ZF makes sense)
  • Should the trust own the Zcash trademark? It could effectively function as a 2-of-2 agreement between the ECC and ZF.
  • Is there any way the shielded adoption metric could be gamed?
  • Are the amounts reasonable? Should the dev fund be less than 20% in aggregate?
  • How do we select representatives for the ZF Grants 3-of-5 body that aren’t from the ECC or ZF?
6 Likes