172 lines
7.3 KiB
ReStructuredText
172 lines
7.3 KiB
ReStructuredText
::
|
||
|
||
ZIP: 1003
|
||
Title: 20% Split Evenly Between the ECC and the Zcash Foundation, and a Voting System Mandate
|
||
Owner: aristarchus (zcash forums)
|
||
Status: Obsolete
|
||
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 don’t
|
||
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 Foundation’s 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 Foundation’s 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 isn’t implemented by the start
|
||
of the 3rd Halvening period, the 20% of funds intended to go to the ‘voting
|
||
development fund’ should instead not be minted.
|
||
|
||
|
||
References
|
||
==========
|
||
|
||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||
.. [#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/>`_
|
||
|
||
.. raw:: html
|
||
|
||
<br>
|
||
|
||
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.
|