One of the goals of the Uniswap Foundation is to reduce the amount of friction in the community governance process. In that spirit, today we are proposing changes to that process to improve its efficiency and efficacy.
We propose the following changes to the community governance process:
Remove the first off-chain Snapshot poll, and replace it with a “Request for Comment” post. The first phase of the governance process should allow the community to digest a proposal, comment, and ask questions -- and for the proposer to respond and make updates. We also believe two off-chain votes introduces unnecessary friction, so we propose removing this first one.
Increase quorum for the remaining off-chain Snapshot poll in the second phase to 5M UNI. The purpose of this off-chain vote is to gauge community sentiment prior to the governance vote. We believe the 5M UNI quorum will act as a better signal than the lower quorum requirements in the current process.
We also propose to formalize a process for future changes to off-chain components of the governance process (like the changes discussed in this proposal): specifically, an off-chain Snapshot poll with the same parameters of the on-chain governance vote. Today, this would require a 7-day voting period with a 40M UNI quorum. All changes that entail changes to on-chain parameters should continue to go through the normal community governance process.
In 3 weeks, on Monday, December 12, we will post a Snapshot poll for the community to vote on these changes. As described above, the vote will last for 7-days and have a 40M UNI quorum.
Uniswap’s governance process is a core input to the community’s ability to steward its ongoing maintenance and growth in a fair and transparent manner. The design of the process should optimize for the dissemination of information throughout the community, for thoughtful iterations on proposals, and for signaling from the community prior to on-chain votes. While the governance process put in place today has, for the most part, been successful in achieving those goals, we believe improvements can be made to reduce overhead and to enhance off-chain signaling prior to the final governance vote.
These process enhancements were previously discussed in the forum here, but the simplifications were never implemented. We have decided to bring them back with minor changes.
Below we lay out the suggested changes, alongside our rationale. We are excited to hear and incorporate your feedback into this process change.
A detailed outline of the current process can be found here.
Temperature Check: A temperature check is accompanied by a 3-day snapshot poll with a 25k UNI quorum.
Consensus Check: A consensus check is accompanied by a 5-day snapshot poll with a 50k UNI quorum.
Governance Proposal: The on-chain proposal and vote, tied to on-chain executable code, is the final phase of the governance process. The proposer must have a minimum of 2.5M UNI delegated to their address, and there is a 40M UNI quorum requirement.
Phase 1: Request for Comment
We believe the first phase of the governance process should allow the community to digest a proposal, comment, and ask questions. The RFC Phase should last for at least 3 days so the proposers can gather adequate feedback to take into account for the next iteration of the proposal.
We are also removing the friction of two off-chain votes.
Phase 2: Temperature Check
For this phase to better serve as a signaling tool, we suggest increasing quorum to 5M UNI. This threshold should be high enough to prevent lower quality proposals from moving to the final on-chain vote, while not creating additional friction.
Phase 3: On-chain Governance Vote
In her original post on the community governance process, Ashleigh states “On-chain voting is not necessary to make updates to off-chain processes.” We agree with this. However, we do believe that community support and acceptance is important for off-chain process changes to have legitimacy.
Thus, we propose a formalized process -- intended to signal community support and acceptance -- to change these off-chain components in the future. Specifically, we propose an off-chain vote with the same parameters of the final governance vote. Right now, that is a 7 day vote period and 40M UNI quorum.
These are the parameters we plan to use to pass all of the proposed changes in this proposal.
We welcome all feedback from the community on these proposed changes, and will incorporate feedback into the proposal where sentiment is strong.
If no serious changes to the proposal are required, we plan to post a Snapshot Poll in 3 weeks, on Monday, December 12th for the community to vote on these changes. This vote will last for 7 days and require a quorum of 40M UNI votes.
If the vote passes, the UF will update relevant documentation on the forum and elsewhere.
One of the goals of the Uniswap Foundation is to reduce the amount of friction in the community governance process. In that spirit, today we are proposing changes to that process to improve its efficiency and efficacy.
We propose the following changes to the community governance process:
Remove the first off-chain Snapshot poll, and replace it with a “Request for Comment” post. The first phase of the governance process should allow the community to digest a proposal, comment, and ask questions -- and for the proposer to respond and make updates. We also believe two off-chain votes introduces unnecessary friction, so we propose removing this first one.
Increase quorum for the remaining off-chain Snapshot poll in the second phase to 5M UNI. The purpose of this off-chain vote is to gauge community sentiment prior to the governance vote. We believe the 5M UNI quorum will act as a better signal than the lower quorum requirements in the current process.
We also propose to formalize a process for future changes to off-chain components of the governance process (like the changes discussed in this proposal): specifically, an off-chain Snapshot poll with the same parameters of the on-chain governance vote. Today, this would require a 7-day voting period with a 40M UNI quorum. All changes that entail changes to on-chain parameters should continue to go through the normal community governance process.
In 3 weeks, on Monday, December 12, we will post a Snapshot poll for the community to vote on these changes. As described above, the vote will last for 7-days and have a 40M UNI quorum.
Uniswap’s governance process is a core input to the community’s ability to steward its ongoing maintenance and growth in a fair and transparent manner. The design of the process should optimize for the dissemination of information throughout the community, for thoughtful iterations on proposals, and for signaling from the community prior to on-chain votes. While the governance process put in place today has, for the most part, been successful in achieving those goals, we believe improvements can be made to reduce overhead and to enhance off-chain signaling prior to the final governance vote.
These process enhancements were previously discussed in the forum here, but the simplifications were never implemented. We have decided to bring them back with minor changes.
Below we lay out the suggested changes, alongside our rationale. We are excited to hear and incorporate your feedback into this process change.
A detailed outline of the current process can be found here.
Temperature Check: A temperature check is accompanied by a 3-day snapshot poll with a 25k UNI quorum.
Consensus Check: A consensus check is accompanied by a 5-day snapshot poll with a 50k UNI quorum.
Governance Proposal: The on-chain proposal and vote, tied to on-chain executable code, is the final phase of the governance process. The proposer must have a minimum of 2.5M UNI delegated to their address, and there is a 40M UNI quorum requirement.
Phase 1: Request for Comment
We believe the first phase of the governance process should allow the community to digest a proposal, comment, and ask questions. The RFC Phase should last for at least 3 days so the proposers can gather adequate feedback to take into account for the next iteration of the proposal.
We are also removing the friction of two off-chain votes.
Phase 2: Temperature Check
For this phase to better serve as a signaling tool, we suggest increasing quorum to 5M UNI. This threshold should be high enough to prevent lower quality proposals from moving to the final on-chain vote, while not creating additional friction.
Phase 3: On-chain Governance Vote
In her original post on the community governance process, Ashleigh states “On-chain voting is not necessary to make updates to off-chain processes.” We agree with this. However, we do believe that community support and acceptance is important for off-chain process changes to have legitimacy.
Thus, we propose a formalized process -- intended to signal community support and acceptance -- to change these off-chain components in the future. Specifically, we propose an off-chain vote with the same parameters of the final governance vote. Right now, that is a 7 day vote period and 40M UNI quorum.
These are the parameters we plan to use to pass all of the proposed changes in this proposal.
We welcome all feedback from the community on these proposed changes, and will incorporate feedback into the proposal where sentiment is strong.
If no serious changes to the proposal are required, we plan to post a Snapshot Poll in 3 weeks, on Monday, December 12th for the community to vote on these changes. This vote will last for 7 days and require a quorum of 40M UNI votes.
If the vote passes, the UF will update relevant documentation on the forum and elsewhere.
Snapshot voting should not be used for decision-making because a large amount of UNI cannot participate in Snapshot due to custody providers inability to vote off-chain. All governance decisions should be decided on-chain.
Hi! Fabien from Snapshot here. Do you know which custodian(s) wouldn't work with Snapshot? AFAIK most custodians support Snapshot voting through delegation, I know Coinbase or Fireblocks are used and Anchorage recently added a way to do delegation (need to activate on request). Which one I'm missing?
Do anyone know how long it takes for my coins pairs to be listed on the pool list they where confirmed index onto uniswap dot org pool. Will they show up on list to the public? I add these coins pairs a few weeks ago and they still not in pool search list!
( EAMIINFT / MATIC ) and ( BHOIINFT / MATIC ) and ( MATIC / BTC ) and ( MATIC / AHLRCMETA ) and ( MATIC / CRYPTO ) and ( MATIC / CHURCH ) all these coins pairs on Polygonscan network. I added them now how do they show up in pool all search or pool list under Polygon. Is it a time period wait or i have to program them onto available Uniswap list? Please give code I will tip with some of my above Matic pairs too ERC-20 tokens!
I support modifying the governance process as outlined in the proposal - namely, eliminating the off-chain Snapshot poll, creating a “Request for Comment” phase, and increasing the quorum for the second phase.
Consistent with several other community members’ comments, I think the RFC process should be longer than 3 days; my view is that it should be at least 7 days long. Having a week provides necessary time to become aware of each proposal and formulate potential comments. Less than a week risks rushing the commentary process.
I support modifying the governance process as outlined in the proposal - namely, eliminating the off-chain Snapshot poll, creating a “Request for Comment” phase, and increasing the quorum for the second phase.
Consistent with several other community members’ comments, I think the RFC process should be longer than 3 days; my view is that it should be at least 7 days long. Having a week provides necessary time to become aware of each proposal and formulate potential comments. Less than a week risks rushing the commentary process.
This post was authored by Alana Levin, an investment partner at Variant. Variant is an investor in the UNI token. See disclosures.
Just for reference:
source: https://www.tally.xyz/gov/eip155:1:0x408ED6354d4973f66138C91495F2f2FCbd8724C3/voters
Snapshot voting should not be used for decision-making because a large amount of UNI cannot participate in Snapshot due to custody providers inability to vote off-chain. All governance decisions should be decided on-chain.
Hi! Fabien from Snapshot here. Do you know which custodian(s) wouldn't work with Snapshot? AFAIK most custodians support Snapshot voting through delegation, I know Coinbase or Fireblocks are used and Anchorage recently added a way to do delegation (need to activate on request). Which one I'm missing?
Do anyone know how long it takes for my coins pairs to be listed on the pool list they where confirmed index onto uniswap dot org pool. Will they show up on list to the public? I add these coins pairs a few weeks ago and they still not in pool search list!
( EAMIINFT / MATIC ) and ( BHOIINFT / MATIC ) and ( MATIC / BTC ) and ( MATIC / AHLRCMETA ) and ( MATIC / CRYPTO ) and ( MATIC / CHURCH ) all these coins pairs on Polygonscan network. I added them now how do they show up in pool all search or pool list under Polygon. Is it a time period wait or i have to program them onto available Uniswap list? Please give code I will tip with some of my above Matic pairs too ERC-20 tokens!
I support modifying the governance process as outlined in the proposal - namely, eliminating the off-chain Snapshot poll, creating a “Request for Comment” phase, and increasing the quorum for the second phase.
Consistent with several other community members’ comments, I think the RFC process should be longer than 3 days; my view is that it should be at least 7 days long. Having a week provides necessary time to become aware of each proposal and formulate potential comments. Less than a week risks rushing the commentary process.
I support modifying the governance process as outlined in the proposal - namely, eliminating the off-chain Snapshot poll, creating a “Request for Comment” phase, and increasing the quorum for the second phase.
Consistent with several other community members’ comments, I think the RFC process should be longer than 3 days; my view is that it should be at least 7 days long. Having a week provides necessary time to become aware of each proposal and formulate potential comments. Less than a week risks rushing the commentary process.
This post was authored by Alana Levin, an investment partner at Variant. Variant is an investor in the UNI token. See disclosures.
Just for reference:
source: https://www.tally.xyz/gov/eip155:1:0x408ED6354d4973f66138C91495F2f2FCbd8724C3/voters
From a voter's perspective this process is far more streamlined and preferable (two non-binding votes is repetitive imo). We (Blockchain at Berkeley) would signal support for this updated process.
I'd like to seek clarity on the min $UNI delegated to create the mentioned Snapshot polls. Just tried to create a snapshot proposal from my personal wallet and was told I need 1k uni minimum delegated. Want to be clear if the new [temp check] phase will retain this 1k $UNI requirement. Also would like to confirm that the proposed formalized off-chain final vote will maintain the same 2.5mm $UNI proposing requirement as the on-chain final vote.
From a voter's perspective this process is far more streamlined and preferable (two non-binding votes is repetitive imo). We (Blockchain at Berkeley) would signal support for this updated process.
I'd like to seek clarity on the min $UNI delegated to create the mentioned Snapshot polls. Just tried to create a snapshot proposal from my personal wallet and was told I need 1k uni minimum delegated. Want to be clear if the new [temp check] phase will retain this 1k $UNI requirement. Also would like to confirm that the proposed formalized off-chain final vote will maintain the same 2.5mm $UNI proposing requirement as the on-chain final vote.
I think lengthening the RFC could make sense - maybe to a 5 day minimum? That seems like a fair amount of time to allow active governance participants to read a proposal, put together some initial thoughts, feedback, and questions, and comment in the forums.
In terms of quorum for the new Temperature Check Phase (currently at 5M), I think increasing it makes sense in that it adds additional assurance that the proposer will spend time speaking to and rallying multiple delegates prior to the final governance vote.
Thank you, Devin, for getting the ball rolling here. We think many, ourselves included, thought the governance process was sub-optimal. Switching the temperature check to a 3-day RFC sounds like a good improvement. It might be nice to make that a week instead; however, we don't see a reason to delay the Snapshot Poll if the proposer believes they can rally the votes.
We do think it is worth considering to increase the Snapshot further than the proposed 5m. As @devenmatthews pointed out, 37 wallets meet the 2.5mm threshold. With that in mind, maybe we should set the quorum to 10m, or more? Ultimately it isn't super important since the poll is not codified and is only socially enforced.
Thank you, Devin, for getting the ball rolling here. We think many, ourselves included, thought the governance process was sub-optimal. Switching the temperature check to a 3-day RFC sounds like a good improvement. It might be nice to make that a week instead; however, we don't see a reason to delay the Snapshot Poll if the proposer believes they can rally the votes.
We do think it is worth considering to increase the Snapshot further than the proposed 5m. As @devenmatthews pointed out, 37 wallets meet the 2.5mm threshold. With that in mind, maybe we should set the quorum to 10m, or more? Ultimately it isn't super important since the poll is not codified and is only socially enforced.
As for the second point regarding a formalized off-chain governance process. Snapshot voting should not be used for decision-making because a large amount of UNI cannot participate in Snapshot due to custody providers inability to vote off-chain. All governance decisions should be decided on-chain.
Other Internet supports this simplification.
One note: when Teo posted the original version of this proposal, we had the following suggestion:
Other Internet supports this simplification.
One note: when Teo posted the original version of this proposal, we had the following suggestion:
more standardization around how to set up Snapshot polls would be helpful. Framing of “yes” and “no” votes could use particular attention (here are three different polls which each have different phrasings for yes and no votes — some do not show up in the UI properly). Using “no change” as a standard for no votes, at the very least, would be a reasonable starting place.
Still think that this would be useful language to add to a governance process update.
The current process has been enshrined in several third party apps like Boardroom. We’ll need to make a list of these projects and reach out to ensure the process documentation is correctly updated.
Lastly, not opposed to a 5 day RFC minimum. Not opposed to increased quorum.
Thanks for this! After experimenting with a couple different methods and helping a couple different teams submit proposals, we are in huge favor of this new proposed timeline. The RFC period is probably most important and may take over 3 days. The temp and consensus check seemed a bit redundant prior and this newer system will decrease voter fatigue.
Hi all,
Glad to see this in motion. I agree with @GFXlabs that a higher quorum for the Snapshot poll might be a good idea. Reaching quorum would then indicate that the proposal is either an absolute home run or that the proposer has done the leg work to get it in front of enough delegates to get buy-in from the community. 10m seems a reasonable number.
Hi all,
Glad to see this in motion. I agree with @GFXlabs that a higher quorum for the Snapshot poll might be a good idea. Reaching quorum would then indicate that the proposal is either an absolute home run or that the proposer has done the leg work to get it in front of enough delegates to get buy-in from the community. 10m seems a reasonable number.
I wanted to raise one more item here. While in general I'd like to avoid the scenario where the DAO must decide the best option out of several, it's reasonable to think that we'll run up against it at some point. Given a recent personal run-in with ranked-choice voting, I strongly believe that it's a superior method to first past the post voting (despite having lost the vote in question!). That said, it's not super intuitive to understand the implications of your vote in RCV and I'd like to avoid a situation where we're explaining it to stakeholders while a vote is happening.
It's not easy to envision a scenario where we're making such a choice given the DAO's current structural constraints, but I do think it's worth there being a bullet point in both the Phase 2: Temperature check section and the Proposed formalization of process changes to off-chain components of governance process section that indicate that in the event of a choice between several options, RCV will be the methodology used.
These are good questions.
I think lengthening the RFC could make sense - maybe to a 5 day minimum? That seems like a fair amount of time to allow active governance participants to read a proposal, put together some initial thoughts, feedback, and questions, and comment in the forums.
In terms of quorum for the new Temperature Check Phase (currently at 5M), I think increasing it makes sense in that it adds additional assurance that the proposer will spend time speaking to and rallying multiple delegates prior to the final governance vote.
Thank you, Devin, for getting the ball rolling here. We think many, ourselves included, thought the governance process was sub-optimal. Switching the temperature check to a 3-day RFC sounds like a good improvement. It might be nice to make that a week instead; however, we don't see a reason to delay the Snapshot Poll if the proposer believes they can rally the votes.
We do think it is worth considering to increase the Snapshot further than the proposed 5m. As @devenmatthews pointed out, 37 wallets meet the 2.5mm threshold. With that in mind, maybe we should set the quorum to 10m, or more? Ultimately it isn't super important since the poll is not codified and is only socially enforced.
Thank you, Devin, for getting the ball rolling here. We think many, ourselves included, thought the governance process was sub-optimal. Switching the temperature check to a 3-day RFC sounds like a good improvement. It might be nice to make that a week instead; however, we don't see a reason to delay the Snapshot Poll if the proposer believes they can rally the votes.
We do think it is worth considering to increase the Snapshot further than the proposed 5m. As @devenmatthews pointed out, 37 wallets meet the 2.5mm threshold. With that in mind, maybe we should set the quorum to 10m, or more? Ultimately it isn't super important since the poll is not codified and is only socially enforced.
As for the second point regarding a formalized off-chain governance process. Snapshot voting should not be used for decision-making because a large amount of UNI cannot participate in Snapshot due to custody providers inability to vote off-chain. All governance decisions should be decided on-chain.
Other Internet supports this simplification.
One note: when Teo posted the original version of this proposal, we had the following suggestion:
Other Internet supports this simplification.
One note: when Teo posted the original version of this proposal, we had the following suggestion:
more standardization around how to set up Snapshot polls would be helpful. Framing of “yes” and “no” votes could use particular attention (here are three different polls which each have different phrasings for yes and no votes — some do not show up in the UI properly). Using “no change” as a standard for no votes, at the very least, would be a reasonable starting place.
Still think that this would be useful language to add to a governance process update.
The current process has been enshrined in several third party apps like Boardroom. We’ll need to make a list of these projects and reach out to ensure the process documentation is correctly updated.
Lastly, not opposed to a 5 day RFC minimum. Not opposed to increased quorum.
Thanks for this! After experimenting with a couple different methods and helping a couple different teams submit proposals, we are in huge favor of this new proposed timeline. The RFC period is probably most important and may take over 3 days. The temp and consensus check seemed a bit redundant prior and this newer system will decrease voter fatigue.
Hi all,
Glad to see this in motion. I agree with @GFXlabs that a higher quorum for the Snapshot poll might be a good idea. Reaching quorum would then indicate that the proposal is either an absolute home run or that the proposer has done the leg work to get it in front of enough delegates to get buy-in from the community. 10m seems a reasonable number.
Hi all,
Glad to see this in motion. I agree with @GFXlabs that a higher quorum for the Snapshot poll might be a good idea. Reaching quorum would then indicate that the proposal is either an absolute home run or that the proposer has done the leg work to get it in front of enough delegates to get buy-in from the community. 10m seems a reasonable number.
I wanted to raise one more item here. While in general I'd like to avoid the scenario where the DAO must decide the best option out of several, it's reasonable to think that we'll run up against it at some point. Given a recent personal run-in with ranked-choice voting, I strongly believe that it's a superior method to first past the post voting (despite having lost the vote in question!). That said, it's not super intuitive to understand the implications of your vote in RCV and I'd like to avoid a situation where we're explaining it to stakeholders while a vote is happening.
It's not easy to envision a scenario where we're making such a choice given the DAO's current structural constraints, but I do think it's worth there being a bullet point in both the Phase 2: Temperature check section and the Proposed formalization of process changes to off-chain components of governance process section that indicate that in the event of a choice between several options, RCV will be the methodology used.
These are good questions.
These are good questions.
I've confirmed this is possible with the Snapshot team - we can leverage subspace functionality to create two kinds of polls with two different delegation/self-delegation requirements.
What do you think?
These are good questions.
I've confirmed this is possible with the Snapshot team - we can leverage subspace functionality to create two kinds of polls with two different delegation/self-delegation requirements.
What do you think?
