- 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.ethwith the bridge sender contract address and the destination chain’s
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.