[Temperature Check] - Deploy Uniswap V2 on all chains with V3

8/25/23 - Snapshot poll here
9/12/23 - On-chain vote here


  • The only canonical deployment of Uniswap V2 is on Ethereum mainnet.
  • There is demand for V2-style AMMs on non-Ethereum chains and many V2 forks have been deployed with varying degrees of modification.
  • To the extent that these forks have been modified, they may prove unsafe for users.
  • To the extent that these forks have liquidity, that liquidity could likely have accrued to Uniswap V2.
  • The combination of Uniswap V2 and Uniswap V3 can often provide better execution for small-volume swappers via the Universal Router.

When Uniswap V3’s Business Source License expired and the code’s license transitioned to GPL, the DAO created a process by which it would declare canonical deployments of the contracts. This process serves to identify instances of the V3 code that are a) not modified and b) owned and controlled by the Uniswap governance contracts. These assurances are meant to provide developers and users with comfort that the code they’re using is safe and any changes to it (to the extent that changes are even possible) will be telegraphed long in advance.

Uniswap V2 is governed by the same permissive GPL license but has not been subject to the same DAO-run multi-chain expansion as V3. Instead, it has been forked and deployed under different brand names and across many chains almost continuously since Sushi’s vampire attack in the summer of 2020. These forks may contain modifications to the code, and their ownership structure can range from DAO governance contracts to single-signature wallets. Nevertheless, forks of V2 can garner significant liquidity and volume relative to other AMMs.

Deploy Uniswap V2 on all chains where there is there is a canonical instance of V3.

There are at least three compelling arguments to move forward with this proposal.

First, V2 forks have been plagued by hacks that have caused the loss of user funds. The Uniswap V2 contracts have been deployed on mainnet since May 4, 2020 with no loss of user funds; they can be considered among the most battle-hardened contracts on Ethereum. Canonical versions of the Uniswap contracts can provide DEX users on new chains - swappers, liquidity providers, and developers - with the safety and security for which the protocol is known.

Second, there is demand for traditional, full-range AMMs on new chains. Uniswap should be in a place to service this demand and continue to grow our user base and brand equity across multiple ecosystems.

Third, integrating Uniswap V2 pools into the Universal Router will help incrementally improve execution quality for applications that already use the Router to allow their users to swap.

This process will be very similar to the first vote to declare V3 canonical implementations. We will evaluate a batch of deployments, create a new ENS name, and populate the text record for each of those deployments. More specifically:

  • Chains that have a V3 deployment have already gone through the community vetting process and should be eligible for a V2 deployment by default.
  • V2 deployments should be owned by the same contract that owns the V3 deployment on its respective chain and subject to the same cross-chain governance mechanism
  • V2 deployments should be cataloged in the text records of a new ENS subdomain v2deployments.uniswap.eth with the bridge sender contract address and the destination chain’s UniswapV2Factory contract address

If the community supports this initiative, we recommend the following timeline:

  • August 17: RFC posted
  • August 25: Snapshot temp check posted
  • September 1: On-chain vote posted
  • September 12: If successful, on-chain vote executed

Uniswap Labs will shortly deploy V2 to a subset of the chains where V3 exists. If you are a technical team that is interested in helping to deploy V2 to the remaining chains, add a comment on this topic or DM me here to discuss. This post will be updated prior to the Snapshot with details on which teams have deployed the contracts to what networks. Finally, per the V3 process, this post will be updated prior to the on-chain vote with addresses of each deployment’s relevant contracts for community review.


Thanks for the proposal @eek637,

we completely agree that there is a need for unifying V2 and V3 deployments across chains. Having recognised canonical deployments of V2 will help protect users from malicious deployments and it’ll help create some stability in the DEX ecosystem on certain chains.

We support this proposal!


I’m a bit divided here and would probably abstain from voting. Basically, I feel this initiative comes too late, the optimal time would have been in 2021.

With the v4 deployment expected sometime this year or the next, implementing additional v2 deployments would lead to further liquidity fragmentation, increased overheads (such as documentation and integration), and potentially divert community attention from more important things (v4 and UniswapX).

Also, v4 is likely to share some benefits with v2, e.g.:

  • Cheaper swaps compared to v3

I’ll admit that v2 has some benefits too:

  • Battle-tested and secure contracts
  • Numerous existing third-party integrations, documentation, and community familiarity

However, v4 resembles more of a protocol layer than just a DEX. Ideally, I’d like to see v4 develop a “v2-style AMM” mode — a standardized set of hooks suitable for less common assets, featuring:

  • Enforced wide-range or full-range liquidity provisioning, to guarantee liquidity at any price
  • Extra wide tick spacing (to reduce gas costs for swapping)
  • Support for fee-on-transfer tokens (if feasible)
  • Built-in liquidity locking until a specific timestamp

This approach would enable v4 to replace most v2 use cases. My preference is for the DAO to concentrate its efforts on this aspect.

@WintermuteGovernance not sure what you mean by creating stability, can you give an example?

1 Like

We were mostly referring to newer chains (e.g. Base) where there have been several adverse forks of Uni V2/V3. Having a recognised canonical deployment of Uni V2 with proper governance controls will provide users more stability and safety whether their preference be V3 or V2.

You do make some fair points about resource spend. However, if the community only has to approve this proposal for multiple deployments and there are willing participants to help in the back it shouldn’t be too bad. We have also reached out to @eek637 to potentially help with this.

1 Like

We’re supportive of this initiative. Better late than never!

1 Like

Is it possible for router to find optimal route?

(not to mention aggregators like 1inch and meta-aggregators like DefiLlama)

I like the familiarity of V2 and I see no harm in deploying it.

Thanks @kfx. This is a thoughtful analysis and you’re not wrong about the potential for v2-like pools on v4 enabled by hooks. And I also agree that it would have been useful to have v2 everywhere v3’s been deployed since we started branching off of mainnet. C’est la vie.

In my view the liquidity fragmentation is a problem but one that’s solved (at least at first) at the router level. Eventually of course we’d love to get all Uniswap liquidity for any given chain into the Singleton so that we can realize the gas optimizations it can provide. But a) I don’t think that’s necessary to plan for on day 0 of launch and b) i think there are a bunch of interesting ways we could incentivize that transition (e.g. some implementation of the credit facility @mjc716 describes here).

Infrastructure-wise, there will need to be a new universal router deployed on the chains with new v2 deployments. Integrators that talk to the current Universal Router will need to note this change and update the address they call. Any apps that interact with the protocol directly will need to update their liquidity provision UIs.

I think the benefits (increased user safety, potential market share gains) outweigh the valid cons you point out.

1 Like

Re: liquidity fragmentation, it’s just a router issue, it affects LPs too, as with lower liquidity arbitrage trades become less profitable, and sandwich attacks more profitable.

Arbitrage trades is one of the main fee sources for Uniswap LPs. N pools of k liquidity are going to generate less fees for LPs than 1 pool of N·k liquidity, unless the transaction fees are zero. Most L2 have small tx fees but they may be significant enough to change arb trading patterns, when liquidity is shallow.

As said in my first post, don’t have strong objections to the proposal, just wanted to point out this technicality.


The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.

L2BEAT is in favour of this proposal and will vote for it at the temperature check, and on the following on-chain vote.

We agree with @eek637 that although there are downsides to deploying V2 on all chains that V3 is already deployed, the benefits outweigh them. We believe there is demand for V2-style AMMs on non-Ethereum chains which is currently being filled by non-canonical deployments of Uniswap, and we think Uniswap could get some of its market share back by officially deploying V2 on those chains.

A good thing about the proposal is the fact that since we’re voting to deploy V2 on all chains that V3 is already deployed, we won’t have to vote separately for each chain as we did while deploying V3.

Our only concern regarding the proposal would be the overhead deploying V2 on all those chains would come with, but it’s our understanding that the effort will be undertaken by Uniswap Foundation, with potentially the help of other parties that express interest in helping, such as Wintermute.


Thanks to the @UniswapLabs, @WintermuteGovernance, and @GFXlabs teams for deploying V2. Contracts are listed below, and the source spreadsheet can be viewed here.

This proposal will be posted onchain tomorrow, September 11 2023.

Chain Chain ID Bridge Sender Address Bridge Receiver Address (FeeToSetter) Same owner as v3 Factory Address Deployer Team
Optimism 10 0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1 0xa1dd330d602c32622aa270ea73d078b803cb3518 Yes 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f Uniswap Labs
BNB Chain 56 0xf5F4496219F31CDCBa6130B5402873624585615a 0x341c1511141022cf8eE20824Ae0fFA3491F1302b Yes 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f Uniswap Labs
Gnosis 100 0xf5F4496219F31CDCBa6130B5402873624585615a 0xffa5599136fbab9af7799a6703b57bb33e5390cf Yes 0x7146c626be7ee5e70747aa75e295439e643fc034 Wintermute
Polygon 137 0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2 0x8a1b966ac46f42275860f905dbc75efbfdc12374 Yes 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f Uniswap Labs
Boba 288 0x6D4528d192dB72E282265D6092F4B872f9Dff69e 0xf1aaf3ada643ddbbfa78e2a6c31f655b4639053d Yes 0x53163235746ceb81da32293bb0932e1a599256b4 Wintermute
Moonbeam 1284 0xf5F4496219F31CDCBa6130B5402873624585615a 0xB2af16D6c7074228fC487F17929De830303E6531 Yes 0x91FbCAe76de0b852519C26D9f8CA865b5027eeFA GFX
Base 8453 0x866E82a600A1414e583f7F13623F1aC5d58b0Afa 0x31fafd4889fa1269f7a13a66ee0fb458f27d72a9 Yes 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f Uniswap Labs
Arbitrum 42161 0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3f 0x2bad8182c09f50c8318d769245bea52c32be46cd Yes 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f Uniswap Labs
Celo (WH) 42220 0xf5F4496219F31CDCBa6130B5402873624585615a 0x0eb863541278308c3a64f8e908bc646e27bfd071 Yes 0x79a530c8e2fA8748B7B40dd3629C0520c2cCf03f GFX
Avalanche 43114 0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc 0xeb0bcf27d1fb4b25e708fbb815c421aeb51ea9fc Yes 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f Uniswap Labs
Linea 59144 0xd19d4B5d358258f05D7B411E21A1460D11B0876F 0x581F86Da293A1D5Cd087a10E7227a75d2d2201A8 Yes 0x056588f18869a626b0Ae9e89f077eFE6BA752633 GFX

One note - there are two deployments of the V2 factory on Celo. The first was deployed by Uniswap Labs at address 0x5c69...5aA6f before proposal 43 was executed, so the owner was set to the Optics bridge to match the V3 owner at the time. To avoid separate governance vote to change that ownership, and because there were no pools created on the first deployment, GFX deployed a new version of the factory owned by the Wormhole receiver contract which matches the V3 deployment.


Just a heads up - we’ve run into a nit picky issue with these deployments of v2 and are working through it with the various deploying teams. Will get this vote up when that’s resolved.