Uniswap

Updates to original RFC, which can be found here

On November 21st, we posted a Request for Comment on a series of proposed changes to the Uniswap community governance process. Thank you to everyone who has provided their comments! Based on community feedback and discussion, we are making some adjustments to our proposal. We will keep this proposal outstanding until next Wednesday December 14th, at which point we will post a Snapshot poll on the changes.

The changes to the RFC based on feedback are as follows:

Revisions and updates to RFC

1. Increase the new “Request for Comment” process to be a minimum of 7 days rather than our originally proposed 3 days. We agree with Alana Levin, GFX Labs, and others that a minimum of 1 week ensures that the community will have adequate time to digest each proposal, ask questions, and provide feedback.
2. Increase the quorum for the new Temperature Check, the remaining off-chain Snapshot poll, to 10M UNI rather than the originally proposed 5M UNI. As pointed out by Deven Matthews from Blockchain at Berkeley, 37 delegates meet the 2.5mm threshold – proposers would only need to garner support from 2 of these delegates to move to the last governance vote with a 5M quorum. Increasing quorum to 10M UNI increases the effectiveness of this phase as a signal of community support.
3. We highlight two suggestion from Toby from Other Internet to 1) standardize Snapshot language, particularly by formalizing the use of “No change” rather than other more biased language in Snapshot polls, and 2) reach out to popular governance platforms where the governance process is listed to update it, if the vote passes.
4. We are now planning to post a Snapshot Poll to vote on Wednesday, December 14th. The voting parameters will be 7 days and a 40M UNI quorum.

In addition to the above changes, we also pose the following question to the community. We originally proposed that changes to the off-chain components of the community governance process be votes on through an off-chain vote on Snapshot. GFX Labs brought up the point that custodians do not allow voting off-chain - which means many voters may not be able to participate in those votes. Should these changes be voted on on- or off-chain? Particularly if you keep your UNI at a custodian, please opine!

Below, we provide an updated version of our original post.

TL;DR

• 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:

1. 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. We also believe two off-chain votes introduces unnecessary friction.
2. Increase quorum for the remaining off-chain Snapshot poll in the second phase to 10M UNI. The purpose of this off-chain vote is to gauge community sentiment prior to the governance vote. We believe the 10 million 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 the off-chain components of the community governance process, like the changes discussed in this proposal. As mentioned above, we are now welcoming feedback from the community on whether these changes should be voted on through an on- or off-chain vote. If you keep your UNI at a custodian, opine below!

Summary

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.

1297×842 65.2 KB

Current Process

A detailed outline of the current process can be found here.

1. Temperature Check: A temperature check is accompanied by a 3-day snapshot poll that requires a majority vote of 25K UNI yes-vote threshold.
2. Consensus Check: A consensus check is accompanied by a 5-day snapshot poll that requires a majority vote of 50K UNI yes-vote threshold.
3. Governance Proposal: The on-chain proposal and vote is the final phase of the governance process. The proposer must have a minimum of 2.5M UNI delegated to their address.

Proposed changes to community governance process

Phase 1: Request for Comment

• Rename: Temperature Check → Request for Comment
• Removal of Snapshot off-chain vote requirement
• A minimum of 7 days before moving forward

We believe the first phase of the governance process should allow the community to digest a proposal, comment, and ask questions – and not require going through the friction of one of two off-chain votes. The RFC Phase should last for at least 7 days to give the community ample time to formulate opinions on the proposal and provide feedback.

Phase 2: Temperature Check

• Increase the required quorum from 50K to 10M UNI

For this phase to better serve as a signaling tool, we suggest increasing the Snapshot poll yes-vote threshold to 10 million UNI. This threshold should be high enough to prevent lower quality proposals from moving to the final phase, while being low enough for higher quality proposals to garner enough support and move on to the final phase.

As suggested by Toby, we also strongly suggest the standard usage of a “No change” option in these Snapshot polls.

Phase 3: On-chain Governance Vote

• No changes

Proposed formalization of process changes to off-chain components of governance process

As mentioned above, we are looking for more community feedback on this topic

In her original post on the community governance process, Ashleigh states “On-chain voting is not necessary to make updates to off-chain processes.” An on-chain vote is unnecessary and requires users to pay gas, so should not be required for off-chain process changes. However, we do believe that community support and acceptance is important for process changes to have legitimacy. We thus originally proposed that changes to off-chain processes be voted on through off-chain votes on Snapshot with a 7-day voting period and 40M UNI quorum (original RFC here).

However, GFX Labs made the point that custodians do not allow UNI holders to vote off-chain, which may mean some UNI is precluded from voting on those changes. We would like more community feedback on whether these kinds of changes should be voted on on- or off-chain. Particularly if you keep your UNI at a custodian, please opine!

Conclusion and Next Steps

If no new serious changes to the proposal are required, we plan to post a Snapshot Poll on Wednesday, December 14th for the community to vote on these changes. If the Snapshot receives a quorum of 40M UNI votes, the community is indicating they are in favor of these changes.

The UF will update relevant documentation on the forum and work with other platforms where the Uniswap governance process is defined to make updates as well.

Hi everyone,

We wanted to layer onto what Devin was referencing a bit. Historically, polling has been an important piece of the governance process at Uniswap. However, because the polling is off-chain, it isn’t a required step of the governance process and is only socially enforced. For example, GFX Labs could instantly make an on-chain governance proposal, and so long as it reached the required 40m votes in favor, it would execute. We wouldn’t do that because it’s not socially acceptable, and we don’t want to damage our reputation, but it’s best to unambiguously codify what are and are not rules when possible.

Additionally, we’re aware of several funds that utilize custodians and thus cannot participate in off-chain votes such as Snapshot.

In conversation with the Foundation, we proposed the idea of bringing polling on-chain, making polling a requirement to the governance process, and enabling all parties to participate in votes. Effectively, this would be a junior and senior governance structure.

The junior governor would have its own proposal requirements and could feature a lower proposal threshold and quorum threshold. Upon success, the proposal could be passed onto the senior governor, likely requiring a higher quorum threshold to be executed.

In addition to the benefits already listed above, there would be a third primary benefit. This setup could be used to lower the proposal threshold significantly, making governance more accessible, while maintaining the security of the DAO. For example, the proposal threshold for the junior governor contract could be set to 100k and have a quorum of 10m. Improving upon the existing 2.5m threshold. However, only a proposal that achieves a 10m quorum would proceed to the senior governor, where the execution would occur if it reached the full 40m.

For those who are familiar with Community Autonomous Proposals (CAPs), which allow individuals without the necessary votes to make miniature-like proposals, this system would be a massive improvement. CAPs were unsuccessful at gaining traction because they require votes to be delegated, which is unrealistic when votes cannot be relegated.

If this is something voters are interested in seeing, we could formalize the structure and apply for a grant to develop and implement the new smart contracts.

It would be helpful if you could explain why an on-chain polling requirement is beneficial. For instance, the ability to go straight to an on-chain proposal can cut down on time, and if it passes, what would be the problem with there being no prior poll? It kind of seems to add more complexity as well as potentially more surface area for attacks.

To best answer this question, lets clarify the purpose of polling in the governance process. Plenty of DAOs don’t utilize polling and function perfectly fine. When Uniswap Labs launched UNI and introduced the DAO they proposed a governance framework that consisted of a forum post, temperature check, consensus check, and on-chain vote. Only the final step is functionally important to the DAO; the first three exist to give the proposer a framework to gather support and feedback on their proposal. The framework allows forum posts to start as ideas and progress into implementation. The framework does not prevent proposers from creating on-chain proposals which skip the traditional steps.

If UNI holders want to adjust the framework to guarantee voters have time to review proposals before they progress to an implementation vote, then the protocol should codify the requirement on-chain.

In addition to guaranteeing time to review the proposal before implementation, there are two other benefits. First, by implementing the proposed junior governor setup, the number of possible proposers could increase significantly because it effectively lowers the proposal threshold while maintaining the same quorum requirement. Second, it doesn’t put the protocol and its voters in the position of being reliant on Snapshot.