ZIP: 1007 Title: Enforce Development Fund Commitments with a Legal Charter Owners: @lex-node (zcash forums) @mistfpga (zcash forums) <firstname.lastname@example.org> Status: Obsolete Category: Concensus Process Created: 2019-08-24 License: CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0/> Discussions-To: <https://forum.zcashcommunity.com/t/dev-fund-supplemental-proposal-enforce-devfund-commitments-with-legal-charter/34709>
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
For clarity this ZIP defines these terms:
A supplemental proposal to ensure feature selection and work is community-driven.
Hopefully it will be compatible with a number of other ZIPs and can be worked into them.
This proposal is supplemental to any Development Funding Proposal that places or purports to place conditions on how the Electric Coin Company (ECC) and the Zcash Foundation (ZF) use development funds, or take other related off-chain actions such as requirements and Covenants.
For example, the proposal 2 provides that “[f]unds accruing to the Zcash Development Fund MUST be used only for ... technical work directly connected to the various software implementations of the Zcash protocol.” However, once development funding is approved and implemented via a Network Upgrade, there will be no enforcement mechanism to ensure that the ZF and ECC abide by this requirement.
This proposal aims to provide such an enforcement mechanism. If this proposal is adopted, then the ECC and/or ZF, as applicable MUST enter into a legal agreement that would entitle ZEC holders to enforce ECC’s/ZF’s performance of any Covenants. For the purposes of this proposal we will refer to the legal agreement as the “DevFund Charter” or “Charter” for short, but it MAY also be styled in other ways – e.g. as a Constitution, Bylaws, Fund Governance Agreement, etc.
The DevFund Charter SHOULD be used to the benefit of all ZEC users, but the DevFund Charter MAY provide that an enforcement action requires the support of the holders of a plurality, majority or supermajority of ZEC. ZEC held by the ZF, ECC and their officers, directors, employees and/or affiliates SHOULD be excluded from the denominator in calculating the requisite plurality, majority or supermajority of ZEC.
a "plurality" in a vote means the option that received more votes than any other single option, but it is unclear how this applies to "a plurality of ZEC". Taking into account experience from stake-weighted voting in other cryptocurrencies, the threshold of a simple majority (50%), or more, of all *issued* ZEC voting for any enforcement action would seem to be an extremely high bar.
A quorum of yet-to-be-decided number of representatives from a number of groups specified by the DevFund Charter MAY provide that an enforcement action requires the support of the assigned representatives of each. One such mechanism SHOULD be ZEC balance, however this would require a 66% majority or a 85% supermajority. (These numbers are not binding and are up for discussion)
It is assumed that the Electric Coin Company, Zcash Foundation, or party with a direct conflict of interest SHOULD identify their vote/signal - which MAY be rejected from the vote.
Legal enforcement MAY occur in a court of law, non-binding mediation or binding arbitration. The DevFund Charter MAY also provide rights to other Zcash community constituencies, such as specified miners or the “Third Entity” contemplated by 2.
Because ZEC holders do not have specific legal rights against the ECC or ZF, but MAY wish to condition renewed on-chain development funding on the ECC’s or ZF’s agreement to use the development funds in certain ways, ZEC holders should have the legal right to enforce ECC’s/ZF’s compliance with those agreements.
|1||RFC 2119: Key words for use in RFCs to Indicate Requirement Levels|
|2||ZIP 1006: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity|