ZEIP-95 | Migrating 0x Protocol to On-chain Governance Process

If Zeip-95 is to activate the 0x Protocol Security Council, would it not be beneficial for this post described above to be included in the Zeip-95 proposal? I assume the information would include the process of formation of the 0PSC, with details of its source of sustained funding, the positional makeup of the council, it’s detailed set of functions, and the process of which those functions are undertaken.

1/ Please confirm that the variable ‘voting power’ in the table in the forum post above is configurable by governance for both the protocol and treasury contracts and identify the specific contract function/s and available parameters.

2/ Please describe any modeling that was done to better understand the risk profile associated with the quadratic voting scheme being proposed. For example, any estimations of the cost to guarantee a vote outcome based on projected total active voting power at different address distribution scenarios.

3/ Please explain the game theory incentive to accrue governance tokens (either via personal holdings or via delegation) and participate in governance if voting power is proportionally decreased as aggregate tokens held and skin-in-the-game increase. Is it likely that quadratic voting will incentivize (or force) large token holders to distribute their holdings to multiple addresses to preserve their voting power, thereby creating and rewarding sybil behavior and introducing friction that disincentivizes voting or even holding large amounts of the token?

4/ Please specify how voting power will be determined for snapshot polls. For example, currently, snapshot voting power includes both staked and unstaked tokens.

5/ Please clarify the treasury proposal threshold amount in the table above.

6/ Please fully explain the role, responsibilities, authorities, and selection process for the security council.

7/ Please deconflict these two statements, which appear to be in direct contradiction:

PR641 - … [A]ll governance settings are fixed numbers i.e. governance quorum is not a percentage of total but a fixed value for both the protocol as well as treasury.

Forum - We propose calculating quorum as a percentage of total active quadratic voting power vs. total supply as it will require more voting power to participate in a vote as more voting power is activated.

8/ Currently, ERC20 Transformations are permissioned so only 0x Labs can deploy new Transformers. Will authority to deploy new Transformers transfer to governance as part of this upgrade?

Lots of good questions and points of clarification - will address those in a separate thread but want to share our current thoughts on Quadratic Voting.

tldr; we recognize we were premature to propose full quadratic voting at this stage given the current level of governance participation and lack of satisfactory sybil resistance mechanisms. We therefore propose Threshold Quadratic Voting, which initially will behave much like 1 token 1 vote but gives the community a easier path toward Quadratic Voting when systems are more mature and thus more secure.

We believe that Quadratic Voting is a meaningful form of governance to reach for for the effect it has in leveling the amount of influence that any individual has regardless of the amount of wealth they have. Particularly for treasury purposes, we believe that this behavior of giving more weight to the voices of the many is desirable.

That being said, a key component to making quadratic voting work is a sybil resistance mechanism, otherwise the cost of attack for a malicious actor is significantly lowered compared to 1 token 1 vote schemes. When looking at the current state of the art in decentralized identity solutions, we were not fully satisfied with them (e.g. Proof of Humanity’s verification requires picture and video submission, BrightID verification relies on wisdom of the crowd which may be a high cold start cost, and Gitcoin Passport integration would not be trustless).

We believe that in order for new forms of governance to be successful, it’ll take many small steps to build up the collective muscle for decentralized ownership and technical scaffolding for more interesting systems rather than one big leap.

In that light, we propose a modification to quadratic voting that we’re calling Threshold Quadratic Voting. The concept is hopefully easy simple to grasp: up to a threshold value voting power is calculated linearly (1 token 1 vote) and after which voting power is calculated quadratically. For example, Person A has 100 ZRX and Person B has 200 ZRX if a threshold value of 100 is used, Person A will have 100 voting power and Person B will have 110 voting power (100 + sqrt(100)).

We propose that the initial threshold value to be set to 1M ZRX and that this variable can be modified via governance. We acknowledge that this solution does not solve the hard problem of quadratic voting but instead gives the community an easier path to transitioning to quadratic voting when better solutions are found. This initial value of 1M in effect, makes voting power linear for almost all voters. However, we hope that with time, this variable value can be lowered such that we achieve the initial goal of giving more weight to the voices of smaller token holders.

Here is the a notebook that we used to determine that the cost of attack against pure quadratic voting is too low and that the threshold we’re proposing meaningfully increases that cost of attack. Below is a chart of what the cost of a 51% attack would be for different threshold values assuming that there are 20M ZRX active in governance split across 100 wallets.

Looking across the governance space, we see that there are many teams that are taking the lead in solving these harder problems of governance - for example this prop.house RFP for private voting solutions for Nouns DAO. We do not believe that we as 0x Protocol community needs to be the group to solve the problem of quadratic voting but instead should work with/support other teams whose mission are more directly focused on governance.

@nikita providing my thoughts on some of your other questions.

1/ Voting power is configurable via upgrading the ZeroExVotes . Linked here is the full contract and interface.

2/ See my comment above.

3/ Quadratic voting without sybil resistance mechanisms does indeed incentivize sybil behavior and introduce friction that disincentivizes voting for small token holders or distributing holdings to multiple addresses for large token holders. True quadratic voting, as written about by people like Vitalk, represents a more equitable voting scheme that levels the amount of influence that people have regardless of the amount of wealth they have.

We propose quadratic voting for treasury proposals and not for protocol upgrade proposals because we believe that the disbursement of funds should be decided in a way that’s more like 1 person 1 vote but that isn’t necessarily desired for protocol upgrade proposals. Since protocol upgrade proposals are proposed to be decided via 1 token 1 vote, there is no different in incentive to accrue governance tokens as there is currently.

4/ We propose that voting power in snapshot polls are determined the same as it would be on-chain - for protocol related proposals, voting power is calculated via 1 token 1 vote; for treasury related proposals, voting power is calculated via threshold quadratic voting.

5/ The 10% treasury proposal threshold amount means that quorum is 10% of the total amount of “active” ZRX - if it was implemented right now, it would be 10% of the amount of ZRX staked.

6/ We will publish a separate post in the governance forum describing the security council in more detail soon.

7/ Quorum for protocol proposals is a fixed number where as quorum for treasury proposals is a percentage. This can be seen here for protocol upgrade proposals and here for treasury proposals.

Thanks for the detailed response. I will have some other followup comments and questions later, but regarding #5, my question is about the minimum amount required to create a treasury proposal, not the quorum amount; and regarding #7, my question is why the PR description (https://github.com/0xProject/protocol/pull/641) says something different than the forum post and wanting to know which is correct. You seem to be saying that the forum post is correct but it appears to conflict with the PR description.

I welcome a formal decentralized ownership of 0x protocol. A technical note: imo a proposal that has already reached finality (i.e. has support from > 2/3 of all voting power and quorum) should become successful as soon as it becomes final. This would be particularly relevant in case of a bug fix where timing is relevant and the governance should be quick in coordinating an upgrade. I understand the ability of rollback without delay mitigates this issue, however I see no harm in allowing a proposal that would be executable anyway at the end of the voting period to becoming executable before voting ends (or voting ends when proposal result is final, i.e. either at the end of the voting period or when absolute majority of voting power supports it).

5/ Sorry for my misread and thanks for bringing this up since I need to propose a new value as we’re now proposing Threshold Quadratic Voting. The initial idea was that the proposal threshold would be 500 quadratic voting power but I wrote it as sqrt(250k) so that it would hopefully be easier to compare to the threshold for protocol upgrade proposals. In general, the philosophy around the values proposed is that treasury proposals come with less risk than protocol upgrade proposals and therefore the metagovernance variables should reflect that by making the bar lower for treasury proposals.

7/ Ah yes, I am saying that the forum post is correct and that the PR description will be updated (the places I point to in the smart contracts show that quorum is calculated as fixed number for protocol upgrade proposals and a percentage for treasury proposals).

hey @gabririgo, few thoughts here.

In terms of allowing a proposal to be executable before voting ends that would require a majority of voting power relative to the total supply of ZRX (~500M ZRX) supporting a proposal to ensure that voting outcome cannot change during the rest of the voting period. Based on historical turnout of any governance proposal across the entire space, that level of participation has never been seen so I’m not sure it makes sense to add the extra conditional that would allow for a proposal to be executed before voting ends.

In terms of advocating for a timelock, there seems to be consensus across the governance space that that additional time buffer is needed to give time for community members who do not support the proposal or if there’s a bug in the proposal, to exit their positions before a proposal is executed.

I don’t see why we need to include a QV implementation from the start if everyone agrees QV is not ready to be used

The 1M threshold is easily circumventable by big wallets. It would however impact delegates with +1M delegated power which is unfair imo

Also including the implementation would have some impact on gas costs which is something to consider regarding the long term use of the system

Thanks for your comment - want to clarify that the implementation of QV that we’re proposing would not impact delegates in the way that you are mentioning.

The way that voting power would be calculated is done at the level of each delegator, not at the level of each delegate. What this means is that if we did simple quadratic voting is (1) sum of sqrt of token balances VS. (2) sqrt of sum of token balances.

Here’s an example to be more illustrative of what this means: Delegate A has two delegators - Person B and Person C. Person B has 100 ZRX, Person C has 100 ZRX. Delegate A would have a total voting power of 20 = sqrt(100) + sqrt(100). This is in contrast to another approach where Delegate A would have a total voting power of 14 = sqrt(100 + 100).

What this means is that the threshold we’re proposing would only affect individual token holders who have +1M.

We will share what the expected gas costs for voting in the proposed governance system when we have those results :slight_smile:

I think that it’ll be great to include the proposed Threshold Quadratic Voting implementation so that there is a path for us as a community to transition to it that wouldn’t require any new deployments!

1 Like

Thanks for clarifying. I guess will be clearer when we have the final implementation.

I still think that including an unused feature is not worth the effort, especially if we have no visibility on how QV systems will evolve in the future. One might argue that at some point the old implementation will get deprecated and needs reworking hence cannot be activated without developing new contracts

Often the simplest solutions are the better alternative especially in times of incertitude

The incertitude here imo is that there is no common agreement on how a QV system should work, hence the discussions. Until this is resolved I don’t think zrx holders will agree on reducing the threshold, on the other hand if QV systems are proven reliable there is a high change the inner working would be different than what we currently know, which will most likely lead to new development

On the timelock, I personally do not think allocating more time for holders to react will make a meaningful difference, but it is only my opinion and I respect your position. In regards to absolute majority, I was not referring to the total supply of ZRX but of the voting power, i.e. WZRX. Total supply of WZRX will most likely be in the same order as the balance of ZRX vault, probably 2x because of simpler token model compared to the staking system. I assume only balances before a voting starts are considered as voting power, but if that means that an extra storage slot has to be updated every transaction (i.e. WZRX total supply at block) I am in favour of reverting my observation, and I understand that making a snapshot of WZRX total supply at proposal creation would not be ideal. I like the deterministic approach of the current staking system, however I am going to support and follow closely the new model as it pushes the boundaries of decentralized governance experimentation even further.

[ADDITION] reg. timelock, having an early voting end does not impact timelock, but makes a widely agreed-upon upgrade faster. Reg. voting power, can you please update the specs to reflect the required majority? It is my understanding that 2/3 of votes in favor are required, but you refer to 50% of ZRX total supply (500M ZRX). When I talk about absolute majority I refer to the final majority (2/3 of votes). A successful proposal should still require 2/3 of votes in favor. My proposal, therefore, only anticipates a state that would occur anyway at the end of the voting period. Given past history, I think it’s more likely that a bug in the code is discovered months after protocol is live rather than during the period an upgrade is proposed.

1/ Voting power is configurable via upgrading the ZeroExVotes . Linked here is the full contract and interface.

a few notes on this:

  • token address in ZeroExVotes is immutable

  • I cannot find the method to upgrade ZeroExVotes address neither in the 0x governance contracts, nor in the openzeppelin deps

  • There is no test that asserts such upgrade can be executed

Also two additional notes.
The use of “token” terminology as in

GovernorVotes _token

as in here is a bit misleading as GovernorVotes is not a token. Technically, it would probably be clearer if WrappedZRX was an upgradable proxy and inherited from GovernorVotes. This would result in one less contract address to manage and GovernorVotes would effectively be a token. I have seen other things in the code that I find not clear, but I’ll wait for the code to be ready for peer review to point them out as I believe it is still WIP.

Also I see typescript tests are missing. In this context, I strongly feel like adding a coverage tool ( i.e. coveralls.io) to the package, which will help understand what the overall code coverage is in % of the relevant lines of code, would be tremendously beneficial.

[ADDITION] it is my understanding that on L2s/sidechains, L1 voting will happen and a successful proposal will be sent to L2 as a relay message. I see no mention of this process in the ZEIP, and there is no L2 contract in the package. Can you please formalize the path for L2 governance implementation, whether it will be implemented at a later stage, whether custom L2 bridges will be deployed and maintained (by whom) or whether one or more existing message-relay bridges will be used for the purpose? Thank you a lot for clarifying this.

Hey @0xSHA, from a pure gas cost perspective, using the threshold quadratic voting mechanism that we’re proposing does not change the cost of voting or creating proposals so the added complexity does not impact regular governance activities.

I do believe that the QV implementation that we’ve developed and are proposing to leave there for us as a community to transition toward in the future is the correct implementation in terms of how voting power is calculated. The changes that would need to be incorporated in the future would be the sybil resistance mechanism which I agree would be new development but I don’t believe would replace any of the QV work here.

If there is strong sentiment to not include the Threshold Quadratic Voting mechanism that we’re proposing we could keep the work in a separate branch that future development can reference but given that it’s already developed and doesn’t impose any extra gas costs, I personally (and am definitely biased here) don’t see a problem with including it.

Ah I see what you’re saying now - thanks for clearing up the slight misunderstanding I had on both what you mean by majority of voting power and what ending voting early means.

I’ll let others who are more technical to chime in and correct me where I’m wrong but my guess is that these changes would require some engineering work (nothing hard but would be new implementations) - particularly to allow voting to end early, I believe the checks for queueing a successful proposal into the timelock include if the proposal deadline has passed.

In terms of required majority, I believe vote outcome is determined by if forVotes > againstVotes, rather than forVotes >= 2/3 voteSupply which is the case for other governance systems across the space.

thank you for getting into that. What is relevant to the proposal execution is the State of the proposal. hence the conditions that validate a particular state. In regards to the simple majority, I am worried that a highly controversial proposal may break the community apart, whereas a 2/3 majority would imply forVotes > 2x againstVotes which should give more resiliance to the governance decision making. Considering an upgrade to the protocol will affect $ Billions (and in the future Trillions) worth of tokens, a protocol upgrade should not be controversial by design imho.

The ZeroExVotes implementation is working via a vanilla openzeppelin ERC1967Proxy implementation and is upgradable that way while its proxy address remains immutable. The wrapped token itself on another hand is non-upgradable by design.
Note that although in openzeppelin’s ERC20Votes implementation for example the token and the voting logic are part of the same contract, we decided on a different design that abstracts the voting logic away from the token. This approach was discussed with openzeppelin here Quadratic voting - Contracts - OpenZeppelin Forum
The above discussion also holds the explanation as to why a reference to the voting contract - ZeroExVotes is named _token which is to emphasize compatibility with GovernorVotes implementation of openzeppelin but I do accept it’s confusing and have just pushed a rename of that.

On code coverage we do not use typescript for testing but do use coveralls and foundry and coverage is currently at >95% for contracts see latest report at 0xProject/protocol | Build #4425512986 | Coveralls - Test Coverage History & Statistics

2 Likes

WRT the open Snapshot vote:

1/ It isn’t clear what the implications and possible second and third order effects are of " 1. Deployment of the new governance smart contracts for initial calibration and testing." Please elaborate.

2/ Please explain the mechanism that would prevent or enable “2. Migration period: ZRX holders can start registering to the new system.”

3/ Approval is being sought to deploy the contracts prior to the audit being available for review. When do you expect the audit to be available?

hey @nikita - ty for these questions.

1/ The implications of (1) is that given the community signaling support for the proposed on-chain governance implementation, we will share all relevant reports (e.g. finalized audit, gas reports) and anything else that the community would like to know about the smart contracts we developed and that we will deploy the contracts onto mainnet. Included in the development process is thorough end to end integration and migration tests to ensure that everything functions properly. I’m not sure if I know what second and third order effects you may be referring to - if you could name some examples that you suspect could apply that would be helpful for me :slight_smile:

2/ The key mechanism that we will provide to assist with the migration period is a revamped Governance Portal UI that tokenholders can go to to unstake from the current governance system and activate their ZRX for the new governance system if they choose to opt-in. We plan to make a modification in the related proposal (New 0x Protocol Website — Open Application) to explicitly call out that a new governance portal is within this scope of work.

3/ The audit is being finalized this week and we will share the report out as soon as that is done! While we are seeing approval prior to the audit being available for review, we believe that the transition steps proposed, particularly with the migration period and future vote that would formally switch ownership of 0x Protocol to a new governance system gives the community ample opportunities to signal their support/disagreement with the system and that this vote does not, in any way bind the community to on-chain governance.

1 Like

hey y’all, had a few belated follow-ups and 1 clarification.

Follow-ups

Clarification

  • With the smart contracts deployed, the following migration milestones are
  1. On-chain vote to switch treasury to new treasury governor
  2. Unstake ZRX from the current staking system and migrate to new governance system
  3. ZEIP vote to switch exchange proxy owner to new protocol governor
1 Like