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

(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?).

2 Likes

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?

2 Likes

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.

5 Likes

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.

3 Likes

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.

3 Likes

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.

2 Likes

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.

2 Likes

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?

3 Likes

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

It is certainly true that the proposal (intentionally) avoids appointing the initial members of the proposed Third Party and thus requires some further community effort/involvement. For example, the Community Advisory Panel (assuming more open access within reason, and perhaps excluding individuals directly associated with the ECC and the ZF as the other governing bodies of the 2-of-3) could simply vote on the initial membership. Anyone with proven knowledge/history/involvement in Zcash could apply. That’s just an idea. I’m sure there are other ways to do it.

If additional time/effort required to figure out the Third Party is sufficient to reject the proposal, then it probably wasn’t the right proposal to begin with. As I mentioned above, this proposal is for anyone who thinks that it makes sense to not pre-allocate funding for any single organization, decentralize fund governance beyond the ECC and the ZF, and thereby attract more people to contribute to the success of Zcash.

Believe me, I know exactly what you mean :slight_smile:

That is certainly one criteria to consider, among others.

3 Likes

Yes, it could certainly evolve into a mix of weighted polls (miners, holders, forum users, Advisory Panel, exchanges, etc.). The ones that are easier to implement could probably be included from the start.

2 Likes

One possible argument in support of a 2-of-3 structure (with a “can’t vote for yourself” clause) involving ECC, ZF and a 5-member Third Entity (an elected “Community Council”) is that it avoids a complete and thus risky overhaul of the current governance mechanism (i.e. ECC and ZF would maintain key/majority positions) while creating an avenue (i.e. the Council) for experimentation with community involvement, coinholder voting, etc. This is very close to some recent proposals which essentially recommend either a 3-of-5 / 4-of-5 Council with guaranteed seats for ECC and ZF, or restructuring the already existing ZF board accordingly. The main difference is that it starts out with a 2-of-3 decision-making mechanism, creates a “sandbox” to more or less safely launch the 5-person Council, and allows for switching to 3-of-5 or 4-of-5 once the voting system/infrastructure is proven.

I’m not arguing for any particular option here but simply wanted to highlight this subtle difference :slight_smile:

3 Likes

If thats your ideas and problems for dev funds i will liquidate for a good reason i dont care i dont have a money or what else…much better to be poor and make nosess…i dont what to broke my peace of mind

I concur with your high-level sentiment, but would like to point out the obvious-but-essential: we still don’t know how to form such an elected Community Council and what it would look like.

Despite months of discussing this, I don’t think there’s any concrete proposal on the table for how such elections would be done. Intent and wishes aren’t enough; a concrete mechanism that can be analyzed and executed is needed for a proposal to be viable.

(I also have concerns about finding nominees, as discussed point 4 above, but that’s a separate issue.)

2 Likes

Yes, I think everybody understands this :slight_smile:

2 Likes