8/25/23 - Snapshot poll here 9/12/23 - On-chain vote here
TL;DR
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:
v2deployments.uniswap.eth with the bridge sender contract address and the destination chain’s UniswapV2Factory contract addressIf the community supports this initiative, we recommend the following timeline:
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.
8/25/23 - Snapshot poll here 9/12/23 - On-chain vote here
TL;DR
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:
v2deployments.uniswap.eth with the bridge sender contract address and the destination chain’s UniswapV2Factory contract addressIf the community supports this initiative, we recommend the following timeline:
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.
https://gov.uniswap.org/t/temperature-check-deploy-uniswap-v2-on-all-chains-with-v3/21799/9?u=kaereste
https://gov.uniswap.org/t/temperature-check-deploy-uniswap-v2-on-all-chains-with-v3/21799/9?u=kaereste
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.
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.
correct - we didn't deploy new routers. but anyone could, if they wanted to use a specific version.
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:
Infrastructure-wise, there will need to be a new universal router deployed on the chains with new v2 deployments.
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:
Infrastructure-wise, there will need to be a new universal router deployed on the chains with new v2 deployments.
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.
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.
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.
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.
We're supportive of this initiative. Better late than never!
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.
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).
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.:
I'll admit that v2 has some benefits too:
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:
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?
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.
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.
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).
correct - we didn't deploy new routers. but anyone could, if they wanted to use a specific version.
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:
Infrastructure-wise, there will need to be a new universal router deployed on the chains with new v2 deployments.
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:
Infrastructure-wise, there will need to be a new universal router deployed on the chains with new v2 deployments.
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.
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.
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.
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.
We're supportive of this initiative. Better late than never!
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.
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).
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.:
I'll admit that v2 has some benefits too:
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:
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?
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.
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.
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).
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.
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.
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.
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!
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.
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.
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.
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!
