Dev Fund Supplemental Proposal: enforce devfund commitments with legal charter

I posted some ideas on the 2-3 multisig thread on how to handle under/over funding from wild zecfiat changes.

Might be relevant to the ‘Dev Charter’ thinking?

Edit: Unbungled the English.

1 Like

I’m getting the answer for you :slight_smile:

1 Like

PM’d you about the czip stuff…

1 Like

@daira and I made an initial review pass over this PreZIP. This is not a formal part of the proposal process (in particular, @daira is not acting in hir role as ZIP editor); this is just a joint comment between @daira and myself on the current state of the PreZIP. Neither of us are lawyers, and nothing below is legal advice.

The content in this section should be in the Motivation. The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.

This should cover SHOULD and SHOULD NOT as well, but that would become rather verbose. How about:

“This proposal is supplemental to any Development Fund Proposal which places or purports to place conditions on how the Electric Coin Company (ECC) and the Zcash Foundation use development funds or take other related off-chain actions […].”

If Covenants is intended to have a specific meaning, it should be defined in the Terminology section.

Is this legally achievable if some ZEC holders are not publicly identifiable?

It is extremely unlikely that a majority of ZEC would vote on anything. See basically all production implementations of on-chain voting systems.

It is not clear how this would be enforced technically. The contract could require that these parties agree not to use their ZEC in any such vote, but as currently written this implies there is a way to enforce it.

This also does not cover all possible parties; some of the proposed dev-fund ZIPs allow more than just the ZF and ECC to apply for funds, or be involved in governance (for example, the “Third Entity”). It should be clear whether the intent of this proposal is to solely cover the ZF and ECC.

This should just be Rationale.

This should be Specification.

The second part cannot be stronger (using MUST) than the first part (using SHOULD); if no attorneys are engaged to draft a Charter, then there is no Charter to come into effect. If the intent is that a Charter only comes into effect if it is drafted (i.e. the ZIP allows for no Charter to be drafted), this should be made clear.


This isn’t paradoxical, it’s how law works (to the extent that it works) in general.


Thanks for the feedback. I am not part of the ZCash community and wrote this up at the suggestion of Zooko when he saw my thoughts on twitter.

I won’t be able to spend a lot of time to respond to this feedback, particularly not by Aug 31st. If someone else would like to make revisions I’d be happy to review a revised version or answer questions.


I have spoken with @lex-node via PM and will try to get this into a state where it can at least get put forward for the 31st.

and making adjustments as recommended by str4d and daira.

I will be changing the format a bit and condensing current objections and concerns into a section so they highlighted.

To be fair I think I get what this proposal is trying to do but I will be checking my drafts with lex-node too.

(I don’t know if this makes me temporary champion or not, but I will probably have to start a new thread if lex cannot make the updates. the thread will reference this and be handed back to lex when they have more time to engage with the proposal.)




Just keep it in this thread, there’s no reason to have another one. You can post updated versions as links or just as very long comments, either is fine.

1 Like

@mistfpga here ya go! via


That should more than enough time to get all this worked out. great news. I would suggest adding it to the High Signal, Low Noise thread in the OP as an image and also refrence it in the Megathread.

It is what I was hoping you would say. “We cant take something out of left field, but yes we are still flexible.” it seems inline with the extension and dev funding sentiment overall. (and what nathan posted in the emergency extension thing. )

I have a few of my proposals that might slip beyond the 31st deadline but not by much - this is due to helping others with theirs. I can not worry about mine so much now and pay a little more attention to the others. :slight_smile:

Thank you. Daira and Sonya. (sorry for asking you all the questions sonya, it just feels a better use of other peoples time if you collate then ask - which is why I haven’t @'d Daira or Str4d)


I have reached out to lex-node via email so I expect all these issues to be resolved before the pull request, if not, I will readjust to make more flexible when the community votes on it so the can vote on aspects like percentages, etc.

@daira @str4d I would really appreciate your help with looking over this, If you can spare some time to look over any of my proposals please make it this one.

what more needs to be done? I have taken some liberties with definitions and moving to a quorum based approach to address concerns about voting turnout. I know it still needs a bit of work before I can make it a pull request, but could you please cast a quick eye over it. It is a proposal I have written for someone else.

This is missing a requirements section or am I blind? tbh I have read this proposal so many times the words don’t mean anything anymore. - I just noticed that they are in out of scope. can requirements be out of scope?

Caveat this was written up by @mistfpga, whist there is/was some controversy around 2-2, the trademark and signoff - this proposal should not be stopped by those, @lex-node has expressed strong desire to continue with this, he just did not have the time to write it up. It will be adapted to fit whatever format happens to be going forward. I have also take some liberty when addressing str4d and daira’s comments. This is in an effort to keep the zip alive and in the right spirit @acityinohio you have a proposal based of this one, is this how you read it too?

I will make it better in github.

1 - Header

ZIP: unassigned
Title: Enforce DevFund Commitments with a Legal Charter
Owner: @lex-node (zcash forums)
Current Advocate: @mistfpga (zcash forums)
ZIP Status: Draft
Community Status: proposal:@ Dev Fund Supplemental Proposal: enforce devfund commitments with legal charter
Category: Process
Created: 2019-08-24
License: CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike 4.0) [3]

2 - Terminology

To understand this ZIP it is critical that people understand the right terminology so their requirements can be quickly checked.


Have special meaning and people should familiarise themselves with it. -

For clarity in this zip I define these terms:

  • Spirit is defined as what is the intended outcome of the zip.[2]
  • 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 upon. (I have no idea, mistfpga, added to the below bit.)

These terms still need to be qualified.

  • Covenant needs to be explicitly defined by lex-node. I think i have the gist - mistfpga

3 - Out of Scope for this proposal:

  • This proposal does not address the merits, motivations or terms of any particular development funding proposal.
  • Requirements & Implementation
  • The current trademark and sign off issues that just popped up.

4 - Abstract

Supplemental proposal to ensure feature selection and work is community driven. (maybe, idk.)

5 - Motivation

This proposal is supplemental to any Development Fund Proposal which places or purports to place conditions on how the Electric Coin Company (ECC) and the Zcash Foundation use development funds or take other related off-chain actions (such requirements, Covenants).

For example, the proposal 20% to a 2-of-3 multisig with community-involved governance 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 hardfork, 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 which would entitle ZCash (ZEC) holders to enforce ECC’s/ZF’s performance of any Covenants. For 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 quorum of yet to be decided number of representatives from a number specified groups from which 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% super majority. (mistfpga numbers)

It is assumed that the ECC, Foundation or party with a direct conflict of interest WILL 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 the 20% to a 2-of-3 multisig with community-involved governance proposal referenced above.

6 - 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.

7 - Specification

The following is a high-level summary of requirements and implementation of the proposal:

  • If a development funding proposal receives sufficient community support and requires certain Covenants on the part of ECC or ZF, then one or more attorneys MUST be engaged to draft a Charter that reflects those Covenants, and the Charter MUST become legally effective & 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 a hardfork, if a hardfork 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.


Because @lex-node is currently unavailable but will be I have put yet to be addressed concerns here. and addressed them as best I can.

Here is a precompile list:

  • “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).

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

Further discussion and decision from the community is needed on, but is not limited to: (this does not really need lex-nodes input but it would be nice)

  • 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 hard-fork that discontinues or reduces development funding if so requested by holders of the requisite plurality, majority or supermajority of ZEC), etc.
  • is this design by committee? (added by mistfpga)

Technical implementation.

  • help?

Associated zips


[1] - <-I like this one best, dont know which the ECC prefers.(mistfpga)

1 Like

Great job on this. Would “technical implementation” include legal documents or does it refer to code only?

Are there any good mechanisms on ZCash for on-chain voting by ZEC holders?


I will take that as you are sufficiently happy with my edits, you still have the power to edit it tho.

I will convert it into a pull request and email it to you, check your spam, my domain was a bit wonky until recently (silent upgrade by one of my mail hosts) so a lot of spam has been coming from my email address for the past 3 or 4 months. heh.

Then I guess you can take it from the pull request? changing the super majority, etc if you see fit.

no idea. sorry. to be fair I am not 100% sure it needs one, it is more of a mechanism idk I cant assess what would need to be changed to implement it. the ECC said they would give a second round of feedback at somepoint and I imagine some others will once it goes into GitHub.

1 Like

We’re discussing an on-chain staked poll in this thread: Staked Poll on Zcash Dev Fund Debate

Pull request done

1 Like