189 lines
9.1 KiB
ReStructuredText
189 lines
9.1 KiB
ReStructuredText
::
|
||
|
||
ZIP: 1007
|
||
Title: Enforce Development Fund Commitments with a Legal Charter
|
||
Owners: @lex-node (zcash forums)
|
||
@mistfpga (zcash forums) <steve@mistfpga.net>
|
||
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>
|
||
|
||
|
||
Terminology
|
||
===========
|
||
|
||
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
|
||
document are to be interpreted as described in RFC 2119. [#RFC2119]_
|
||
|
||
For clarity this ZIP defines these terms:
|
||
|
||
* Covenant is defined as a legally binding agreement, upon which a specific
|
||
aspect of development of the Zcash protocol and/or adoption is scheduled and
|
||
agreed.
|
||
|
||
|
||
Abstract
|
||
========
|
||
|
||
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.
|
||
|
||
|
||
Out of Scope for this Proposal
|
||
==============================
|
||
|
||
* This proposal does not address the merits, motivations or terms of any particular
|
||
Development Funding Proposal.
|
||
* Requirements and Implementation.
|
||
|
||
|
||
Motivation and Requirements
|
||
===========================
|
||
|
||
.. role:: editor-note
|
||
|
||
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 [#zip-1006]_ 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.
|
||
|
||
:editor-note:`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
|
||
[#zip-1006]_.
|
||
|
||
|
||
Rationale
|
||
=========
|
||
|
||
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.
|
||
|
||
|
||
Specification
|
||
=============
|
||
|
||
* If a Development Funding Proposal receives sufficient community support and
|
||
requires certain Covenants on the part of ECC or ZF, and there is also sufficient
|
||
community support for using this enforcement mechanism as applied to that proposal,
|
||
then one or more attorneys MUST be engaged to draft a Charter that reflects those
|
||
Covenants, and the Charter MUST become legally effective and binding at the same
|
||
time as the other aspects of the Development Funding Proposal are implemented
|
||
on-chain (e.g., at the same time as activation of the corresponding Network Upgrade,
|
||
if a Network Upgrade is is required to implement the Development Funding Proposal).
|
||
|
||
* Each pending Development Funding Proposal SHOULD be amended to specifically
|
||
describe any Covenants that the ECC, ZF or any other relevant person or entity
|
||
would be required to agree to as part of such Development Funding Proposal.
|
||
|
||
|
||
Open Issues
|
||
===========
|
||
|
||
* Whether a plurality, majority or supermajority of ZEC are required to approve an
|
||
enforcement action against ECC or ZF;
|
||
* Logistics and technical implementation regarding the Charter, such as on-chain
|
||
signalling/voting for enforcement;
|
||
* Remedies under the Charter, such as “specific performance” (getting a court to
|
||
order ZF or ECC to comply with a Covenant);
|
||
* Discontinuation or reduction of development funding (which MAY occur by having
|
||
Covenants that the ZF or ECC will prepare a Network Upgrade that discontinues or
|
||
reduces development funding if so requested by holders of the requisite plurality,
|
||
majority or supermajority of ZEC), etc.
|
||
|
||
|
||
Raised Concerns
|
||
===============
|
||
|
||
* “Code is Law; This is Just Law!”
|
||
|
||
- Objection: Relying on off-chain legal mechanisms is contrary to the cypherpunk
|
||
ethos and/or the mission/ethos of Zcash.
|
||
- Answer: This is a values judgment that some people may reasonably hold. However,
|
||
one should also consider that “don’t trust, verify” is also a cypherpunk
|
||
principle and that the off-chain nature of some requirements means that a
|
||
code-based solution is currently not possible; therefore, a legal enforcement
|
||
mechanism, while imperfect, may be preferable to no enforcement mechanism.
|
||
|
||
* “Social Coordination Impracticality/Risk”
|
||
|
||
- Objection: ZEC holders prize anonymity, but legal enforcement of breached
|
||
Covenants will require social coordination (people must agree to enforce the
|
||
action, and someone must actually get a lawyer and go to court). Therefore, this
|
||
mechanism will not be valuable to ZEC holders and could lead them to compromise
|
||
their anonymity and thus be worse than useless.
|
||
- Answer: The community should further discuss how, in practice, ZEC holders might
|
||
securely coordinate to bring an enforcement action against ECC and the ZF if it
|
||
were needed. Additionally, it should be considered that the mere possibility of
|
||
legal enforcement due to the clear terms of a Charter may dissuade ECC and ZF
|
||
from violating Covenants and thus, paradoxically, having a Charter may also mean
|
||
that no legal action ever becomes necessary. Additionally, the “class action”
|
||
legal structure in some jurisdictions may mean that the ZEC holders' community
|
||
could find a ‘champion’ in the form of a class-action attorney, without ZEC
|
||
holders being required to personally become involved or ‘out themselves’ as
|
||
ZEC holders (other than one willing ZEC holder as class representative).
|
||
|
||
* “This Will Just Waste Funding On Lawyers”
|
||
|
||
- Objection: This Charter will be novel and bespoke, and lawyers may charge high
|
||
fees to draft it and give assurances that it is enforceable. This wastes money
|
||
that otherwise could be spent on Zcash development.
|
||
- Answer: This is a valid concern. The Zcash community may be able to crowdsource
|
||
an initial rough draft of the Charter from lawyers in the community or even
|
||
non-lawyers who may be willing to do research and make an attempt at an initial
|
||
draft. Lawyers could be involved primarily to issue-spot and formalize the
|
||
initial draft. ECC and ZF may have law firms on retainer that could perform the
|
||
work at favorable rates. Lawyers may be willing to work at discounted rates due
|
||
to the unique opportunity and prestige of developing this innovative blockchain
|
||
governance mechanism. Additionally, any legal fees may be small as a percentage
|
||
of the overall value at stake, which may be considerable if a 5-20% development
|
||
funding block reward is authorized.
|
||
|
||
|
||
References
|
||
==========
|
||
|
||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||
.. [#zip-1006] `ZIP 1006: Development Fund of 10% to a 2-of-3 Multisig with Community-Involved Third Entity <zip-1006.rst>`_
|