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

Granting veto power to a formalistic party like a lawyer would be a safeguard against clear and egregious misconduct. But such misconduct seems unlikely, and there’s always the hardfork option if it happens.

My concern is that a laywer would not be able to judge funding decisions on merit. If Party A says it needs all the Dev Fund reserves to pursue some crucial development or promotion activity, and provides a plausible reason with many serious-sounding blockchainy terms, it’s hard to see how a lawyer would veto it on formal grounds.

The same concern applies to other additional “entities”. If they are not deeply familiar with the Zcash ecosystem and technology, or can’t put in the time and effort to review things, then they may (in good faith!) accept funding proposals that are badly suboptimal in the grand scheme of things. And as discussed, because of the zero-sum game, the funded parties would be incentivized to submit convincing-but-suboptimal proposals.

5 Likes

I just want to add that even though I trust the ECC and the Foundation, I do not think it is a good idea to put them in a zero sum game with each other competing for funding. It seems that this is the basic nature of any multi-sig decision type proposal.

In addition, this proposal would entail significant time spend thinking about and discussing who gets how much funding, versus simply focusing all efforts on development work and knowing with certainty what the funding levels will be for the next 4 years.

My view is that this proposal is trying to minimize the trust that the community has to put in the Foundation and the ECC. Unfortunately I think that at some level we are going to have to trust that they will act in the best interest of the Zcash community with the funding they are given. This is true for any system where you are paying someone in advance to perform some service, and it is true to some extent in the investing world as well.

Obviously I am biased toward my own proposal, but I think the community should weigh the costs and benefits of a having a temporary governance system for a few years, versus accepting that we are trusting the ECC and Foundation on some level no matter what, and telling them to move as quickly as possible toward a long term decentralized funding solution.

4 Likes

Some of the incentive problems would be mitigated by changing the funding structure, to not be a single pool that both ECC and Zfnd compete for.

Instead, earmark the funds to the intended recipient (say 10%+10% as in @aristarchus’s 20% split between the ECC and the Foundation proposal). However, still subject the dispensing of funds to 2-out-of-3 approval. Any funds yet to be dispensed stay earmarked to the intended recipient for the 4 years until the 2024 halving, but are not irrevocably owned by them. A community decision process in 2024 may decide to reallocate remaining reserves.

The main advantage is that this avoids the zero-sum game and the urgency for each funded party to spend funds before the other takes them (the first incentive problem). It also reduces pressure to consume reserves (the third incentive problem), though does not eliminate it since reserves may eventually be allocated.

This also caps the damage if one of the funded parties goes rogue and somehow manages to receive its funds and then waste them. The other half of the Dev Fund would remain earmarked to the other funded party, so substantial work can still happen.

This also maintains the intended an oversight structure, allowing for enforcement of reporting requirements such as those suggested by @prestwich and in the Foundation’s guidance.

The main drawback, compared to the original proposal, is less flexibility. If one of the funded party puts all of its portion to good use, and the other one underutilizies its funds, it would require the consent of the latter to pass on more funds to the former. Also, this does not allow for direct funding of other entities; though indirect funding is still possible, e.g., via the Zcash Foundation’s Grant Program (using its own share of the Dev Fund).

4 Likes

Nice - solves several problems.

Funding for additional parties could be via equal deductions from Zfnd & ECC, might only require an agreement in place for that contingency.

1 Like

We will have to discuss this internally before making an assessment on whether such changes are feasible and/or appropriate in light of the original intent of the proposal. We will almost certainly submit the ZIP draft as is, but I suppose further changes, if any, can be hashed out before the end of October. For now, I can share some of my immediate reactions from a personal perspective.

I think one of the unique defining features of our proposal - at least in my mind - is that it explicitly does not earmark or guarantee funding for any single organization, thus allowing for maximal flexibility going into a fundamentally uncertain future. Of course, the three governing entities are in a privileged position relative to external applicants because they only have to secure one additional vote to get their request approved whereas everyone else need two. But all would have to apply and get approved. I suppose many would see this as decentralization enhancing, and perhaps even desirable despite the criticisms you’ve raised. But I may be wrong. It’ll definitely be very interesting to see how the miner, Community Advisory Panel, and possibly forum user voting plays out.

As with the discussion around collusion, I am a bit concerned about the assumption that both the ECC and the ZF would feel urgency to “spend funds before the other takes them”. If everything I’ve read and heard about the principles of both the ECC and the ZF is true, I would expect them to block any request that can arguably be shown as excessive or resulting in a highly inefficient use of funds (I admit there’s a lot of subjective judgement that goes into such assessments but if the process/discussion is public, it should be possible to at least approximately arrive at what most of the community thinks is reasonable).

Given that the ECC has explicitly provided an estimate of how much money it needs to do what it thinks is best for Zcash, I wouldn’t be surprised if that gets reflected in their first request, assuming that the proposal gets accepted unaltered in its fundamentals. Again, my hunch is that many would welcome a more or less level playing field (although not really due to the privilege mentioned above) as promoting decentralization and welcoming others to contribute to Zcash and also get rewarded, even if one voting entity is against it in particular instances, perhaps because they were hoping to secure more funds for themselves.

Just some immediate thoughts - these are not set in stone, are not necessarily reflective of Placeholder as a whole, and are definitely open for discussion :slight_smile:

6 Likes

I would echo what Eran said above about incentives. They have a powerful effect on people’s perceptions of reality. It’s unavoidable — that’s just human nature.

Also, what Josh wrote in June:

My concern is not that the Electric Coin Company does subvert Zcash to serve its own interests; my concern is that the ECC would be able to do so.

You could swap out “Electric Coin Company” for “Zcash Foundation” or any other entity (or special interest group) that has substantial influence over Zcash, now or in the future.

Zcash governance is more decentralized than it used to be, and I’m concerned about that trend reversing. I understand why commenters on this forum and other community members feel like they are disempowered relative to ECC and ZF. That’s just true!

Before anyone jumps on me: We shouldn’t shy away from acknowledging the problems that we’re working to solve. I am not saying that ECC and ZF want the balance of power to be how it is. Again, quoting Josh:

It’s up to the Zcash Foundation, with the help of the Zcash community, to be the second party in the multisig model of Zcash governance. In the future, we hope there will be more! Bolt Labs, or Parity Technologies, or other businesses, or other nonprofits, or collectives of users, could be involved. The multisig model of Zcash governance is 2-of-2 right now, but it doesn’t have to stay that way forever.

As long as the same entities that govern disbursement of funds are also recipients, the conflicts of interest are substantial. Those conflicts of interest are both at play right now, given ECC and ZF’s control of the ZIP process.

Re: “collectives of users,” I’d love to see someone step up and organize one.

Anyway, you’re right that draft ZIPs don’t have to be perfect, so we can all continue debating this in the coming months :slight_smile:

4 Likes

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?

3 Likes

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

3 Likes

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

4 Likes

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.

5 Likes

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

6 Likes

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.

3 Likes

(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