Cross-chain Deployment Guide

Uniswap v3 was deployed on Ethereum mainnet in May 2021 and has since been deployed on multiple additional chains, including Arbitrum, Optimism, Polygon, and Celo. Additional chain deployments have been approved to go live soon, or are currently through the governance process.

The Uniswap Foundation is excited to support the deployment of Uniswap v3 onto other L2s and blockchains by providing resources below to facilitate the governance and deployment process.

Note that a successful governance proposal here only guarantees the deployment of the Univ3 protocol on other chains. It does not guarantee the integration of a cross-chain deployment into any front-end interface.

Governance Proposal

First, write the proposal. There are a number of relevant considerations to take into account for cross-chain proposals. To ensure these considerations are covered, please follow the template provided here, written by Other Internet with support from other community members. A great example to review is the proposal to deploy v3 on Celo (here).

Key components of the proposal to focus on include:

  • Bridge security: The bridge which will pass governance messages to the chain’s deployment, in addition to its security assumptions and implementation details, are important to identify in your proposal.
  • Additional Use Grant language: The language for the Additional Use Grant to the Uniswap BSL (don’t just copy and paste language from previous proposals - ensure to update it for your team and chain).

We also recommend deploying Uniswap v3 on a testnet prior to or while going through the governance process. You can review steps to deploy v3 in the section below. Once v3 is deployed, include links to the smart contracts in your proposal for community review.

Governance Process

The governance process can be reviewed in detail here.

At a high level, the process is as follows:

  1. Request for Comment (RFC). Minimum 7 days. Post your proposal on the governance forum to allow the community to review and ask questions. Keep the proposal in the forum, responding to questions and iterating upon the proposal based on feedback for at least 7 days prior to moving to the next phase.

  2. Temperature Check. 5 days. Create an off-chain Snapshot Poll to ensure community sentiment is in favor of your proposal. A majority of votes in favor, with a quorum of 10M UNI votes, is required to move forward to the last phase.

  3. Governance Vote. 11 days (7 day voting period). Write the calldata that will create the Additional Use Grant and associate it with the ENS subdomain v3-core-license-grants.uniswap.eth. You can review how to put together the calldata for this kind of proposal here or here. You can see Celo’s successfully executed transaction as an example here and here (check the “Executable code” section at the bottom).

You are required to have 2.5M votes delegated to you in order to post the proposal – if you need assistance, reach out to a Uniswap delegate (here) or the Uniswap Foundation directly to assist. A majority of votes in favor, with a quorum of 40M UNI votes, is required for the vote to pass.


Once the final phase has been completed and the proposal has passed, your team can deploy Uniswap v3 on your chain!

A Github has been put together summarizing the core steps for deploying Uniswap v3 on another chain. The Github is here. It includes links to the v3 deployment script, as well as steps for creating a subgraph, token list, and

Beware of missteps made in previous deployments, and double check questions with the Uniswap Foundation if necessary.

One example of an error which was previously made is during the Arbitrum deployment. The Uniswap Factory was deployed to an unaliased address rather than an aliased address, requiring subsequent correction via another round of governance. This is an issue specific to Arbitrum - in other words, you likely do not need to deploy to an aliased address unless your chain leverages address aliasing like the Arbitrum chain - however, this is a good example of the kinds of errors which can be made during the deployment process without clear communication. Issue is further explained here.

As mentioned above, proposers should note that a successful governance proposal here only guarantees the deployment of the Univ3 protocol on other chains. It does not guarantee the integration of a cross-chain deployment into any front-end interface.

Over time, we are happy to update this post with additional helpful details. If you think more should be added to this guide, post it in the comments!


Thanks for the updated deployment proposal process Devin!

I believe most deployment proposals did not deploy on testnet beforehand- though I think this is good guidance. This minimizes the time between proposal->deployment.

A few questions about the deployment process I’d like to raise

  • Do deployment proposals become a thing of the past if the v3 BSL is not renewed?

    • I imagine not, as Uniswap governance will need to recognize an official deployment on each chain. If an official deployment is not recognized, Uniswap governance will not have guidance over which deployment to control using the governance bridge.
  • Should license grants be paired with conditionals?

    • Many other deployments promise liquidity mining/grants programs in their proposals, yet there is no oversight to whether these are seen through; Is the community okay treating these as nice-to-have promises or should these conditions be enforced somehow (legally as a license exemption conditional is one way, but not ideal).
  • How should non-EVM deployments of Uniswap v3 be treated differently?

    • There is currently a conversation about this in the StarkNet deployment proposal thread.
    • Should these be treated on a case by case basis or should an alternative framework be developed? This conversation becomes difficult and nuanced as we discuss the deployments on EVM-like chains (See vitalik’s post on types of zkEVMs)

I appreciate this topic being re-visited as there has been an influx of deployment proposals lately. It’s important to keep the community guidelines around this cohesive to not waste delegates’ time.