From 698a826c789b9313d735ec345f09334c1162a6cd Mon Sep 17 00:00:00 2001 From: Josh Cincinnati Date: Sat, 31 Aug 2019 23:45:22 -0400 Subject: [PATCH 1/6] adds my dev fund proposal --- zip-1337.md | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 zip-1337.md diff --git a/zip-1337.md b/zip-1337.md new file mode 100644 index 00000000..611f4f5a --- /dev/null +++ b/zip-1337.md @@ -0,0 +1,156 @@ +``` + ZIP: ??? + Title: Compromise Dev Fund Proposal With Diverse Funding Streams + Owner: Josh Cincinnati + 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](https://tools.ietf.org/html/rfc2119) + +The term "network upgrade" in this document is to be interpreted as +described in ZIP 200. [#zip-0200](https://github.com/zcash/zips/blob/master/zip-0200.rst) + +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](https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/) 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](https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55), 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](https://www.501c3.org/kb/what-are-restricted-funds/) purely for disbursement through [ZF Grants](https://grants.zfnd.org/), 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](https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/) 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](https://www.zfnd.org/blog/foundation-in-2019/) + +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](https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter) 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? From 42df5af63e6bc54c5619c1ad7cd68960c038b670 Mon Sep 17 00:00:00 2001 From: Josh Cincinnati Date: Wed, 13 Nov 2019 11:00:27 -0500 Subject: [PATCH 2/6] grammar fix Co-Authored-By: John Light --- zip-1337.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-1337.md b/zip-1337.md index 611f4f5a..b9d8a6b1 100644 --- a/zip-1337.md +++ b/zip-1337.md @@ -72,7 +72,7 @@ Upon the NU4 network activation, 20% of the mining reward (post-Blossom/post-hal Here I'm borrowing from [the Foundation's guidance](https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/) 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 +- Published 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](https://www.zfnd.org/blog/foundation-in-2019/) From f39dfae9ee8d807edee9c221bc74ace505b750a0 Mon Sep 17 00:00:00 2001 From: Josh Cincinnati Date: Wed, 13 Nov 2019 11:01:12 -0500 Subject: [PATCH 3/6] more grammar fixes Co-Authored-By: John Light --- zip-1337.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-1337.md b/zip-1337.md index b9d8a6b1..e20bd284 100644 --- a/zip-1337.md +++ b/zip-1337.md @@ -127,7 +127,7 @@ With all due respect to the proposers behind some variant of a "2-of-3 multisig" > 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. +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, 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. From feeb6590643e888f4a06e96868e15a2be1e330cf Mon Sep 17 00:00:00 2001 From: Josh Cincinnati Date: Wed, 13 Nov 2019 17:26:47 -0500 Subject: [PATCH 4/6] significant rewrite of the proposal --- zip-1337.md | 61 ++++++++++++++++++++++++----------------------------- 1 file changed, 27 insertions(+), 34 deletions(-) diff --git a/zip-1337.md b/zip-1337.md index e20bd284..4baea067 100644 --- a/zip-1337.md +++ b/zip-1337.md @@ -2,7 +2,7 @@ ZIP: ??? Title: Compromise Dev Fund Proposal With Diverse Funding Streams Owner: Josh Cincinnati - Credits: Eran Tromer, Andrew Miller, mistfpga, lex-node, and many others + Credits: Matt Luongo, 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/ @@ -23,7 +23,7 @@ described in ZIP 200. [#zip-0200](https://github.com/zcash/zips/blob/master/zip- 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.__ +__I try to put the best pieces of various proposals together. A 20% of the block reward for a 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, all while carving out a limited-scoped opportunity for extending governance to more groups than the ECC/ZF.__ Motivation ========== @@ -34,39 +34,33 @@ The Foundation, ECC, and broader community has offered many suggestions and guid - The ECC and Zcash Foundation shouldn't get a blank check; accountability is a prerequisite for any disbursement, based on the [Foundation's statement](https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/) 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](https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55), 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 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) +*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](https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55). 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 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 +- 30% of the fund 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 +- 30% to the fund 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 +- 40% to the fund to the Zcash Foundation as a [RESTRICTED donation](https://www.501c3.org/kb/what-are-restricted-funds/) purely for disbursement through [ZF Grants](https://grants.zfnd.org/), with additional restrictions and stipulations described below -- 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](https://www.501c3.org/kb/what-are-restricted-funds/) purely for disbursement through [ZF Grants](https://grants.zfnd.org/), 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: +0.625ZEC * 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: -- 13125 ZEC to the ECC for meeting accountability requirements +- 19687.5 ZEC to the ECC for meeting accountability requirements -- 13125 ZEC to the Zcash Foundation for meeting accountability requirements +- 19687.5 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) +- 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) ### The trust's accountability requirements @@ -78,7 +72,7 @@ Here I'm borrowing from [the Foundation's guidance](https://www.zfnd.org/blog/de 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) +- 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) @@ -90,29 +84,30 @@ Additionally, for the ECC, the trust MUST validate the following before each dis - 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). +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 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 could also chose to fund ZF Grants _beyond_ the restricted donations from the trust, but doing so would be at their discretion. -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. +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](https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/38) 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/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 ========= @@ -129,11 +124,11 @@ With all due respect to the proposers behind some variant of a "2-of-3 multisig" 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, 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. +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 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](https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter) for legal covenants on funding. +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](https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter) for legal covenants on funding. Security and Privacy Considerations =================================== @@ -150,7 +145,5 @@ 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? +- 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) From 22b350cf20b00b61b65aa61df47cbca595d5cbfb Mon Sep 17 00:00:00 2001 From: Josh Cincinnati Date: Wed, 13 Nov 2019 18:01:27 -0500 Subject: [PATCH 5/6] removes trust cost question --- zip-1337.md | 1 - 1 file changed, 1 deletion(-) diff --git a/zip-1337.md b/zip-1337.md index 4baea067..c7a09323 100644 --- a/zip-1337.md +++ b/zip-1337.md @@ -144,6 +144,5 @@ 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) - 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) From f36e0320a2de53c89d3c220637bdd0ec51475275 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 25 Nov 2019 21:21:49 +0000 Subject: [PATCH 6/6] ZIP 1010: Editing to regularize all the dev fund ZIPs. Signed-off-by: Daira Hopwood --- README.rst | 1 + index.html | 1 + zip-1010.html | 216 ++++++++++++++++++++++++++++++ zip-1010.rst | 353 ++++++++++++++++++++++++++++++++++++++++++++++++++ zip-1337.md | 148 --------------------- 5 files changed, 571 insertions(+), 148 deletions(-) create mode 100644 zip-1010.html create mode 100644 zip-1010.rst delete mode 100644 zip-1337.md diff --git a/README.rst b/README.rst index 415b7a9b..6c0e394a 100644 --- a/README.rst +++ b/README.rst @@ -91,5 +91,6 @@ Index of ZIPs 1007 Enforce Development Fund Commitments with a Legal Charter Draft 1008 Fund ECC for Two More Years Draft 1009 Five-Entity Strategic Council Draft + 1010 Compromise Dev Fund Proposal With Diverse Funding Streams Draft guide {Something Short and To the Point} Draft diff --git a/index.html b/index.html index 2f0a17c1..ce2741a2 100644 --- a/index.html +++ b/index.html @@ -91,6 +91,7 @@ 1007 Enforce Development Fund Commitments with a Legal Charter Draft 1008 Fund ECC for Two More Years Draft 1009 Five-Entity Strategic Council Draft + 1010 Compromise Dev Fund Proposal With Diverse Funding Streams Draft guide {Something Short and To the Point} Draft diff --git a/zip-1010.html b/zip-1010.html new file mode 100644 index 00000000..676d666d --- /dev/null +++ b/zip-1010.html @@ -0,0 +1,216 @@ + + + + ZIP 1010: Compromise Dev Fund Proposal With Diverse Funding Streams + + + +
+ 
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. 1

+

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 2

+
+
+

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

+

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 3 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.)
    • +
+

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 4. 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 5 purely for disbursement through ZF Grants 6, with additional restrictions and stipulations described below.
    • +
+

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 3 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 7.
    • +
+

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 8 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 9 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

+ + + + + + + +
1Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2ZIP 200: Network Upgrade Mechanism
+ + + + + + + +
3Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019.
+ + + + + + + +
4Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019.
+ + + + + + + +
5“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018.
+ + + + + + + +
6ZF Grants — Funding for Zcash ecosystem projects
+ + + + + + + +
7The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019.
+ + + + + + + +
8Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019.
+ + + + + + + +
9ZIP 1007: Enforce Development Fund Commitments with a Legal Charter
+
+
+ + \ No newline at end of file diff --git a/zip-1010.rst b/zip-1010.rst new file mode 100644 index 00000000..b50849c7 --- /dev/null +++ b/zip-1010.rst @@ -0,0 +1,353 @@ +:: + + ZIP: 1010 + Title: Compromise Dev Fund Proposal With Diverse Funding Streams + Owner: Josh Cincinnati + 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: + + +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 `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ +.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. `_ +.. [#tromer-comment] `Comment on a post “How to hire ECC” in the Zcash Community Forum. Eran Tromer, August 11, 2019. `_ +.. [#restricted-funds] `“What Are Restricted Funds?” Foundation Group, last modified December 7, 2018. `_ +.. [#zfnd-grants] `ZF Grants — Funding for Zcash ecosystem projects `_ +.. [#zfnd-state] `The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. `_ +.. [#acityinohio-comment] `Comment on a post “Decentralizing the Dev Fee” in the Zcash Community Forum. Josh Cincinnati, October 27, 2019. `_ +.. [#zip-1007] `ZIP 1007: Enforce Development Fund Commitments with a Legal Charter `_ diff --git a/zip-1337.md b/zip-1337.md deleted file mode 100644 index c7a09323..00000000 --- a/zip-1337.md +++ /dev/null @@ -1,148 +0,0 @@ -``` - ZIP: ??? - Title: Compromise Dev Fund Proposal With Diverse Funding Streams - Owner: Josh Cincinnati - Credits: Matt Luongo, 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](https://tools.ietf.org/html/rfc2119) - -The term "network upgrade" in this document is to be interpreted as -described in ZIP 200. [#zip-0200](https://github.com/zcash/zips/blob/master/zip-0200.rst) - -Abstract -======== - -__I try to put the best pieces of various proposals together. A 20% of the block reward for a 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, 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](https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/) 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/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, 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) - -*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](https://forum.zcashcommunity.com/t/how-to-hire-ecc/34379/55). 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 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: - -- 30% of the fund to the ECC, if they meet the accountability requirements set by the trust/described below - -- 30% to the fund to the Zcash Foundation, if they meet the accountability requirements set by the trust/described below - -- 40% to the fund to the Zcash Foundation as a [RESTRICTED donation](https://www.501c3.org/kb/what-are-restricted-funds/) purely for disbursement through [ZF Grants](https://grants.zfnd.org/), 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. 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) - -### The trust's accountability requirements - -Here I'm borrowing from [the Foundation's guidance](https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/) 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 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](https://www.zfnd.org/blog/foundation-in-2019/) - -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 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 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. (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 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 could 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](https://forum.zcashcommunity.com/t/decentralizing-the-dev-fee/35252/38) 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/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](https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter) 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)