Merge pull request #295 from daira/zip1003

ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
This commit is contained in:
Daira Hopwood 2019-11-21 15:51:53 +00:00 committed by GitHub
commit ac7594e6ca
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 297 additions and 0 deletions

View File

@ -84,6 +84,7 @@ Index of ZIPs
<tr> <td>401</td> <td class="left"><a href="zip-0401.rst">Addressing mempool denial-of-service</a></td> <td>Final</td>
<tr> <td>1001</td> <td class="left"><a href="zip-1001.rst">Keep the Block Distribution as Initially Defined — 90% to Miners</a></td> <td>Draft</td>
<tr> <td>1002</td> <td class="left"><a href="zip-1002.rst">Opt-in Donation Feature</a></td> <td>Draft</td>
<tr> <td>1003</td> <td class="left"><a href="zip-1003.rst">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></td> <td>Draft</td>
<tr> <td>1006</td> <td class="left"><a href="zip-1006.rst">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></td> <td>Draft</td>
<tr> <td>1007</td> <td class="left"><a href="zip-1007.rst">Enforce Development Fund Commitments with a Legal Charter</a></td> <td>Draft</td>
<tr> <td>1008</td> <td class="left"><a href="zip-1008.rst">Fund ECC for Two More Years</a></td> <td>Draft</td>

View File

@ -84,6 +84,7 @@
<tr> <td>401</td> <td class="left"><a href="zip-0401">Addressing mempool denial-of-service</a></td> <td>Final</td>
<tr> <td>1001</td> <td class="left"><a href="zip-1001">Keep the Block Distribution as Initially Defined — 90% to Miners</a></td> <td>Draft</td>
<tr> <td>1002</td> <td class="left"><a href="zip-1002">Opt-in Donation Feature</a></td> <td>Draft</td>
<tr> <td>1003</td> <td class="left"><a href="zip-1003">20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</a></td> <td>Draft</td>
<tr> <td>1006</td> <td class="left"><a href="zip-1006">Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity</a></td> <td>Draft</td>
<tr> <td>1007</td> <td class="left"><a href="zip-1007">Enforce Development Fund Commitments with a Legal Charter</a></td> <td>Draft</td>
<tr> <td>1008</td> <td class="left"><a href="zip-1008">Fund ECC for Two More Years</a></td> <td>Draft</td>

127
zip-1003.html Normal file
View File

@ -0,0 +1,127 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 1003: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate</title>
<meta charset="utf-8" />
<link rel="stylesheet" href="css/zip-style.css"><link rel="stylesheet" href="assets/css/style.css"></head>
<body>
<section>
<pre>ZIP: 1003
Title: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
Owner: aristarchus (zcash forums)
Status: Draft
Category: Consensus / Process
Created: 2019-06-19
License: MIT
Discussions-To: &lt;https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862&gt;</pre>
<section id="terminology">
<h2>Terminology</h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>For clarity in this ZIP I define these terms:</p>
<dl>
<dt>2nd Halvening period</dt>
<dd>the 4-year period of time, roughly from October 2020 to October 2024, during which at most 5,250,000 ZEC will be minted.</dd>
<dt>3rd Halvening period</dt>
<dd>the 4-year period of time roughly from October 2024 to October 2028.</dd>
<dt>DF%</dt>
<dd>Dev Fund Percentage, the portion of newly minted ZEC in each block reserved for a development fund.</dd>
</dl>
</section>
<section id="abstract">
<h2>Abstract</h2>
<p>This proposal would allocate a 20% Dev Fund Percentage to be split evenly between the Electric Coin Company (ECC) and the Zcash Foundation during the 2nd Halvening period. This proposal aims to be simple to implement, without a single point of failure, and comes with mandates for transparency, accountability and a mandate to build a development fund voting mechanism to be used during the 3rd Halvening period. This proposal is designed to strike a balance between ensuring that high quality development work can continue uninterrupted, with the need to further decentralize Zcash development funding as soon as possible.</p>
</section>
<section id="motivation">
<h2>Motivation</h2>
<p>Strengths of this proposal:</p>
<ol type="1">
<li>Simple to implement. I would rather developers spend time scaling Zcash rather than implementing the development funding mechanism.</li>
<li>Developers will have several years to work on a great decentralized development funding voting mechanism.</li>
<li>20% is a large enough percentage that there should be enough development funding for many different ZEC price scenarios. To those who want to decrease this percentage: Overpaying for security is a gift to miners, to the detriment of every other stakeholder in the Zcash community. I will even make the strong statement that intentionally overpaying the miners for security is stealing from the other stakeholders.</li>
<li>With two entities receiving funds there is no single point of failure.</li>
</ol>
</section>
<section id="requirements-and-specification">
<h2>Requirements and Specification</h2>
<ol type="1">
<li>DF% MUST be 20 percent, split evenly between ECC and the Zcash Foundation during the 2nd Halvening period.</li>
<li>The Dev Fund MUST only be spent on research, development and adoption of Zcash.</li>
<li>A voting system for development funding MUST be built and implemented in order to be used during the 3rd Halvening period.</li>
</ol>
<section id="voting-system-requirements">
<h3>Voting System Requirements</h3>
<p>Here are the general properties of the mandated voting mechanism. I dont want to specify the technical implementation details, since I believe this is a job suited for the engineers building this system.</p>
<ol type="1">
<li>Voting SHOULD be private.</li>
<li>Only ZEC holders can vote.</li>
<li>Voting should happen on-chain.</li>
<li>In order to vote, you must lock your ZEC so it cannot be spent for a period of time. This is to force the voters to have skin in the game and prevent someone nefarious from buying a lot of ZEC just before an election and then dumping it immediately after.</li>
<li>Voters can choose how long to lock their ZEC, and their voting power is proportional to the time that the ZEC is locked. For example, someone who votes with 10 ZEC and locks it for 6 months would have the same voting power as someone who votes with 20 ZEC and locks it for 3 months. Of course there must be a maximum lock time, perhaps a year, to prevent anyone from getting infinite voting power by locking their ZEC permanently.</li>
<li>The final results of the vote should be transparent to and verifiable by everyone.</li>
<li>The system should be totally open and allow anyone/any organization to compete for funding to develop Zcash.</li>
</ol>
</section>
<section id="transparency-and-accountability-for-the-ecc-and-the-zcash-foundation">
<h3>Transparency and Accountability for the ECC and the Zcash Foundation</h3>
<p>These requirements would apply to both ECC and the Zcash Foundation. The mandate is to adhere to these accountability requirements originally put forward by the Foundation:</p>
<ul>
<li>Monthly public developer calls, detailing current technical roadmap and updates.</li>
<li>Quarterly technology roadmap reports and updates.</li>
<li>Quarterly financial reports, detailing spending levels/burn rate and cash/ZEC on hand.</li>
<li>A yearly, audited financial report akin to the Form 990 for US-based nonprofits.</li>
<li>Yearly reviews of organization performance, along the lines of the State of the Zcash Foundation report <a href="#zfnd-state" id="id2" class="footnote_reference">2</a>.</li>
</ul>
</section>
<section id="requirements-specifically-for-the-ecc">
<h3>Requirements Specifically for the ECC</h3>
<p>Motivated by the Zcash Foundations proposal that the ECC become a non-profit <a href="#zfnd-guidance" id="id3" class="footnote_reference">3</a>, I am going to list general requirements for the ECC to abide by if they choose to receive funds and work on behalf of ZEC holders.</p>
<ol type="1">
<li>Because I share the Foundations concern that the ECC could be “beholden to its shareholders”, I am mandating that the ECC should be working in the service of the Zcash community and <strong>shall serve no other masters</strong>. The original investors/founders who are not still working in the service of the Zcash community SHOULD NOT have control over the use of the new development funds.</li>
<li>The revenue received from the Dev Fund SHOULD NOT be used to give further rewards to, even indirectly, the investors, founders, or shareholders of the ECC, who are not working on Zcash after the first halving. <strong>They have already received the Founders Reward and this new development fund is not supposed to further benefit them.</strong></li>
<li>The ECC SHOULD offer competitive pay and <strong>a stake in upside of the success of Zcash as a way to attract the best and brightest</strong>. I do want the ECC be able to <strong>maintain a world class team</strong> capable of competing with the tech giants of the world (Google, Apple etc.).</li>
<li>The ECC SHOULD <strong>continue to engage with regulators</strong> and advocate for privacy preserving technology. The <strong>legal structure of the ECC must not hamper these critical efforts</strong> in any way.</li>
</ol>
<p>I am not mandating non-profit status for the ECC. Maybe that is the best legal structure, maybe something else is better.</p>
<p>Finally, in the event that the voting system isnt implemented by the start of the 3rd Halvening period, the 20% of funds intended to go to the voting development fund should by default be sent to a burn address.</p>
</section>
</section>
<section id="references">
<h2>References</h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-state" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.zfnd.org/blog/foundation-in-2019/">The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019.</a></td>
</tr>
</tbody>
</table>
<table id="zfnd-guidance" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/">Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019.</a></td>
</tr>
</tbody>
</table>
</section>
<section id="change-log">
<h2>Change Log</h2>
<ul>
<li>2019-06-19 Initial post</li>
<li>2019-26-07 Listed three strengths of this proposal</li>
<li>2019-08-13 Voting System Requirements</li>
<li>2019-08-20 Requirements Specifically for the ECC</li>
<li>2019-08-29 Update to be more like a ZIP draft.</li>
</ul>
</section>
</section>
</body>
</html>

168
zip-1003.rst Normal file
View File

@ -0,0 +1,168 @@
::
ZIP: 1003
Title: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
Owner: aristarchus (zcash forums)
Status: Draft
Category: Consensus / Process
Created: 2019-06-19
License: MIT
Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-proposal-20-split-between-the-ecc-and-the-foundation/33862>
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document
are to be interpreted as described in RFC 2119. [#RFC2119]_
For clarity in this ZIP I define these terms:
2nd Halvening period
the 4-year period of time, roughly from October 2020 to October 2024,
during which at most 5,250,000 ZEC will be minted.
3rd Halvening period
the 4-year period of time roughly from October 2024 to October 2028.
DF%
Dev Fund Percentage, the portion of newly minted ZEC in each block
reserved for a development fund.
Abstract
========
This proposal would allocate a 20% Dev Fund Percentage to be split evenly
between the Electric Coin Company (ECC) and the Zcash Foundation during the
2nd Halvening period. This proposal aims to be simple to implement, without
a single point of failure, and comes with mandates for transparency,
accountability and a mandate to build a development fund voting mechanism
to be used during the 3rd Halvening period. This proposal is designed to
strike a balance between ensuring that high quality development work can
continue uninterrupted, with the need to further decentralize Zcash
development funding as soon as possible.
Motivation
==========
Strengths of this proposal:
1. Simple to implement. I would rather developers spend time scaling Zcash
rather than implementing the development funding mechanism.
2. Developers will have several years to work on a great decentralized
development funding voting mechanism.
3. 20% is a large enough percentage that there should be enough development
funding for many different ZEC price scenarios. To those who want to
decrease this percentage: Overpaying for security is a gift to miners,
to the detriment of every other stakeholder in the Zcash community.
I will even make the strong statement that intentionally overpaying the
miners for security is stealing from the other stakeholders.
4. With two entities receiving funds there is no single point of failure.
Requirements and Specification
==============================
1. DF% MUST be 20 percent, split evenly between ECC and the Zcash Foundation
during the 2nd Halvening period.
2. The Dev Fund MUST only be spent on research, development and adoption of
Zcash.
3. A voting system for development funding MUST be built and implemented in
order to be used during the 3rd Halvening period.
Voting System Requirements
--------------------------
Here are the general properties of the mandated voting mechanism. I dont
want to specify the technical implementation details, since I believe this
is a job suited for the engineers building this system.
1. Voting SHOULD be private.
2. Only ZEC holders can vote.
3. Voting should happen on-chain.
4. In order to vote, you must lock your ZEC so it cannot be spent for a
period of time. This is to force the voters to have skin in the game
and prevent someone nefarious from buying a lot of ZEC just before an
election and then dumping it immediately after.
5. Voters can choose how long to lock their ZEC, and their voting power is
proportional to the time that the ZEC is locked. For example, someone
who votes with 10 ZEC and locks it for 6 months would have the same
voting power as someone who votes with 20 ZEC and locks it for 3 months.
Of course there must be a maximum lock time, perhaps a year, to prevent
anyone from getting infinite voting power by locking their ZEC
permanently.
6. The final results of the vote should be transparent to and verifiable by
everyone.
7. The system should be totally open and allow anyone/any organization to
compete for funding to develop Zcash.
Transparency and Accountability for the ECC and the Zcash Foundation
--------------------------------------------------------------------
These requirements would apply to both ECC and the Zcash Foundation. The
mandate is to adhere to these accountability requirements originally put
forward by the Foundation:
* Monthly public developer calls, detailing current technical roadmap and
updates.
* Quarterly technology roadmap reports and updates.
* Quarterly financial reports, detailing spending levels/burn rate and
cash/ZEC on hand.
* A yearly, audited financial report akin to the Form 990 for US-based
nonprofits.
* Yearly reviews of organization performance, along the lines of the
State of the Zcash Foundation report [#zfnd-state]_.
Requirements Specifically for the ECC
-------------------------------------
Motivated by the Zcash Foundations proposal that the ECC become a non-profit
[#zfnd-guidance]_, I am going to list general requirements for the ECC to
abide by if they choose to receive funds and work on behalf of ZEC holders.
1. Because I share the Foundations concern that the ECC could be “beholden
to its shareholders”, I am mandating that the ECC should be working in
the service of the Zcash community and **shall serve no other masters**.
The original investors/founders who are not still working in the service
of the Zcash community SHOULD NOT have control over the use of the new
development funds.
2. The revenue received from the Dev Fund SHOULD NOT be used to give further
rewards to, even indirectly, the investors, founders, or shareholders of
the ECC, who are not working on Zcash after the first halving.
**They have already received the Founders Reward and this new development
fund is not supposed to further benefit them.**
3. The ECC SHOULD offer competitive pay and **a stake in upside of the
success of Zcash as a way to attract the best and brightest**. I do want
the ECC be able to **maintain a world class team** capable of competing
with the tech giants of the world (Google, Apple etc.).
4. The ECC SHOULD **continue to engage with regulators** and advocate for
privacy preserving technology. The **legal structure of the ECC must not
hamper these critical efforts** in any way.
I am not mandating non-profit status for the ECC. Maybe that is the best
legal structure, maybe something else is better.
Finally, in the event that the voting system isnt implemented by the start
of the 3rd Halvening period, the 20% of funds intended to go to the voting
development fund should by default be sent to a burn address.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zfnd-state] `The State of the Zcash Foundation in 2019. Zcash Foundation blog, January 31, 2019. <https://www.zfnd.org/blog/foundation-in-2019/>`_
.. [#zfnd-guidance] `Zcash Foundation Guidance on Dev Fund Proposals. Zcash Foundation blog, August 6, 2019. <https://www.zfnd.org/blog/dev-fund-guidance-and-timeline/>`_
Change Log
==========
* 2019-06-19 Initial post
* 2019-26-07 Listed three strengths of this proposal
* 2019-08-13 Voting System Requirements
* 2019-08-20 Requirements Specifically for the ECC
* 2019-08-29 Update to be more like a ZIP draft.