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

[ericwong]

Abstract

The purpose of this ZEIP (ZeroExImprovementProposal) is to propose a technical implementation for governance of the 0x Protocol and treasury that continues the journey of the decentralization roadmap — bringing the 0x Protocol upgrades to an on-chain binding vote. A successful transition to on-chain governance will put the future of 0x Protocol fully in the hands of the community, making it truly an unstoppable settlement layer for the global exchange of value.

Follow the open-source development of this system of smart contracts here.

Context

The 0x Protocol ecosystem — the protocol, the community-owned treasury, the DAO — has followed a progressive decentralization roadmap that started with the 0x Labs team serving as the main steward and ends with collective ownership by ZRX holders coordinated via on-chain governance. The need for this decentralized governance is well articulated by Will Warren; “This pipeline of smart contracts [that make up the 0x Protocol] could end up facilitating many trillions of dollars in exchange so the upgrade process must be extremely secure and invulnerable to censorship or government intermediation. In other words, governance over upgrades must be decentralized.”

The 0x Protocol was developed to serve as the open standard and common building block for exchange functionality amongst dApps. There are two main mechanisms to achieve this: (1) protocol updates that make changes to the set of smart contracts to ensure appropriate technical capabilities and (2) disbursement of funds from the protocol treasury to encourage the growth of the 0x Protocol ecosystem.

At the time of writing this post, a community-owned treasury has been deployed and governed by community members via an on-chain process. The next step in the decentralization roadmap is to migrate the upgradeable process of the protocol to an on-chain process as well.

Before exploring what’s next, here are brief descriptions of the current state of governance of the community-owned treasury and the protocol.

Community-Owned Treasury

The community-owned treasury exists to fund technical and non-technical initiatives that broadly grow the 0x ecosystem and its community. Community proposals should aim to disburse those funds in ways that promote the protocol’s long-term sustainability and achieve its mission.

Governance of the treasury is currently executed via on-chain token-weighted voting. There is a three-step process that manages treasury proposals that ultimately results in an on-chain vote enabled using the legacy staking implementation of ZRX tokens. Approved proposals are executed by the Treasury contract.

Protocol

The purpose of the protocol is to serve as a credibly neutral set of open source contracts that settle the exchange of value in a non-custodial way. Protocol update proposals should aim to ensure that the protocol can continue to serve in this capacity within the continually evolving context of the blockchain space.

Governance of the protocol is currently executed via off-chain token weighted voting. There is a ZEIP process that manages protocol update proposals that ultimately results in an off chain vote. Approved proposals are executed by the Governor contract, ZeroExGovernor. Currently, a time-locked multi-sig wallet operated by 0x Labs is the only contract allowed to perform administrative updates to the exchangeProxy contract.

What’s next

The rest of this forum post proposes a technical implementation that would enable on-chain binding governance system.

A successful transition to a fully on-chain governance process for 0x will be a tremendous milestone, reducing the barrier for any developer within the broader blockchain ecosystem to contribute directly to the protocol and extend its functionality, enabling a Cambrian explosion of innovation on a smart contract level!

Proposal

The proposed implementation defines a new smart contract governance system for the Protocol and Treasury that is based largely on the Compound governance model. The resulting smart contracts will replace the existing zeroExGovernor contract to trigger on-chain actions via an on-chain binding vote.

Note: These technical changes will not change the temperature check processes as outlined previously.

We’re aiming to reuse as much of the existing audited and in-production implementations of governance as possible, building off of OpenZepplin’s battle tested contracts. The proposed governance system will have snapshotting, delegation, and upgradeable vote tallying capacity. Timelock logic will apply for any approved proposal before execution to provide a time buffer for security measures. All meta governance variables such as Voting Delay, Voting Period, Quorum, Timelock, etc. can be subject to change via governance.

This post proposes slightly different governance mechanisms between that of the treasury versus the protocol. Critically, what is similar between both systems is that they are both fully on-chain binding. Below are brief descriptions and justifications for the proposed governance mechanisms.

Treasury Governance

The nature of the community-owned treasury is to encourage experimentation and growth of the ecosystem. In line with that spirit, this post suggests that we experiment with some governance mechanisms for the treasury.

The two main experiments proposed with treasury governance is (1) the use of quadratic voting and (2) calculating quorum as a percentage of the total active quadratic voting power.

1. We propose quadratic voting as it is an approach that redistributes voting power from whales to smaller token holders. We believe that this property is favorable for treasury proposals similar to why Gitcoin employs quadratic funding — the voices of the many should be weighed proportionally mored to the voice of the few.
2. 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. We view this as an incentive to higher voter participation — more voting power participation = more robust governance!

We feel that this risks associated with this level of experimentation in treasury governance is offset by the total risk presented to the 0x Protocol ecosystem by the current treasury. We believe that there is ample time to ensure that this more experimental governance mechanism is secure before the future state when the entirety of the Ecosystem Development Fund is transferred to the treasury.

Protocol Governance

The nature of 0x Protocol is to serve as a secure and reliable foundational building block for other dApps and projects. As such, this post suggests that we stick more closely to what continues to serve as the industry standard for governance mechanism. In the meantime, we should continue to monitor and consider adopting the research, development, and live testing done with other forms of governance.

The proposed mechanism for protocol governance as compared to the experiments described above for treasury governance is (1) 1 token 1 vote and (2) quorum is based on a set quantity of voting power.

Summary

A table is provided below that summarizes the meta governance variables and the proposed initial values.

Variable	Description	Proposed Initial Value
Voting power	How voting power for a given account is determined	treasury = quadratic protocol = 1:1
Voting delay	Delay from proposal creation until voting starts. Voting power for a given account is calculated after this voting delay.	treasury = 2 day protocol = 2 day
Voting period	Duration of the vote.	treasury = 7 days protocol = 7 days
Proposal threshold	Minimum amount of voting power needed to create a proposal.	treasury = sqrt(250k) protocol = 1M
Quorum	Minimum amount of voting power participating in a proposal to make it valid.	treasury = 10% protocol = 10M
timelock	Time delay between proposal passes to when it is executed.	treasury = 2 days protocol = 3 days

Decommissioning previous 0x Protocol Governance Mechanism

This upgrade will also decommission the 0x V3 staking pool contract that is currently used for Treasury governance. A migration path will be provided for ZRX holders who are users of 0x V3 staking to transition to the new proposed governance system.

Auditing

An audit for the proposed set of smart contracts has been scheduled.

This technical solution is developed publicly and will be open-sourced on Github here.

Migration Plan

We propose a three step migration plan from the current governance system to the proposed fully on-chain system:

1. Deployment of the new governance smart contracts

   A temperature check will be taken for the community to signal whether or not there is support for the development and deployment of on-chain governance as proposed.

2. Migration period

   A buffer period will be used to provide time for the community to transition from the current governance system to the newly deployed set of smart contracts. User interfaces to make this migration as simple as possible will be provided.

3. Vote to switch of governance system

   A vote will be taken for the community to decide whether or not to change the owner, and thus upgradability power, of the exchangeProxy contract from the current governance system to the new governance system.

Security Measures

The blockchain space is an extremely adversarial environment and as such, a fully on-chain governance mechanism must be accompanied with robust security practices to ensure that 0x Protocol will continue to function properly.

Below are two top security measures that we believe are critical to have in place for 0x Protocol to transition to on-chain governance according to the technical implementation described above.

0x Protocol Security Council

In short, the 0x Protocol Security Council is a group that has very limited but impactful power over 0x Protocol to enable it to address any vulnerabilities that are found. Their sole objective would be to serve as a security failsafe that can act faster than a full governance process in the case of existential crisis such as a mission-critical security risk.

There will be a subsequent post that fully describes the concept of a 0x Protocol Security Council. We believe that establishing this group reflects a crucial parallel evolution in the 0x community to support the technical milestone of on-chain governance.

Bug Bounty

The current bug bounty program for 0x Protocol is hosted by 0x Labs [1, 2] which features rewards up to $1,000,000 for critical exploits in 0x Protocol V4 and we believe that the continuation of this bug bounty program is absolutely necessary.

This program can be funded via a treasury grant allocation with co-sponsorship by stakeholders like 0x Labs that have a vested interest in securing 0x Protocol. Additionally, the responsibility of running this program can transition to the 0x Protocol Security Council.

Conclusion

In order for 0x Protocol to serve as the credibly neutral and uncensorable open standard for the global exchange of value, its governance needs to be decentralized. This post proposes both a technical implementation that will enable governance to occur fully on-chain and security measures that must be in place to ensure that the protocol is properly protected. A successful transition here will mark a pivotal moment in the decentralization roadmap of 0x — a point where the future of 0x Protocol is fully in the hands of the community and where 0x Protocol becomes unstoppable.

[mintcloud]

This is an update I have personally been eager to see on for a very long time. Probably since 2019, when I joined the 0x Labs team This will make 0x Protocol an upgradable, secure AND unstoppable protocol, something that very few onchain protocols have currently. I also welcome the innovation around Treasury governance.
I support the plan wholeheartedly (disclaimer: I am part of the working group), and I’m excited to learn what others think about it.

[Patrick]

@ericwong

We propose quadratic voting as it is an approach that redistributes voting power from whales to smaller token holders. We believe that this property is favorable for treasury proposals similar to why Gitcoin employs quadratic funding — the voices of the many should be weighed proportionally mored to the voice of the few.

Quadratic voting is pretty experimental territory. It would be great to understand how quadratic voting embracing the vote buying approach to distribute votes among preferred focus of interests would interface with the ZRX governance token?

It appears that quadratic voting potentially can be a strong approach to use towards information being shown in a survey like manner. Is quadratic voting being seen as an approach to be used for a proposal with an Approve/Disapprove vote with two options?

It appears that some thought towards secrecy has been discussed due to recent proposals which some experts such as Park and Rivest perceive as an integral element to utilize to preserve security throughout the voting process. Are there any other aspects that Park and Rivest speak about in the following paper discussing the merits of quadratic voting to better assist in creating a secure system void of collusion that would be implemented?

qv-and-the-public-good.pdf

There are some researchers that have concerns that QV can be a greater opportunity for collusion to take hold through collusion of focus groups and Sybil attacks flooding the vote since many $1 dollar valued votes are greater than a single $10 dollar vote. QV diminishes the equality that 1p1v provides and therefor can provide greater opportunity for the wealthy to influence such votes unless collusion abilities are minimized. Are there such concerns shared?

[Patrick]

@ericwong

There will be a subsequent post that fully describes the concept of a 0x Protocol Security Council. We believe that establishing this group reflects a crucial parallel evolution in the 0x community to support the technical milestone of on-chain governance.

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.

[nikita]

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?

[ericwong]

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.

[ericwong]

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

[nikita]

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.

[gabririgo]

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

[ericwong]

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

[ericwong]

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.

[0xSHA]

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

[ericwong]

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

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!

[0xSHA]

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

[gabririgo]

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.

[gabririgo]

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.

[ericwong]

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.

[ericwong]

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.

[gabririgo]

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.

[elenag]

@gabririgo

token address in ZeroExVotes is immutable

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