Uniswap governance receives large interest from L1 & L2 projects (Base, Moonbeam, Linea, etc.) looking to deploy Uniswap v3 on their respective networks. To ensure accountability, transparency, and security within these deployments, Uniswap Labs drafted a deployment proposal template for future cross-chain deployment proposals.
The template was refined further by Toby Shorin from Other Internet in his post, “Proposal Template 2.0 - Upgrade for Deployments & Agreements.” In the new template, a “KPI & Success Criteria” section was added to better equip the community when deciding whether a deployment might be beneficial for Uniswap.
1. Lack of Uniform Proposal Format and Guideline
As Toby noted in his forum post, the initial deployment template was never formally approved by the Uniswap community making it difficult to enforce. Today, cross-chain deployment proposals are posted in various formats, with many lacking key sections such as the “KPI & Success Criteria”, which helps the decision making process at Uniswap governance.
2. The Proposal is Long and Complex
Cross-chain deployments are technical by nature, making it difficult for non-technical Uniswap governance participants to understand the complexities of their implementation. Moreover, these proposals are often long, use technical language, and lack a TL;DR for the general audience.
3. Many Proposals Receive Low Engagement
Deployment proposals often receive low engagement, comments, and questions on the forum. For example, a recent proposal to deploy v3 on Linea received zero comments on the forum. Similarly, a proposal from Filecoin Virtual Machine (FVM) failed to receive any community feedback. While there can be multiple ways to share feedback including by private message, posting on the forum is crucial as it helps with documentation and makes it easily accessible for the community.
1. Enforce and/or Encourage Uniform Proposal and Guideline
Deployment proposals should follow a uniform proposal framework and guideline. Authors must fill all relevant proposal sections, especially the “required” fields (even if it means writing N/A to show they are missing). This ensures that Uniswap governance can easily distinguish comprehensive applications from suboptimal proposals.
Any additional information can be included in the supplementary section after the required section of the proposal.
It is the AC’s role to point out if any required and/or encouraged parts are missing thereby raising the issue to Uniswap Governance.
2. Require TL;DR Section
Similar to the above point, proposals should be required or at least encouraged to include a TL;DR for the readers. By including a short summary of the proposal this ensures even the most complex proposal is understood by a non-technical audience.
3. Feedback from the Accountability Committee
While in theory Uniswap governance proposals should receive comments and questions from the community (especially delegates) before going to a vote, deployment proposals are struggling to do so. Therefore, the role of the AC is to post questions and comments on all deployment proposals. Regardless if the proposal meets all requirements, the AC is required to post questions and comments to not only increase the accountability and transparency for Uniswap governance but also to encourage engagement by the wider Uniswap community.
In addition, cross-chain proposal authors should be required to present to the AC OR on community governance calls attended by members of the AC to ask and comment and write down some of the interactions on the forum related to such cross-chain proposals.
Role of the Accountability Committee
The Accountability Committee comprises members with diverse backgrounds, including governance and technical expertise. Any committee member who has a clear conflict of interest (e.g. proposal author), should not be involved. Instead, it is recommended to have at least one member with technical knowledge and another member from a different area of expertise to review and provide input on proposals. They will be tasked with asking questions and comments on various aspects, such as the proposal’s guidelines and its potential benefits or drawbacks to the Uniswap community.
This entire process will be conducted in a timely manner to ensure that Uniswap governance receives a basic assessment of the proposals’ accountability and transparency levels from the Accountability Committee.
Example of the Accountability Committee Workflow
A hypothetical ABC chain is looking to deploy Uniswap v3 on their chain. Below are two potential scenarios and their flows:
A ABC Chain makes a proposal without discussing with the Accountability Committee
1.The Accountability Committee member posts that the proposal is under review by the Accountability Committee.
At least one member with technical knowledge and another member from a different area of expertise will be assigned to review and provide input on the proposal including whether the proposal is missing “required” or recommended parts of the proposal.
Currently, as the Accountability Committee has no enforcement mandate, the proposal will go live even if the proposal is missing “required” or recommended parts of the proposal. However, the Accountability Committee’s feedback can be sufficient to help Uniswap governance assess such proposals. If a vote is pushed and still is missing “required” or recommended parts of the proposal, a team member will inform the team and/or comment on the public forums.
B. ABC Chain discusses with the Accountability Committee and makes a proposal
1.The Accountability Committee should note the interaction with ABC Chain, and ideally it should be a publicly accessible channel (for example, presenting about their chain in a public governance call) where the Accountability Committee members can attend and take notes and ask questions.
After the proposal is posted, the Accountability Committee will post that the committee has been in discussions with the proposed chain, and note some of the key interactions. Thereafter, the Accountability Committee will post that the proposal is under review.
Similar to Scenario A, at least one member with technical knowledge and another member from a different area of expertise will be assigned to review and provide input on the proposal including whether the proposal is missing “required” or recommended parts of the proposal.
Again, similar to Scenario A, as the Accountability Committee has no enforcement mandate, the proposal will go live even if the proposal is missing “required” or recommended parts of the proposal. However, the Accountability Committee’s feedback should still help Uniswap governance assess such proposals. If a vote is pushed and still is missing “required” or recommended parts of the proposal, a team member will inform the team and/or comment on the public forums.