forked from ZcashFoundation/zips
-
Notifications
You must be signed in to change notification settings - Fork 1
/
zip-1010.html
201 lines (201 loc) · 25.1 KB
/
zip-1010.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>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
Created: 2019-08-31
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/a-grand-compromise-synthesis-zip-proposal/34812/></pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">2</a></p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>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.</p>
</section>
<section id="motivation-and-requirements"><h2><span class="section-heading">Motivation and Requirements</span><span class="section-anchor"> <a href="#motivation-and-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>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.</p>
<p>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:</p>
<ul>
<li>The ECC and Zcash Foundation shouldn't get a blank check; accountability is a prerequisite for any disbursement, based on the Foundation's statement <a id="id3" class="footnote_reference" href="#zfnd-guidance">3</a> and other proposals being suggested.</li>
<li>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.</li>
<li>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).</li>
<li>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.</li>
<li>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.)</li>
</ul>
<p><span class="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.</span></p>
<p><em>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</em> <a id="id4" class="footnote_reference" href="#tromer-comment">4</a>. <em>After many discussions I came to worry about the gameability of the metric and decided to drop it entirely.</em></p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>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:</p>
<ul>
<li>30% of the fund to the ECC, if they meet the accountability requirements set by the trust/described below;</li>
<li>30% of the fund to the Zcash Foundation, if they meet the accountability requirements set by the trust/described below;</li>
<li>40% of the fund to the Zcash Foundation as a RESTRICTED donation <a id="id5" class="footnote_reference" href="#restricted-funds">5</a> purely for disbursement through ZF Grants <a id="id6" class="footnote_reference" href="#zfnd-grants">6</a>, with additional restrictions and stipulations described below.</li>
</ul>
<p><span class="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.</span></p>
<section id="example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period"><h3><span class="section-heading">Example disbursements by the trust for a hypothetical 105000-block period</span><span class="section-anchor"> <a href="#example-disbursements-by-the-trust-for-a-hypothetical-105000-block-period"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>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:</p>
<ul>
<li>19687.5 ZEC to the ECC for meeting accountability requirements.</li>
<li>19687.5 ZEC to the Zcash Foundation for meeting accountability requirements.</li>
<li>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).</li>
</ul>
<p>This example assumes no change to target block spacing.</p>
</section>
<section id="the-trust-s-accountability-requirements"><h3><span class="section-heading">The trust's accountability requirements</span><span class="section-anchor"> <a href="#the-trust-s-accountability-requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Here I'm borrowing from the Foundation's guidance <a id="id7" class="footnote_reference" href="#zfnd-guidance">3</a> 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:</p>
<ul>
<li>Published quarterly technical roadmap reports and financial reports, detailing spending levels/burn rate and cash/ZEC on hand;</li>
<li>(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 <a id="id8" class="footnote_reference" href="#zfnd-state">7</a>.</li>
</ul>
<p>For the Zcash Foundation, the trust MUST further require:</p>
<ul>
<li>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);</li>
<li>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).</li>
</ul>
<p>Additionally, for the ECC, the trust MUST validate the following before each disbursement:</p>
<ul>
<li>(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));</li>
<li>No outside investment was received while they are obligatory recipients of this dev fund;</li>
<li>No portion of the dev fund went to dividends, profit-sharing, or share/equity buybacks while they are obligatory recipients of this dev fund;</li>
<li>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;</li>
<li>There's no change-of-control (majority control changes) at the ECC while they are obligatory recipients of this dev fund;</li>
</ul>
<p>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.</p>
</section>
<section id="what-happens-in-the-case-of-a-violation"><h3><span class="section-heading">What happens in the case of a violation</span><span class="section-anchor"> <a href="#what-happens-in-the-case-of-a-violation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>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.)</p>
</section>
<section id="the-zf-grants-portion"><h3><span class="section-heading">The ZF Grants portion</span><span class="section-anchor"> <a href="#the-zf-grants-portion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>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 <em>beyond</em> the restricted donations from the trust, but doing so would be at their discretion.</p>
<p>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 <a id="id9" class="footnote_reference" href="#acityinohio-comment">8</a> and modifying them to apply to a ZF Grants-specific Grant Review Committee, rather than the Foundation's board.</p>
<p>The ZF Grant Review Committee would be compromised of five members, voted on in the following manner:</p>
<ul>
<li>1 seat for the ECC. Though the appointed member may change, they retain power to choose the seat for 4 years.</li>
<li>1 seat for the Zcash Foundation. Though the appointed member may change, they retain power to choose the seat for 4 years.</li>
<li>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.</li>
<li>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.</li>
</ul>
<p>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.</p>
</section>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>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.</p>
<section id="a-word-on-the-enigmatic-third-party-floating-around"><h3><span class="section-heading">A word on the enigmatic "third party" floating around</span><span class="section-anchor"> <a href="#a-word-on-the-enigmatic-third-party-floating-around"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>With all due respect to the proposers behind some variant of a "2-of-3 multisig" decision-making process for <em>all</em> disbursement decisions: I think this is a bad idea. To quote a previous forum post of mine:</p>
<blockquote>
<p>...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.</p>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>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 <em>wouldn't</em> 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.</p>
</section>
<section id="why-a-trust"><h3><span class="section-heading">Why a trust?</span><span class="section-anchor"> <a href="#why-a-trust"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>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 <a id="id10" class="footnote_reference" href="#zip-1007">9</a> for legal covenants on funding.</p>
</section>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>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").</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBD, but it should be relatively simple to code in both zebra and zcashd.</p>
</section>
<section id="issues-and-further-discussion"><h2><span class="section-heading">Issues and further discussion</span><span class="section-anchor"> <a href="#issues-and-further-discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>What are the tax implications for setting up the trust?</li>
<li>Are the amounts reasonable? Should the dev fund be less than 20% in aggregate?</li>
<li>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.)</li>
</ul>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-guidance" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/">Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="tromer-comment" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55">Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="restricted-funds" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="https://www.501c3.org/kb/what-are-restricted-funds/">“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018.</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-grants" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://grants.zfnd.org/">ZF Grants — Funding for Zcash ecosystem projects</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-state" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://www.zfnd.org/blog/foundation-in-2019/">The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="acityinohio-comment" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/38">Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="zip-1007" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="zip-1007">ZIP 1007: Enforce Development Fund Commitments with a Legal Charter</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>