Upgrade Uniswap’s current governance contract from Governor Alpha to Governor Bravo because this will offer a number of benefits.
Co-written with Getty Hill (@Getty), Eddy Lee (@elee), Yuan Han Li (@yuan-han-li), John Wang (@johnwang), and Ali Khambati (@alikhambati)
Governor Alpha, the current governance framework, is a great start; however, in light of Compound’s upgrade to Governor Bravo, it would be prudent for Uniswap to consider a similar migration due to Governor Bravo’s strong value proposition:
Native upgradeability: Under Governor Alpha, changes to governance parameters require deploying a new contract and completely migrating to a new address. This is particularly damaging to governance participation as it introduces downtime and asynchronicity. Many governance tools and custodians use factory contracts which point to a specific contract address, meaning parties must manually upgrade their infrastructure every time governance parameters are changed under Governor Alpha. This includes tools for creating autonomous proposals like fish.vote; front-ends such as Tally, Sybil, and Boardroom which aggregate and display governance results for various protocols; and professional custodians which are used by large token holders, delegates, and community members. Enabling a static contract address that has proxy upgradability patterns is paramount for maximizing participation, and maintaining an open and secure governance process.
Voting reason string: Governor Bravo gives voters the opportunity to add free-form comments (text strings) along with their on-chain votes. Not only does this increase the transparency around the rationale people have behind their votes, but it also facilitates more in-depth and nuanced discussion.
New ‘abstain’ voting option: Governor Bravo enables voters to formally abstain rather than forcing them to choose between voting yes/no or not voting at all. This will give voters more flexibility and also increase transparency into delegate behavior.
Proposal numbers won’t reset: Under Governor Alpha, any upgrades to the contract resets the proposal number schema. Notice that ‘Proposal 0.4’ (which resulted in deployment and migration to a new Governor Alpha contract due to modifying the proposal submission threshold parameter) caused the following on-chain proposal from @HarvardLawBFI to be numbered ‘Proposal 1.1’. Under Governor Bravo, this would not be an issue and proposal numbers would be continuous because the contract would be maintained at a single address.
Proposal Cancellation: Bravo allows user-directed cancellations enabling erroneous proposals to be canceled if need be (rather than forcing people to vote no/abstain).
Review Period: Governor Bravo allows governance to include a review/analysis period. Currently, Compound uses a 13140 block (~2-day) review period that allows holders to review the proposal. This means that users will have 2-days to prepare for voting (e.g., remove UNI from Aave), unlike Governor Alpha which instantly snapshots users’ voting power. A review period substantially improves the accessibility and safety of the governance process.
The Snap Poll will be live for 96 hours (4 days) from July 27th at 00:00 EDT. If the poll passes with a minimum of 25,000 UNI in support, this proposal will move forward to the consensus check phase.
A link to our snapshot proposal: Snapshot
If the Temperature Check Snapshot proposal passes @Getty and @elee will do the necessary development work to migrate Uniswap from Governor Alpha to Bravo. The deployment and details will be included in the consensus check for the community to review.
Upgrade Uniswap’s current governance contract from Governor Alpha to Governor Bravo because this will offer a number of benefits.
Co-written with Getty Hill (@Getty), Eddy Lee (@elee), Yuan Han Li (@yuan-han-li), John Wang (@johnwang), and Ali Khambati (@alikhambati)
Governor Alpha, the current governance framework, is a great start; however, in light of Compound’s upgrade to Governor Bravo, it would be prudent for Uniswap to consider a similar migration due to Governor Bravo’s strong value proposition:
Native upgradeability: Under Governor Alpha, changes to governance parameters require deploying a new contract and completely migrating to a new address. This is particularly damaging to governance participation as it introduces downtime and asynchronicity. Many governance tools and custodians use factory contracts which point to a specific contract address, meaning parties must manually upgrade their infrastructure every time governance parameters are changed under Governor Alpha. This includes tools for creating autonomous proposals like fish.vote; front-ends such as Tally, Sybil, and Boardroom which aggregate and display governance results for various protocols; and professional custodians which are used by large token holders, delegates, and community members. Enabling a static contract address that has proxy upgradability patterns is paramount for maximizing participation, and maintaining an open and secure governance process.
Voting reason string: Governor Bravo gives voters the opportunity to add free-form comments (text strings) along with their on-chain votes. Not only does this increase the transparency around the rationale people have behind their votes, but it also facilitates more in-depth and nuanced discussion.
New ‘abstain’ voting option: Governor Bravo enables voters to formally abstain rather than forcing them to choose between voting yes/no or not voting at all. This will give voters more flexibility and also increase transparency into delegate behavior.
Proposal numbers won’t reset: Under Governor Alpha, any upgrades to the contract resets the proposal number schema. Notice that ‘Proposal 0.4’ (which resulted in deployment and migration to a new Governor Alpha contract due to modifying the proposal submission threshold parameter) caused the following on-chain proposal from @HarvardLawBFI to be numbered ‘Proposal 1.1’. Under Governor Bravo, this would not be an issue and proposal numbers would be continuous because the contract would be maintained at a single address.
Proposal Cancellation: Bravo allows user-directed cancellations enabling erroneous proposals to be canceled if need be (rather than forcing people to vote no/abstain).
Review Period: Governor Bravo allows governance to include a review/analysis period. Currently, Compound uses a 13140 block (~2-day) review period that allows holders to review the proposal. This means that users will have 2-days to prepare for voting (e.g., remove UNI from Aave), unlike Governor Alpha which instantly snapshots users’ voting power. A review period substantially improves the accessibility and safety of the governance process.
The Snap Poll will be live for 96 hours (4 days) from July 27th at 00:00 EDT. If the poll passes with a minimum of 25,000 UNI in support, this proposal will move forward to the consensus check phase.
A link to our snapshot proposal: Snapshot
If the Temperature Check Snapshot proposal passes @Getty and @elee will do the necessary development work to migrate Uniswap from Governor Alpha to Bravo. The deployment and details will be included in the consensus check for the community to review.
Got it, and makes sense from a security perspective!
Thanks for the mention @dennisonb. This is Francisco from OpenZeppelin.
We're indeed about to publish a system of Governor contracts compatible with GovernorBravo. A couple of benefits that might motivate this choice:
Thanks for the mention @dennisonb. This is Francisco from OpenZeppelin.
We're indeed about to publish a system of Governor contracts compatible with GovernorBravo. A couple of benefits that might motivate this choice:
The current version of the code can be found in the contracts/governance directory in the OpenZeppelin Contracts repo, but please note it is not released yet. (Can't include links due to new account.)
Happy to answer any further questions. :)
Thanks for sharing @Getty. Santiago from OpenZeppelin here. As I've mentioned over DM, we'd love to see Uniswap adopting the contract we've been working on - we're committed to maintaining it and adding new features requested by the community. But we understand that going with a more battle-tested and audited (ironically, by our own team) contract like Bravo makes sense for Uniswap.
However, one thing I'd add is that migrating from Bravo to our Governance contract in the future (in case you want to leverage new features) may require another redeploy, rather than an upgrade, since contract storage is not compatible. This would diminish the benefit of moving right now to Bravo, since native upgradeability would only be usable for moving to compatible Bravo implementations.
Thanks for sharing @Getty. Santiago from OpenZeppelin here. As I've mentioned over DM, we'd love to see Uniswap adopting the contract we've been working on - we're committed to maintaining it and adding new features requested by the community. But we understand that going with a more battle-tested and audited (ironically, by our own team) contract like Bravo makes sense for Uniswap.
However, one thing I'd add is that migrating from Bravo to our Governance contract in the future (in case you want to leverage new features) may require another redeploy, rather than an upgrade, since contract storage is not compatible. This would diminish the benefit of moving right now to Bravo, since native upgradeability would only be usable for moving to compatible Bravo implementations.
Now, I'm curious if having our Governor externally audited could change the current decision. If so, can I ask you about the timeline you have in mind for migrating? So we know whether this migration is intended to happen in the immediate future, or it is possible to get an external firm to audit our contract in time.
Got it, and makes sense from a security perspective!
Thanks for the mention @dennisonb. This is Francisco from OpenZeppelin.
We're indeed about to publish a system of Governor contracts compatible with GovernorBravo. A couple of benefits that might motivate this choice:
Thanks for the mention @dennisonb. This is Francisco from OpenZeppelin.
We're indeed about to publish a system of Governor contracts compatible with GovernorBravo. A couple of benefits that might motivate this choice:
The current version of the code can be found in the contracts/governance directory in the OpenZeppelin Contracts repo, but please note it is not released yet. (Can't include links due to new account.)
Happy to answer any further questions. :)
Thanks for sharing @Getty. Santiago from OpenZeppelin here. As I've mentioned over DM, we'd love to see Uniswap adopting the contract we've been working on - we're committed to maintaining it and adding new features requested by the community. But we understand that going with a more battle-tested and audited (ironically, by our own team) contract like Bravo makes sense for Uniswap.
However, one thing I'd add is that migrating from Bravo to our Governance contract in the future (in case you want to leverage new features) may require another redeploy, rather than an upgrade, since contract storage is not compatible. This would diminish the benefit of moving right now to Bravo, since native upgradeability would only be usable for moving to compatible Bravo implementations.
Thanks for sharing @Getty. Santiago from OpenZeppelin here. As I've mentioned over DM, we'd love to see Uniswap adopting the contract we've been working on - we're committed to maintaining it and adding new features requested by the community. But we understand that going with a more battle-tested and audited (ironically, by our own team) contract like Bravo makes sense for Uniswap.
However, one thing I'd add is that migrating from Bravo to our Governance contract in the future (in case you want to leverage new features) may require another redeploy, rather than an upgrade, since contract storage is not compatible. This would diminish the benefit of moving right now to Bravo, since native upgradeability would only be usable for moving to compatible Bravo implementations.
Now, I'm curious if having our Governor externally audited could change the current decision. If so, can I ask you about the timeline you have in mind for migrating? So we know whether this migration is intended to happen in the immediate future, or it is possible to get an external firm to audit our contract in time.
Hello folks, Dennison from Tally here.
We strongly support this proposal. It follows in the steps of Compound, allows governance to be more flexible and supports upgrades without proposal renumbering.
Hello folks, Dennison from Tally here.
We strongly support this proposal. It follows in the steps of Compound, allows governance to be more flexible and supports upgrades without proposal renumbering.
We also would like to suggest that the starting number of the new Bravo Governance be set to reflect all the past proposals, including the failed proposal. The Uniswap numbering convention of 0.x and 1.x is not standard and is not used in any of the other Compound-style governances in the ecosystem. Additionally, despite the failed proposal, well, failing, it still is a part of the official on-chain record of Uniswap governance and should not be, in our opinion omitted, as it's participants and ballots still form part of the large picture of Uniswap.
Regardless, upgrading to Bravo is in our opinion the right way to go and we are looking forward to it!
One additional option that should be considered at this point is, OpenZeppelin will be releasing a complete set of Compound Compatible Governance contracts in a soon-to-be-released version of the OpenZeppelin contracts. Considering OpenZeppelin is the leader of standards in the Ethereum ecosystem, it might be worth while to wait to evaluate the OpenZeppelin solutions to see if they might provide an even better solution.
Hello folks, Dennison from Tally here.
We strongly support this proposal. It follows in the steps of Compound, allows governance to be more flexible and supports upgrades without proposal renumbering.
Hello folks, Dennison from Tally here.
We strongly support this proposal. It follows in the steps of Compound, allows governance to be more flexible and supports upgrades without proposal renumbering.
We also would like to suggest that the starting number of the new Bravo Governance be set to reflect all the past proposals, including the failed proposal. The Uniswap numbering convention of 0.x and 1.x is not standard and is not used in any of the other Compound-style governances in the ecosystem. Additionally, despite the failed proposal, well, failing, it still is a part of the official on-chain record of Uniswap governance and should not be, in our opinion omitted, as it's participants and ballots still form part of the large picture of Uniswap.
Regardless, upgrading to Bravo is in our opinion the right way to go and we are looking forward to it!
One additional option that should be considered at this point is, OpenZeppelin will be releasing a complete set of Compound Compatible Governance contracts in a soon-to-be-released version of the OpenZeppelin contracts. Considering OpenZeppelin is the leader of standards in the Ethereum ecosystem, it might be worth while to wait to evaluate the OpenZeppelin solutions to see if they might provide an even better solution.
For the sake of argument. Say you have two choices.
Where OZ's Governance contract has been fully audited and is ready right now and has all of the Bravo functionality.
I would choose Bravo because it is the tried and tested governance contract.
For the sake of argument. Say you have two choices.
Where OZ's Governance contract has been fully audited and is ready right now and has all of the Bravo functionality.
I would choose Bravo because it is the tried and tested governance contract.
If there are two contracts with the same functionality, but one is common, and the other hasn't been used, then it is a no-brainer to choose the one in use.
I’m in support of upgrading to bravo but agree with Dennison’s point about waiting to see what the Open Zeppelin contracts look like.
Hey Dennison, thank you very much for your feedback, we will be sure to number the proposal with #7 if it goes to a formal vote (that is, assuming nothing else gets proposed on-chain in the meantime).
@frangio, thank you also for sharing more about what you guys are working on at OpenZeppelin. We have DMed you on Twitter to open up a line and so we can chat more about OpenZeppelin's solutions.
After talking with the OpenZeppelin guys about their governance contract, we think using Governor Bravo makes the most sense at this stage.
Their governance contract takes a more simple approach that can include all Bravo functionality but does not by default. The contract uses similar logic, but the code is new. It has gone through an internal audit and review process but still needs to go through an external audit.
After talking with the OpenZeppelin guys about their governance contract, we think using Governor Bravo makes the most sense at this stage.
Their governance contract takes a more simple approach that can include all Bravo functionality but does not by default. The contract uses similar logic, but the code is new. It has gone through an internal audit and review process but still needs to go through an external audit.
For safety and simplicity, we think using Governor Bravo is the best decision right now. Bravo has already undergone an audit by OpenZeppelin and is widely used. We can always change/upgrade at a future date if OZ's Governance contract introduces new features/functionality the community is interested in.
For the sake of argument. Say you have two choices.
Where OZ's Governance contract has been fully audited and is ready right now and has all of the Bravo functionality.
I would choose Bravo because it is the tried and tested governance contract.
For the sake of argument. Say you have two choices.
Where OZ's Governance contract has been fully audited and is ready right now and has all of the Bravo functionality.
I would choose Bravo because it is the tried and tested governance contract.
If there are two contracts with the same functionality, but one is common, and the other hasn't been used, then it is a no-brainer to choose the one in use.
I’m in support of upgrading to bravo but agree with Dennison’s point about waiting to see what the Open Zeppelin contracts look like.
Hey Dennison, thank you very much for your feedback, we will be sure to number the proposal with #7 if it goes to a formal vote (that is, assuming nothing else gets proposed on-chain in the meantime).
@frangio, thank you also for sharing more about what you guys are working on at OpenZeppelin. We have DMed you on Twitter to open up a line and so we can chat more about OpenZeppelin's solutions.
After talking with the OpenZeppelin guys about their governance contract, we think using Governor Bravo makes the most sense at this stage.
Their governance contract takes a more simple approach that can include all Bravo functionality but does not by default. The contract uses similar logic, but the code is new. It has gone through an internal audit and review process but still needs to go through an external audit.
After talking with the OpenZeppelin guys about their governance contract, we think using Governor Bravo makes the most sense at this stage.
Their governance contract takes a more simple approach that can include all Bravo functionality but does not by default. The contract uses similar logic, but the code is new. It has gone through an internal audit and review process but still needs to go through an external audit.
For safety and simplicity, we think using Governor Bravo is the best decision right now. Bravo has already undergone an audit by OpenZeppelin and is widely used. We can always change/upgrade at a future date if OZ's Governance contract introduces new features/functionality the community is interested in.
