RFC: Uniswap Universal Governance Module


A major objective for Uniswap Governance this year is deploying Uniswap v3 on a broad set of high-quality EVM chains. This document explains why the lack of scalable cross-chain governance is currently an impediment to this goal, and proposes we select a bridge technology partner to build a solution. We outline our process for evaluating a vendor and next steps.


  1. Current State of Uniswap Cross-Chain Governance
  2. What’s Next: Vendor Evaluation, Technical Analysis, Request for Community Feedback


Laura Lotti & Toby Shorin (Other Internet)
Image by Yitong Zhong (VectorDAO)

Current State of Uniswap Cross-Chain Governance

Uniswap V3 is deployed to Polygon, Arbitrum, and Optimism, with Celo, Moonbeam, and Gnosis Chain deploying soon. To enable Ethereum’s Uniswap deployment to govern all instances, each chain must have a messaging bridge for propagating governance decisions from Ethereum L1 to the remote chain’s instance of Uniswap V3 (“cross-chain governance”). Of these 6 deployments, there are 5 different messaging bridges used to execute governance decisions on each of the chains.

  • Polygon and Optimism use the native bridges developed by the respective teams.
  • Arbitrum also uses its native bridge (currently not functioning).
  • Celo uses an implementation of Optics.
  • Moonbeam and Gnosis Chain use Nomad, another forked version of Optics code.

What this currently means is that each new proposal containing protocol parameter changes must be rewritten for each separate bridge and project, requiring custom code and separate votes, and potentially multiple proposal processes. In short, managing governance will become cost-prohibitive and complex as Uniswap scales.

While the volume of governance that pertains to cross-chain parameters is still low compared to protocols with more on-chain parameters, we anticipate that governance activity will increase in the future. Notably, the addition of further fee tiers specific to different chains, or the activation of pool-specific fee switches, would likely bring an increase in proposal volume.

General Solution Criteria

Scaling Uniswap cross-chain governance is a multifaceted problem. Solving it in a “feature-complete” way would require several pieces of work.

  1. The implementation of a single ABI for and standardized call data format for creating proposals for multiple chains.
  2. The ability for proposers to deploy their proposal code to selected or all chains in one proposal.
  3. Updated guides and documentation for proposers.
  4. A graphical user interface for delegates and proposers, reflecting the current state of proposals on each chain.

Conversely, what should be “out of scope” for such an initiative?

:warning: Bridging UNI is out of scope. We are only concerned with bridging governance related contract calls, and for the purposes of this initiative are not considering bridged UNI tokens. Uniswap’s relatively small set of on-chain parameters means reduced attack surface area, and we prefer to keep it that way.

:construction: L2 voting is out of scope. The costs of this approach exceed the benefits; Uniswap’s unequal distribution of voting power means that votes are largely contingent on whales and major delegates, even if we make voting for everyone cheaper.

With these criteria in mind, we felt that an initial project should at least cover items 1, 2, and 3 above.

We call this the Universal Governance Module (UGM). Below, we explain our process for evaluating potential software vendors to implement the UGM.

Vendor Evaluation Process & Technical Analysis

Uniswap governance proposal #7 saw Flipside Analytics propose itself as a premiere service provider to Uniswap Protocol, in a move that caused concern and ultimately the retraction of the proposal. University blockchain clubs are often “used” by protocol diplomats and service providers for their delegated voting power without taking an opinionated stance.

To avoid these failures, we see the need for an independent party like Other Internet to evaluate vendors and nominate one. At the same time, we also want to ensure the process happens with the community’s awareness and acknowledgment.

Below we list the steps we’ve taken so far and where we are at in the process, along with our evaluation criteria for potential bridge partners.

Process To Date & Next Steps

Where we’ve been

  • We first identified a need for a universal governance bridge following conversations with recent V3 deployers Gnosis Chain, Moonbeam, and Celo.
  • We circulated a short version of this post to several other Uniswap delegates to ascertain support.
  • We set up initial exploratory conversations with Abacus, Nomad, and Axelar to validate the technical feasibility of the concept.

Where we are now

  • In this post, we are inviting the community to comment, and suggest additional evaluation criteria or vendors we should be reviewing. Please send us your recommendations within 7 days from this post to allow us to reach out to teams and complete our evaluation in a timely manner.

Next steps

  • We will continue to hold conversations with potential vendors in the next 2 weeks.
  • Following the conclusion of these calls, we’ll post the results of our conversations in a competitive analysis table and make a recommendation.

Provider evaluation criteria

When evaluating potential bridge providers, several considerations must be taken into account. (Our thanks to Stevie Woofwoof from Osmosis, from whom we’ve adapted a similar list of questions.)

Technical Features

  • Security
    What is the security model of the bridge? What compromises does it make?
  • Ease of use
    How developer friendly is the solution? What will the experience be for delegates?
  • Generalizable across all chains and L2s
    Does the bridge work across all chains?
  • Costs (gas)
    How gas-costly is a cross-chain proposal?
  • Maintenance
    What is required to maintain the instance? Who will maintain the Uniswap implementation? For how long?

Team & Contractual Details

  • Reputation
    What is the reputation of the team? What other projects are using the technology?
  • Roadmap
    What is the product roadmap? Can Uniswap influence the roadmap and features?
  • Developer Support
    What level of customer support will be provided?

Tradeoffs & Considerations of UGM

Vendor Lock-in

One possible cause for concern is that enshrining any single bridge provider will lead to vendor lock-in. Why is vendor lock-in problematic? If bridging UNI tokens were planned, the possibility of bridge fees being turned on might be a concern. But there is no plan to do so today.

Cryptocurrency discourse often advocates against “platform lock-in,” and such a perspective weights against crowning any single technology provider. But governance UX is no less important than the UX of the native swap application. Were Uniswap Labs itself engaged with governance, they would likely build, acquire, or solicit a bridge provider to develop a universal solution. In their absence, we see it as within our mandate to do the same.

Finally, Uniswap’s importance in the crypto ecosystem and its well-known brand give it significant leverage. Willingness to select a single vendor means we are in a strong position to solicit additional value-add services and long-term arrangements with any given partner.

L2 Native Bridge Security

Using the native bridges provided by L2s is considered preferable to alternative bridge providers, because A) their security is tied to that of the underlying chain and B) the incentive alignment of L2 teams’ reputation being staked on their chains’ security is thought to lead to better security.

On the other hand, most new EVM chains have not built their own bridging solution (Solana, Moonbeam, etc) and are already relying on third party bridges. This means we will still see fragmentation of governance bridges without a generalized solution, increasing the complexity of multichain decision making going forward. We believe this weighs toward the use of a single provider.

Community Involvement

At this point in the process, we’d like to get overall feedback from the community on this issue, and any recommendations for additional bridge evaluation criteria we should be using. Please send us your recommendations within 7 days from this post to allow us to reach out to teams and complete our evaluation in a timely manner.

If you are interested in providing additional technical expertise to our review process, we’re happy to have more collaborators and reviewers on the comparison work. Please reply to this thread or send us a DM at twitter.com/otherinternet__ if you’d like to help.

Advisors Consulted

Sam Hart, Funding Program at Interchain Foundation (Other Internet)
Raf Solari, CTO at Tally (Independent Technical Advisor)
Arr00, Engineer at Compound (Independent Technical Advisor)
Getty Hill, Co-founder at GFX Labs (Uniswap Delegate)
Robert Leshner, CEO at Compound Labs (Uniswap Delegate)
Medha Kothari, Analyst, and Jesse Walden, Partner at Variant Fund (Uniswap Delegate, Investor)
Larry Sukernik, Co-founder at Reverie (Uniswap Delegate)
Erin Koen, Governance Lead at Avant Garde Finance (Uniswap Delegate)


Thanks @tobyshorin. This is an important initiative. Uniswap would certainly benefit from a more standardized solution for cross-chain deployments. And Other Internet (being an excellent steward of the protocol) is well suited to help administer a process like this.

A few thoughts on the proposed structure.

1) Timing. Selecting a bridge provider is an important decision for Uniswap. It’s critical that we allow providers enough time to review the RFP and submit high quality bids. While we appreciate the need for efficiency, the proposed timeline (2 weeks) is realistically too short to accomplish this goal. Let’s align on the overall structure / criteria first and then we can set a timeline that makes sense.

2) Tokenholder consent. While it makes sense for Other Internet to help administer the process, the ultimate decision should be made by the community. In our view a structure whereby: a) Open Internet helps coordinate bids / runs the process; and b) the community selects the ultimate winner strikes the right balance overall. This will ensure that the process remains organized and efficient but also retains broad-based token holder consent.

3) Compound precedent. A useful precedent here is Compound’s recent RFP process. In that case, Reverie ran a competitive process to hire a security auditor for the protocol. The process produced multiple high-quality bids from top audit firms, including Open Zeppelin, Trail of Bits, ChainSecurity, and more. Reverie helped to shepherd the process and allowed the community to evaluate the bids over the course of several weeks (including over community calls, forum posts, etc). After weighing the various proposals, the community collectively voted and picked a winner. Though it had its challenges, this community-led approach led to fair and competitive process that served Compound well in the end. We think something similar makes sense here.

Happy to help coordinate and support.



Thanks for this thoughtful RFC. This is a heady issue, and our opinion at AGF is that is valuable to have one party serving as the fact finders and filter through which we can evaluate potential service providers. There’s still lots of room for community involvement; if anyone has particular technical concerns that a potential provider should answer, they can and certainly should speak up here or reach out to Other Internet.

I anticipate more forum participation after the next post where a comparison table and recommendation has been presented. Given that this is a highly technical RFQ that is sort of defining a category of service in flight, concrete examples of what will be provided and the benefits that will be conferred will be useful for those of us who are wrapping our heads around what the implications of this engagement might be.

Ultimately, the community will express its view on whether Other Internet has recommended the right candidate by vote; if the vote is successful we’ve likely saved time and money for many stakeholders (and arguably candidates). If it is not, we have more information about what we’re looking for in this vendor and can be more specific in our asks the next time around.


Hi all, I’m providing a brief update on where we are with the UGM. As outlined in the original post, we we currently in the process of soliciting formal proposals from multiple bridge technology providers. Once we’ve collected all of them, we’ll post the proposals here with a clear comparison, our analysis and recommendation of a bridge provider, and next steps.