<div><a href="https://global.discourse-cdn.com/business6/uploads/uniswap1/original/2X/e/e8dcc5fa9ae5366a73cc950e074abc5639300d60.jpeg"><div>
UNI_crosschain_gov1440×880 43.2 KB
</div></a></div>
<h3>
<a name="introduction-1" href="#introduction-1"></a>Introduction</h3>
A major objective for Uniswap Governance this year is <a href="https://uniswap.org/blog/multichain-uniswap">deploying Uniswap v3 on a broad set of high-quality EVM chains 43</a>. 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.
Contents
<ol>
<li>Current State of Uniswap Cross-Chain Governance</li>
<li>What’s Next: Vendor Evaluation, Technical Analysis, Request for Community Feedback</li>
</ol>
Authors
Laura Lotti &amp; Toby Shorin (Other Internet) 
Image by Yitong Zhong (VectorDAO)
<hr />
<h1>
<a name="current-state-of-uniswap-cross-chain-governance-2" href="#current-state-of-uniswap-cross-chain-governance-2"></a>Current State of Uniswap Cross-Chain Governance</h1>
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.
<ul>
<li>Polygon and Optimism use the native bridges developed by the respective teams.</li>
<li>Arbitrum also uses its native bridge (currently not functioning).</li>
<li>Celo uses an implementation of <a href="https://docs.celo.org/celo-codebase/protocol/optics">Optics 14</a>.</li>
<li>Moonbeam and Gnosis Chain use Nomad, another forked version of Optics code.</li>
</ul>
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.
<h2>
<a name="general-solution-criteria-3" href="#general-solution-criteria-3"></a>General Solution Criteria</h2>
Scaling Uniswap cross-chain governance is a multifaceted problem. Solving it in a “feature-complete” way would require several pieces of work.
<ol>
<li>The implementation of a single ABI for and standardized call data format for creating proposals for multiple chains.</li>
<li>The ability for proposers to deploy their proposal code to selected or all chains in one proposal.</li>
<li>Updated guides and documentation for proposers.</li>
<li>A graphical user interface for delegates and proposers, reflecting the current state of proposals on each chain.</li>
</ol>
Conversely, what should be “out of scope” for such an initiative?
 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.
 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.
<hr />
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.
<h2>
<a name="vendor-evaluation-process-technical-analysis-4" href="#vendor-evaluation-process-technical-analysis-4"></a>Vendor Evaluation Process &amp; Technical Analysis</h2>
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.
<h3>
<a name="process-to-date-next-steps-5" href="#process-to-date-next-steps-5"></a>Process To Date &amp; Next Steps</h3>
Where we’ve been
<ul>
<li>We first identified a need for a universal governance bridge following conversations with recent V3 deployers Gnosis Chain, Moonbeam, and Celo.</li>
<li>We circulated a short version of this post to several other Uniswap delegates to ascertain support.</li>
<li>We set up initial exploratory conversations with Abacus, Nomad, and Axelar to validate the technical feasibility of the concept.</li>
</ul>
Where we are now
<ul>
<li>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.</li>
</ul>
Next steps
<ul>
<li>We will continue to hold conversations with potential vendors in the next 2 weeks.</li>
<li>Following the conclusion of these calls, we’ll post the results of our conversations in a competitive analysis table and make a recommendation.</li>
</ul>
<h3>
<a name="provider-evaluation-criteria-6" href="#provider-evaluation-criteria-6"></a>Provider evaluation criteria</h3>
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 <a href="https://gov.osmosis.zone/discussion/3721-draft-bridge-service-provider-rfp">similar list of questions 17</a>.)
Technical Features
<ul>
<li>Security 
What is the security model of the bridge? What compromises does it make?
</li>
<li>Ease of use 
How developer friendly is the solution? What will the experience be for delegates?
</li>
<li>Generalizable across all chains and L2s 
Does the bridge work across all chains?
</li>
<li>Costs (gas) 
How gas-costly is a cross-chain proposal?
</li>
<li>Maintenance 
What is required to maintain the instance? Who will maintain the Uniswap implementation? For how long?
</li>
</ul>
Team &amp; Contractual Details
<ul>
<li>Reputation 
What is the reputation of the team? What other projects are using the technology?
</li>
<li>Roadmap 
What is the product roadmap? Can Uniswap influence the roadmap and features?
</li>
<li>Developer Support 
What level of customer support will be provided?
</li>
</ul>
<h3>
<a name="tradeoffs-considerations-of-ugm-7" href="#tradeoffs-considerations-of-ugm-7"></a>Tradeoffs &amp; Considerations of UGM</h3>
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.
<h2>
<a name="community-involvement-8" href="#community-involvement-8"></a>Community Involvement</h2>
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 <a href="http://twitter.com/otherinternet__">twitter.com/otherinternet__ 15</a> if you’d like to help.
<h3>
<a name="advisors-consulted-9" href="#advisors-consulted-9"></a>Advisors Consulted
</h3>
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)

RFC: Uniswap Universal Governance Module

Got something to add?