Dev Fund Proposal: 20% to a 2-of-3 multisig with community-involved governance

How do the dynamics change if there is a 2-3 but a receiving entity must abstain in voting and a deadlock results in no action?


Hence my suggestion upthread :smiley: Dev Fund Proposal: 20% to a 2-of-3 multisig with community-involved governance


Incentives are important, no doubt. But so are values, principles, and whatever rules of governance and accountability are put in place. People are certainly incentivized by money - some more, some less - but they also care about other things, especially in this context. At least that’s what I’m reading/hearing.

I think your suggestion upthread on 4-of-5 is worth considering, even though it would increase the administrative burden in the system. If this is what the majority thinks makes sense, it could be made part of the Development Fund governance road map and rolled out in stages.

I’m not sure why it never occurred to me as an option. I would be interested to hear what others think about this: 2-of-3 for all external funding requests, and 2-of-2 (which is essentially equivalent to 3-of-3) for the ECC, the ZF, and the Third Entity themselves. This could be the starting point in October 2020, and the system could subsequently evolve into a 3-of-4 or 4-of-5, if the majority prefers further decentralization and community involvement (assuming also that these additional entities are willing to spend time reviewing proposals without getting paid to do so).


The more times I read this proposal the more I like it.

The part that interests me most is how multisig+governance makes it adaptive, especially given the ZEC/FIAT rate which is completely unpredictable.

For example, lets pretend that the price goes up (x10, x100, bat-country-crazy)

  • entities would have a huge surplus of funding as their costs are FIAT based

The governance function could decide what to do with the excess. Should it just keep going directly to the entities or be reduced to match their FIAT costs? Should it fund more things, bigger NUs, accelerated development? Should zcash stick to the plan & build a strategic reserve to fund the next 20 years?

Now lets pretend the price tanks ($15, something painful)

  • ECCs runway disappears & they pivot to make payroll
  • NUs slow/shrink/stall
  • ZFnd scales back to survival mode

If ECC pivots & leaves the governance function could redirect all to ZFnd to ensure its survival. NUs get smaller, development slows to fit budget constraints, but the project continues.

Now lets pretend both things happen - the price tanks, the project limps along in survival mode for years and then the price goes bat-crazy-nuts. The governance function could then react to expand development, ECC may want to pivot back from whatever they were doing, maybe some other entities want to join or take over their role.

I think this ability to react to change is important - how that fits with the zero-sum-game issue or the management/control of funds is also important but I’m sure a solution can be found for that.


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

Overall this is close to a good state for becoming a ZIP draft.

As-written, this all looks like content for the Motivation section. The Rationale section is for explaining why particular decisions were made in the Specification, and should therefore reference specific parts of the Specification in-line (and thus makes sense to be below the Specification). In some existing ZIPs, the Rationale is interspersed within the Specification, which is also acceptable.

Should be “Specification”.

The current FR mechanism, and the currently-shelved ZIP 207, both periodically rotate recipient addresses for operational security purposes (allowing future keys to be kept offline until they are needed). We recommend that the ZIP not prevent this by mandating a single address.

This does not specify the default behaviour from the second halving, which would need to be implemented. (“MAY” indicates an entirely optional choice, and should not be used in a consensus rule unless you really mean that there is no consequence to the rest of the network regarding which option is chosen.)

“MUST” should probably be “SHOULD”, as it is specifying something they have a strong incentive to do anyway, and it is something that the protocol cannot enforce.

The mechanism for shared control of the address(es) needs to be specified in the earlier Funding section (i.e. is this a 2-of-3 transparent multisig address?)

The recipient addresses need to be known at the latest by the time the mainnet activation height is set. If this was a 2-of-3 multisig address (which per above is not specified), then if the Third Entity is not established before the mainnet activation height is set (which this provision allows), some other entity would need to hold their private keys in escrow.

The referenced document about the mission and values of the ZF are just those of the ZF, and has had no input on content, wording etc. from ECC or the general community. It doesn’t seem appropriate to include it as a normative reference within the ZIP.

There should also be a “Security Considerations” section that summarises the discussion down-thread around the trade-offs between 2-of-3 governance vs 2-of-2, 3-of-3, etc.


Thank you for these comments/recommendations! We will try and integrate the ones concerning format before August 31. Everything else will remain up for discussion and can ideally be sorted out moving forward.


(Still speaking for myself, not as ZIP editor.)

That still allows a single party to block any particular [funding] proposal, which to me is the main problem with 2-of-3. For protocol decisions, a built-in bias toward sticking with the status quo in case of disagreement is somewhat reasonable. For medium and long-term funding decisions, I don’t think it is.

1 Like

@daira The only alternatives that come to mind are (1) grant some entity unilateral power to make funding decisions (off the table?) and (2) increase the voter set so that each individual vote carries less weight (requires identifying and empowering additional parties, more coordination, etc.; feasible longer term?).


This may have already been asked and might be nitpicking but why specify transparent address here, as doesn’t this limit us deprecating t-addrs until post-2024? Or add a MAY to add this address may later transition to a shielded address once a suitable replacement is available?


Aye, this is an essential question. My analysis, and as far as I can tell the proposal’s original intent, was that funded parties who are among the 3 entities in the “2-out-of-3” multisig will participate in voting on their own proposal, and thus require just one more vote.

However, ECC Initial Assessment of Community Proposals asserts that

members of the panel should be required to recuse themselves from any decision in which they are also a potential recipient of funds

Under that, ECC and Zfnd proposals would effectively be subject to 2-out-of-2 rather than 2-out-of-3.

Moreover, it would decouple the technical aspect of locking funds under a multi-signature, from the intent. Technically, a rogue party holding one of the 3 keys can decide to use it to fund itself (with cooperation of just 1 more party), regardless of whether it’s supposed to recuse itself according to a social contract. Done blatantly, it would be the kind of egregious violation that may cause a hardfork. But there could be marginal cases, e.g., a party refusing to recuse itself from voting on funding someone who’s affiliated with them.

So under the latter interpretation, the crisp meaning of multisig becomes fuzzy and potentially contentious.

In any case, the proposal should explicitly say whether and when parties are supposed to recuse themselves or be excluded from funding decisions.

1 Like

Good question. The original reason for a “transparent address” was, well - transparency. It has been mentioned above that, for security reasons, a set of changing transparent addresses should be used instead which is what the latest version of the proposal prescribes. What are the implications for transparency if only shielded addresses are used?

Very important considerations indeed. One option is to require three signatures for all transfers but this comes with its own, possibly more serious problems. Here we’re only considering situations where the governing entities act against the rules of governance, right? How does the situation change under a “legal charter”?

Currently it is only possible to send to transparent addresses in coinbase, but from NU3 shielded addresses will be supported as a result of ZIP 213: Shielded Coinbase. I specifically designed it so that coinbase outputs to shielded addresses are forced to reveal the address and amount, so that the consensus rules can enforce rules on those outputs. This means that any of the dev-fund ZIPs could have their outputs go directly to shielded addresses (instead of to a t-addr and then shielded right afterwards), and if multisig shielded addresses are available before the addresses have to be committed, then it would be possible to use multisig shielded addresses.


Right, I think there are a few different issues such as the technicality of actually sending coinbase funds to a shielded address (as described above) but also in the transparency of movement of funds? I imagine the latter could be achieved through view keys (again not implemented already)?

I guess my point is can this statement be generalised in a way that doesn’t restrict funds being paid to a transparent address but rather a 2-3 multisig address with visibility into the movement of funds? Maybe this doesn’t actually matter but I live in the (diminishing) hope that t-addrs will be gone by 2024 and so removing any/all blockers is a positive thing.


Click here for the most up to date version of this proposal on Github. The original post will be kept unchanged for comparison but Github will always have the official latest version of this proposal.


Just reading the proposal on gift hub, it might be a good idea to make short points in this forum topic as well so everybody can see what changed, was added or removed on 1 view without having to decrypt the github ZIP. Just a suggestion how it could be more comfortable for the average joe.

Just some clarifying questions if you don’t mind (quoted text taken from your github proposal):

in particular the creation of a Third Entity (composed of Zcash stakeholders external to the ECC and the ZF)

Does this mean the 3rd entity will contain only Zcash stakeholders? What’s the definition for “eligable” stakeholders? And does this mean that for example miners, independed devs, community members are not eligable to be part of a 3rd entity?

To ensure that funding for both technical and non-technical work on Zcash stays sufficiently independent from external entities (investors, donors, private companies, etc.) who could end up acquiring a disproportionately large influence over the network and its development, or jeopardize the sustainability of funding necessary for the success and stability of Zcash.

Wouldn’t exactly the creating of the 3rd entity with Zcash stakeholders lead to dependence of investors and private companies? This question is based on the assumption that Zcash stakeholder as described bevor are to be in charge in the 3rd entity.

The current version on Github has no substantial changes relative to the one on the forum. Formatting has changed a little, short Rationale and Security Considerations sections have been added, as well as a note on the trademark issue to the Out of Scope section. I will make sure to highlight any important changes as they are introduced from here on.

Zcash stakeholders in the broadest possible sense. I don’t see why members couldn’t include independent Zcash developers, miners, investors, or long-time and/or active community members.

The proposal does not define who can or can’t be part of the third governing entity. The initial composition of the Third Entity would be decided through a process similar to the current one regarding the dev fund.

Yes, all three governing entities would have some meaningful control over funding decisions, including the proposed Third Party.


Thank you. I hope you don’t mind if I copy the format.

I really should get mine in asap. will do it today.

Thanks again.


This feels very much like kicking the can down the road. It may not be ideal to go through all the trouble and strife just to reach the decision that we need to make another big decision by another unspecified community process right away, and this time a possibly even more contentious one involving specific named parties and their personal interests.

I feel that there is a finite amount of energy and attention that we, the community, can allocate to governance (at the expense of actual development, education, research, building businesses and other important things).

An important criterion for evaluating proposals is: to what extent does this conclude the drama and lets people go back to work?


How about if the ‘third entity’ was a process rather than yet another org/group?

I posted some thoughts here, building on the current efforts to survey the ecosystem & involve the community.

1 Like