Declare canonical deployments of V2
This proposal will add references to canonical implementations of Uniswap V2 to text records on a new subdomain on uniswap.eth.
If passed and executed, this proposal will call two functions:
- the first creates the
v2deployments subdomain by calling setSubnodeRecord on the ENS Registry contract and passing it hashed values of the uniswap.eth name and v2deployments subname, as well as the timelock's address and the address of the resolver linked to uniswap.eth
- the second populates text records by passing the encoded hex data representing 10 separate
setText calls to a multicall function on the resolver. Each setText call specifies the network ID of the chain in question as the key and the bridge sender and destination v2Factory contract addresses as the values, separated by a comma (e.g.
{"10": addr1, addr2} )
The code used to derive these values can be found in a Github repo here.
A full list of deployment addresses can be found here.
Simulations of this proposal's successful execution can be found by navigating here, clicking on the latest successful workflow run and downloading the Uniswap artifact at the bottom of the page.
The forum discussion around this proposal can be found here and has been copied below as well.
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.
