Upgrade Uniswap’s current governance contract from Governor Alpha to Governor Bravo to improve governance upgradability and protocol safety.
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 contract used, was a great start, but in light of Compound’s and other protocols upgrade to Governor Bravo, Uniswap should migrate given Bravo’s additional safety benefits and upgradability.
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.
After speaking with the OpenZeppelin team about their reimplementation of Governor Bravo, we think using Compound’s Governor Bravo contract instead makes the most sense at this stage.
Although Open Zeppelin’s Governor contract takes a simpler approach that can include all Bravo functionality, it does not do so 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 the safety and simplicity of Uniswap, we think using Compound’s Governor Bravo contract is the best decision for the time being. Compound’s Governor contract has already undergone an audit by OpenZeppelin and has been widely used. We can always change/upgrade to Open Zeppelin Governor contract at a future date if their contract introduces new features/functionality the community is interested in. More details on OpenZeppelin’s code can be found here:
As mentioned in the previous Consensus Check, we have deployed the contract on the Ropsten test net for the community to review our code:
NB: The _initiate function has been slightly modified to take an initial proposal number as an input rather than pulling it from Governor Alpha. This way Uniswap can resume proper proposal numbering.
Upgrade Uniswap’s current governance contract from Governor Alpha to Governor Bravo to improve governance upgradability and protocol safety.
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 contract used, was a great start, but in light of Compound’s and other protocols upgrade to Governor Bravo, Uniswap should migrate given Bravo’s additional safety benefits and upgradability.
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.
After speaking with the OpenZeppelin team about their reimplementation of Governor Bravo, we think using Compound’s Governor Bravo contract instead makes the most sense at this stage.
Although Open Zeppelin’s Governor contract takes a simpler approach that can include all Bravo functionality, it does not do so 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 the safety and simplicity of Uniswap, we think using Compound’s Governor Bravo contract is the best decision for the time being. Compound’s Governor contract has already undergone an audit by OpenZeppelin and has been widely used. We can always change/upgrade to Open Zeppelin Governor contract at a future date if their contract introduces new features/functionality the community is interested in. More details on OpenZeppelin’s code can be found here:
As mentioned in the previous Consensus Check, we have deployed the contract on the Ropsten test net for the community to review our code:
NB: The _initiate function has been slightly modified to take an initial proposal number as an input rather than pulling it from Governor Alpha. This way Uniswap can resume proper proposal numbering.
Can someone clarify if the Governor Bravo 2-day review period lengthens the voting period by two days or actually delays the snapshot of voters' voting power by twos days?
Can someone clarify if the Governor Bravo 2-day review period lengthens the voting period by two days or actually delays the snapshot of voters' voting power by twos days?
If it's the former, why does this text mention that Governor Alpha instantly snapshots users' voting power? If it's the latter, doesn't a 2-day delay open us up to opportunistic edge case exploitation as described in Scenario 1 of the Uniswap Docs Adversarial Circumstances section?
Thank you.
Can someone clarify if the Governor Bravo 2-day review period lengthens the voting period by two days or actually delays the snapshot of voters' voting power by twos days?
Can someone clarify if the Governor Bravo 2-day review period lengthens the voting period by two days or actually delays the snapshot of voters' voting power by twos days?
If it's the former, why does this text mention that Governor Alpha instantly snapshots users' voting power? If it's the latter, doesn't a 2-day delay open us up to opportunistic edge case exploitation as described in Scenario 1 of the Uniswap Docs Adversarial Circumstances section?
Thank you.
The 2-day review period doesn't snapshot users' votes. The snapshot occurs at the beginning of the voting window. So 2-days passes where users can move their coins and analyze the proposal, then voting begins.
The 2-day review period doesn't snapshot users' votes. The snapshot occurs at the beginning of the voting window. So 2-days passes where users can move their coins and analyze the proposal, then voting begins.
