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

Proposal Discussion
1

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

TL;DR

  • 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.

Introduction
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.

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

Rationale
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.

Process
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.

11 Likes
2

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!

3 Likes
3

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
4

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
5

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

1 Like
6

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.

7

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
8

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.

2 Likes
9

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.

2 Likes
10

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.

4 Likes
11

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.

3 Likes
12

It took longer than expected but I am planning to post the vote tonight (February 9 2024) to declare v2 deployments canonical on all chains where there’s a v3 deployment. This includes Scroll, Rootstock, and Filecoin, which have all had successful v3 deployment votes since this initiative to get V2 out in the world was put on hold.

A full list of deployment addresses can be found here and is also listed below.

Chain Chain ID Bridge Sender Address Bridge Receiver Address (FeeToSetter) Same owner as v3 Factory Address Deployer Team
Optimism 10 0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1 0xa1dd330d602c32622aa270ea73d078b803cb3518 Yes 0x0c3c1c532F1e39EdF36BE9Fe0bE1410313E074Bf Uniswap Labs
Arbitrum 42161 0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3f 0x2bad8182c09f50c8318d769245bea52c32be46cd Yes 0xf1D7CC64Fb4452F05c498126312eBE29f30Fbcf9 Uniswap Labs
Avalanche 43114 0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc 0xeb0bcf27d1fb4b25e708fbb815c421aeb51ea9fc Yes 0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C Uniswap Labs
Base 8453 0x866E82a600A1414e583f7F13623F1aC5d58b0Afa 0x31fafd4889fa1269f7a13a66ee0fb458f27d72a9 Yes 0x8909dc15e40173ff4699343b6eb8132c65e18ec6 Uniswap Labs
BNB Chain 56 0xf5F4496219F31CDCBa6130B5402873624585615a 0x341c1511141022cf8eE20824Ae0fFA3491F1302b Yes 0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6 Uniswap Labs
Polygon 137 0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2 0x8a1b966ac46f42275860f905dbc75efbfdc12374 Yes 0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C Uniswap Labs
Gnosis 100 0xf5F4496219F31CDCBa6130B5402873624585615a 0xffa5599136fbab9af7799a6703b57bb33e5390cf Yes 0x8c8b524ce7c9D2e3f59aB6711bE4Ac826FA46a0f Wintermute
Boba 288 0x6D4528d192dB72E282265D6092F4B872f9Dff69e 0xf1aaf3ada643ddbbfa78e2a6c31f655b4639053d Yes 0x40a26d18440948d8eE121b78ca4e88C37D30143b Wintermute
Linea 59144 0xd19d4B5d358258f05D7B411E21A1460D11B0876F 0x581F86Da293A1D5Cd087a10E7227a75d2d2201A8 Yes 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 Saucepoint
Moonbeam 1284 0xf5F4496219F31CDCBa6130B5402873624585615a 0xB2af16D6c7074228fC487F17929De830303E6531 Yes 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 Saucepoint
Celo (WH) 42220 0xf5F4496219F31CDCBa6130B5402873624585615a 0x0eb863541278308c3a64f8e908bc646e27bfd071 Yes 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 Saucepoint
Scroll 534352 0x6774Bcbd5ceCeF1336b5300fb5186a12DDD8b367 0xefc9d1096fb65c832207e5e7f13c2d1102244dbe Yes 0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7 Saucepoint
Rootstock 30 0xf5F4496219F31CDCBa6130B5402873624585615a 0x38ae7de6f9c51e17f49cf5730dd5f2d29fa20758 Yes 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 Saucepoint
Filecoin 314 0x1f8A4d195B647647c7dD45650CBd553FD33cCAA6 0xFf3b2DA1379cc67cc2755194604713f10b820b0E Yes 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 Saucepoint

The technical issue that caused us to cancel the first vote was minor. Differences in how the contracts were deployed caused variations in a variable called pairInitCodeHash. After diagnosing the cause of this difference, the team at @WintermuteGovernance wrote a script that was used by each of the deploying teams, ensuring that the contracts are indeed identical across chains. Thanks to Zak and Igor from Wintermute, Mark from Uniswap Labs, and the UF’s resident jack of all trades Saucepoint for your help in deploying and verifying these contracts.

4 Likes
13

Hey, there’s a question on StackOverflow whether Uniswap v2 router also has been deployed on the other chains. I assume that no, it was never the plan, and everyone is required to use the Universal router instead?

Speaking of which:

@eek637 can you clarify if there’s a new router deployed now?

14

correct - we didn’t deploy new routers. but anyone could, if they wanted to use a specific version.