Add draft governance ZIPs #989

daira · 2025-03-04T04:40:21Z

No description provided.

nuttycom

Reviewed draft-ecc-community-and-coinholder.md

nuttycom · 2025-03-19T14:20:58Z

zips/draft-ecc-community-and-coinholder.md

+* There is a well-defined, publically agreed, process for evaluation and community feedback on grant proposals.
+* Funds are held in a multisig resistant to compromise of some of the parties' keys, up to a given threshold.
+* No single party's non-cooperation or loss of keys is able to cause any Protocol-defined Ecosystem Funding to be locked up unrecoverably.
+* During the period of this proposal, the block rewards must be distributed as described in the [Abstract] above.


The word "distributed" in this sentence seems overloaded to me. Does this refer to the 8%/12% split, or the sentence that follows (which doesn't provide enough clarity to qualify as a requirement)?

zips/draft-ecc-community-and-coinholder.md

nuttycom

Review complete. Addressing the question of how to handle competing proposals in particular is blocking.

zips/draft-ecc-zbloc.md

nuttycom · 2025-03-19T16:16:15Z

zips/draft-ecc-zbloc.md

+* No single party's non-cooperation or loss of keys is able to cause any Protocol-defined Ecosystem Funding to be locked up unrecoverably.
+* 80% of the block rewards are given to miners, and 20% to a Zcash Community Fund seeded from the Deferred Dev Fund Lockbox.
+* The funds from the 20% funding stream will be usable immediately.
+* The funds in the Deferred Dev Fund Lockbox will be usable once a mechanism is available for disbursing them.


Should the disbursement mechanism options be factored out into a separate ZIP that both the governance ZIPs refer to? In both proposals, the model is effectively "grant-based funding, where development funds are controlled by a multisig" with different options for how and when funds may be disbursed to grantees.

Will someone take responsibility to draft this?

@nuttycom agreed to do this.

nuttycom · 2025-03-19T16:17:21Z

zips/draft-ecc-zbloc.md

+
+Any changes to the ZCG or its governance, such as its expansion to include more members, may be desired but are specifically outside this proposal’s scope.
+
+The full implementation of this proposal would require the design and implementation of a lockbox distribution mechanism, likely using multisig. This mechanism would be similar to that needed for an alternative proposal, the Community and Coin-holder Funding Model [^draft-ecc-community-and-coinholder]. However, this proposal does not require that a lockbox distribution mechanism be implemented at the same time as a change to the funding stream.


This gets to my comment above: any of the ecc-community-and-coinholder options would work for this proposal as well.

nuttycom · 2025-03-19T16:25:02Z

zips/draft-ecc-zbloc.md

+
+Each Constituency initially receives three Voting Units. This MAY be changed by a Governance Proposal.
+
+Constituencies other than the Coin-holder Constituency above are called Organizational Constituencies. The Organizational Constituencies will together elect a representative responsible for establishing a clear process and mechanism for gathering coin-holder sentiment, which will then be used as the decision-making process of the Coin-holder Constituency.


One possibility that this doesn't take into account is that an organic coin-holder constituency may choose to self-organize; the way that this is worded makes it sounds like the Organization Constituencies will choose the decision-making process instead of just the mechanism for determining coin-holder sentiment.

Suggested change

Constituencies other than the Coin-holder Constituency above are called Organizational Constituencies. The Organizational Constituencies will together elect a representative responsible for establishing a clear process and mechanism for gathering coin-holder sentiment, which will then be used as the decision-making process of the Coin-holder Constituency.

Constituencies other than the Coin-holder Constituency above are called Organizational Constituencies. The Organizational Constituencies will together elect a representative responsible for establishing a clear process and mechanism for gathering coin-holder sentiment, which will then be used to determine the will of the Coin-holder Constituency.

nuttycom · 2025-03-19T16:30:33Z

zips/draft-ecc-zbloc.md

+
+### Approval Thresholds
+
+The Approval Threshold is the absolute majority, as a proportion of the total number of Eligible Voting Units, required for a Proposal to be Approved. As stated earlier, Eligible Voting Units do not include those of Constituencies that have a conflict of interest for this Proposal. However, they do include the Voting Units of Constituencies that have no conflict of interest but choose to abstain.


We need something better than this: we need a system that makes it easy to choose between multiple possible alternatives. For example, consider the situation wherein ECC, ZF, Shielded Labs, and the Zingoistas all submit grant proposals for the same work; in this circumstance, is the grantee selected by determining which of the competing proposals has the highest number of approvals? What happens in the case of ties?

In addition, timing constraints based upon when a grant proposal is made can introduce problems - for example, if a vote is scheduled for a grant, and then a few days before the vote a competing proposal is introduced, what happens? If a competing, but better proposal is introduced after the grant has been approved, what happens?

This comment also applies to the coinholder-and-community ZIP.

Note that if additional proposals are made beyond these first two, we're already having to face this problem. It will be very common - it will probably arise for literally every proposal.

It would be approved when the signing threshold is reached. At that point, it becomes a commitment that would only be overturned if a new threshold signals that it should be.

@jswihart the problem that I'm pointing out is that if there are multiple competing proposals, voting on each one individually doesn't work because you might end up in a situation where both grants are approved, but the community only wants to spend money on one of them and there's no way to signal a preference between them using the currently-described voting mechanism.

I was originally thinking that negotiation about alternatives could be done off-chain, and then the on-chain vote would just be a ratification. If we want to put more of the sausage-making on-chain then we can, but I'm not sure that is a good idea, because choosing between multiple alternatives fundamentally requires a more complicated voting mechanism.

nuttycom · 2025-03-19T16:38:51Z

zips/draft-ecc-zbloc.md

+
+By default, a Governance Proposal requires a three-fifths Approval Threshold, and MUST have a Deadline at least two weeks from when the Proposal is published on-chain.
+
+All Consituencies MUST be consulted in order to determine whether they consider a draft Proposal to be "controversial", before it published on-chain. If *any* Constituency decides that a Proposal should be treated as controversial, it is then subject to a higher Approval Threshold of three quarters, and a Deadline at least four weeks from when the Proposal is published on-chain. (In the case of the Coin-holder constituency, a coin-holder vote is not necessarily required to establish this; it is likely sufficient to decide based on forum discussions for example.)


This strikes me as a can of worms. This means that an initial coinholder vote must be held to determine whether a proposal is "controversial" for every proposal.

I see your point. The intent was that a coinholder vote would only need to be done to confirm that a proposal is "controversial" if there is substantial disagreement (among groups of people who plausibly claim to collectively have significant holdings) about whether it is. But also, I consider treating a proposal as controversial whenever there is a dispute as basically harmless. If there is a dispute over whether it's controversial, then it's controversial!

Think of it this way: we could just as well have set the thresholds so that every Governance Proposal is controversial, and that would be fine. Non-controversial proposals are just an optimization so that things that no-one actually disagrees about can be waved through more easily. For that to be the case, it has to be easy to cause any given proposal to be treated as controversial. (Yes that means people can be annoying by forcing proposals to take longer than they needed to have done, but so what? They effectively can do that anyway under any realistic governance process.)

nuttycom · 2025-03-19T16:43:03Z

zips/draft-ecc-zbloc.md

+In the case of Governance Proposals that affect consensus, final ratification occurs when node operators adopt the software implementing the changes.
+
+Note: Nothing forces developers of Zcash consensus node software to follow this specification. The aim of a process specification like this one is only to establish a social consensus. It fundamentally cannot affect the autonomy of developers of Zcash consensus node software to publish (or not) the software they want to publish, or the autonomy of node operators to run (or not) the software they want to run.


These facts are also true for the community-and-coinholder proposal (or, indeed, any proposal.) They should be copied there.

True, but community-and-coinholder is only attempting to handle funding proposals, and so it's obvious in that case that it's not making any demands of node developers (beyond the mechanism it requires for its own operation).

nuttycom · 2025-03-19T16:45:13Z

zips/draft-ecc-zbloc.md

+* Substantive changes to the ZIP Process defined in ZIP 0 [^zip-0000].
+* Substantive changes to this ZIP defining the zBloc.
+* Changes to the set of zBloc Constituencies and/or the distribution of Voting Units among those Constituencies.
+* Changes to the policy a Constituency uses for its decision-making.


This last one should only apply to the coinholder constituency; it should not require a Governance Proposal for ECC to change its internal decision-making mechanism.

Oh, I misinterpreted Josh's intent here then (given his thumbs-up).

nuttycom · 2025-03-19T16:47:30Z

zips/draft-ecc-zbloc.md

+
+### Exceptional decisions to remediate security vulnerabilities
+
+The governance processes specified in this ZIP are not intended to prevent consensus node implementors from making consensus changes that they reasonably believe are critical to maintain the security of the Zcash Mainnet network and/or Zcash users. Such changes might need to be developed and released according to a controlled disclosure process that precludes public voting.


This is also useful to copy to the community-and-coinholder proposal, or to factor out into a shared preamble.

Again, community-and-coinholder only handles grants, not any other aspect of governance.

nuttycom · 2025-03-19T16:52:16Z

zips/draft-ecc-zbloc.md

+A funding stream will be established for a Zcash Community Fund, consisting of 20% of the block subsidy paid to a 2-of-3 P2SH multisig with keys held by the Financial Privacy Foundation, the Zcash Foundation and the Electric Coin Company ("Key-holder Organisations").
+
+This funding stream will start immediately on activation of this ZIP, which is assumed to be after the expiry of the existing ``FS_FPF_ZCG`` and ``FS_DEFERRED`` funding streams. It is proposed to be continued until modified by a future network upgrade.


Raising again that I don't like the funding mechanism to be coupled to the governance mechanism. Also, is the FPF intended to be included here?

What is the rationale behind the keyholders being different from the constituencies? I can see where the coinholder vote would need its disbursement power to be split among the other constituencies, but otherwise it's not obvious why we should have separate keyholders. Add a rationale if this is actually the chosen design.

rendered/draft-ecc-community-and-coinholder.html

zips/draft-ecc-onchain-accountable-voting.md

Signed-off-by: Daira-Emma Hopwood <[email protected]>

@nuttycom

@nuttycom and Josh. Signed-off-by: Daira-Emma Hopwood <[email protected]>

Signed-off-by: Daira-Emma Hopwood <[email protected]>

Co-authored-by: Josh Swihart <[email protected]> Co-authored-by: Kris Nuttycombe <[email protected]> Signed-off-by: Daira-Emma Hopwood <[email protected]>

daira force-pushed the ecc-governance-drafts branch 2 times, most recently from d0a647d to 3886615 Compare March 4, 2025 05:04

daira force-pushed the ecc-governance-drafts branch from 3886615 to 29fe2db Compare March 18, 2025 19:46

nuttycom requested changes Mar 19, 2025

View reviewed changes

jswihart reviewed Mar 20, 2025

View reviewed changes

zips/draft-ecc-onchain-accountable-voting.md Outdated Show resolved Hide resolved

zcash deleted a comment from jswihart Mar 20, 2025

daira and others added 4 commits March 20, 2025 22:01

Add draft governance ZIPs.

d7da636

Signed-off-by: Daira-Emma Hopwood <[email protected]>

Updates to draft-ecc-community-and-coinholder based on feedback from

1d8ea80

@nuttycom and Josh. Signed-off-by: Daira-Emma Hopwood <[email protected]>

Updates based on @str4d and @nuttycom's comments.

0e99c12

Signed-off-by: Daira-Emma Hopwood <[email protected]>

Address some comments from @jswihart's review.

b88a415

Co-authored-by: Josh Swihart <[email protected]> Co-authored-by: Kris Nuttycombe <[email protected]> Signed-off-by: Daira-Emma Hopwood <[email protected]>

daira force-pushed the ecc-governance-drafts branch from 0b9899c to b88a415 Compare March 20, 2025 22:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add draft governance ZIPs #989

Add draft governance ZIPs #989

daira commented Mar 4, 2025

nuttycom left a comment

nuttycom Mar 19, 2025

nuttycom left a comment

nuttycom Mar 19, 2025

jswihart Mar 20, 2025

daira Mar 20, 2025

nuttycom Mar 19, 2025

nuttycom Mar 19, 2025

nuttycom Mar 19, 2025

nuttycom Mar 19, 2025

jswihart Mar 20, 2025

nuttycom Mar 20, 2025 •

edited

Loading

daira Mar 20, 2025

nuttycom Mar 19, 2025

daira Mar 20, 2025 •

edited

Loading

nuttycom Mar 19, 2025

daira Mar 20, 2025 •

edited

Loading

nuttycom Mar 19, 2025

daira Mar 20, 2025

nuttycom Mar 19, 2025

daira Mar 20, 2025

nuttycom Mar 19, 2025


		Any changes to the ZCG or its governance, such as its expansion to include more members, may be desired but are specifically outside this proposal’s scope.

		The full implementation of this proposal would require the design and implementation of a lockbox distribution mechanism, likely using multisig. This mechanism would be similar to that needed for an alternative proposal, the Community and Coin-holder Funding Model [^draft-ecc-community-and-coinholder]. However, this proposal does not require that a lockbox distribution mechanism be implemented at the same time as a change to the funding stream.


		Each Constituency initially receives three Voting Units. This MAY be changed by a Governance Proposal.

		Constituencies other than the Coin-holder Constituency above are called Organizational Constituencies. The Organizational Constituencies will together elect a representative responsible for establishing a clear process and mechanism for gathering coin-holder sentiment, which will then be used as the decision-making process of the Coin-holder Constituency.


		### Approval Thresholds

		The Approval Threshold is the absolute majority, as a proportion of the total number of Eligible Voting Units, required for a Proposal to be Approved. As stated earlier, Eligible Voting Units do not include those of Constituencies that have a conflict of interest for this Proposal. However, they do include the Voting Units of Constituencies that have no conflict of interest but choose to abstain.


		By default, a Governance Proposal requires a three-fifths Approval Threshold, and MUST have a Deadline at least two weeks from when the Proposal is published on-chain.

		All Consituencies MUST be consulted in order to determine whether they consider a draft Proposal to be "controversial", before it published on-chain. If any Constituency decides that a Proposal should be treated as controversial, it is then subject to a higher Approval Threshold of three quarters, and a Deadline at least four weeks from when the Proposal is published on-chain. (In the case of the Coin-holder constituency, a coin-holder vote is not necessarily required to establish this; it is likely sufficient to decide based on forum discussions for example.)

		In the case of Governance Proposals that affect consensus, final ratification occurs when node operators adopt the software implementing the changes.

		Note: Nothing forces developers of Zcash consensus node software to follow this specification. The aim of a process specification like this one is only to establish a social consensus. It fundamentally cannot affect the autonomy of developers of Zcash consensus node software to publish (or not) the software they want to publish, or the autonomy of node operators to run (or not) the software they want to run.


		### Exceptional decisions to remediate security vulnerabilities

		The governance processes specified in this ZIP are not intended to prevent consensus node implementors from making consensus changes that they reasonably believe are critical to maintain the security of the Zcash Mainnet network and/or Zcash users. Such changes might need to be developed and released according to a controlled disclosure process that precludes public voting.

		A funding stream will be established for a Zcash Community Fund, consisting of 20% of the block subsidy paid to a 2-of-3 P2SH multisig with keys held by the Financial Privacy Foundation, the Zcash Foundation and the Electric Coin Company ("Key-holder Organisations").

		This funding stream will start immediately on activation of this ZIP, which is assumed to be after the expiry of the existing ``FS_FPF_ZCG`` and ``FS_DEFERRED`` funding streams. It is proposed to be continued until modified by a future network upgrade.

Add draft governance ZIPs #989

Are you sure you want to change the base?

Add draft governance ZIPs #989

Conversation

daira commented Mar 4, 2025

nuttycom left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nuttycom left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nuttycom Mar 20, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daira Mar 20, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daira Mar 20, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nuttycom Mar 20, 2025 •

edited

Loading

daira Mar 20, 2025 •

edited

Loading

daira Mar 20, 2025 •

edited

Loading