Deploy Uniswap v3 to Arbitrum Mainnet

Proposal Discussion
22

It might be worthwhile to note that this strategy could potentially violate contractual agreements or social obligations between interested parties, and it forces them to make a statement. By exploring a less game-theoretic approach, ie using a direct incentivizer such as a Uni locking contract, we alleviate the problems investors/builders might have in contradicting their own agreements. That’s all pure speculation, of course. I would imagine that it gives teams some freedom from the consequences of such a deployment, and it’s a really cool experiment in L2<>L1 interactions!

1 Like
23

I support this proposal. I’d love to try uniswap with cheap fee

1 Like
24

Thanks @andy8052 for this, and others for voicing your opinions!

I’d like to briefly explain the mechanics of what an on-chain governance action to accomplish this proposal would look like. As explained in the V3 announcement post, the V3 source code may not be used in a commercial or production setting for up to 2 years after launch without appropriate permission. However, additional use grants can be made via changes to v3-core-license-grants.uniswap.eth. Since Uniswap governance owns uniswap.eth, it’s possible for governance to create a text record at this subdomain indicating that a V3 deployment on the Arbitrum Mainnet which appropriately gives control over the factory owner address to Uniswap governance is not in violation of the license.

If this action passed, any deploy that met the criteria could become the canonical V3 on Arbitrum. It might be desirable to coordinate this deployment process with the Uniswap Labs team, so that (for example) the factory addresses on all canonical deploys would continue to be identical, as well as the Arbitrum team, for any technical issues that may arise.

11 Likes
25

I support this proposal too.

26

Thanks Noah! And agreed that working with the team is important. This also will allow for the UI to support Arbitrum sooner rather than later. Unless I am mistaken, I think the technical requirements are actually pretty small here after we get a vote passed

27

We can add support for this kind of proposal creation to the fish.vote UI if that’s helpful. It’s not hard for us to add support for formal governance proposals in the case that the author already has 10M delegate votes.

2 Likes
28

I 100% support this proposal.

1 Like
29

Just a quick write up on what we know about this proposal

What is Arbitrum?
L2 scaling solution based on rollups (link)
Why Arbitrum?
Initial idea by the Uniswap core team was to wait for Optimism to be ready and launch Uniswap v3 there (Optimism is also L2 scaling based on rollups). Arbitrum launches May 28th and community started the incentive to deploy Uniswap v3 there.
Why rollups?
Rollups will allow users to use Uniswap in environment where fees will be much lower than they are on Ethereum chain (L1)
Please explain rollups in 2 minutes, preferably with pictures
sure: https://youtu.be/BgCgauWVTs0?t=452
How can Uniswap be deployed to Arbitrum?
Deploy Uniswap v3 to Arbitrum Mainnet - #24 by Noah
Will Arbitrum deployment use liquidity from pools on Ethereum chain?
No. It is separate deployment which means separate pools.
How big of a performance upgrade can we expect?*
Not an expert on this topic but based on my research rollups can scale around 100x if all transactions in a rollup are simple payments. However since average Uniswap transaction is ~5x more gas hungry than a simple payment we can probably expect around 15-20x? (I would love someone more knowledgeable to answer this)
How much lower will the fees be?*
Assuming you already transferred some of your funds to L2 fees can be as low as 10% of those on L1. However, “bridging” liquidity in itself to any L2 is quite gas hungry.
Bridging liquidity to L2?*
Yes. Assuming v3 is deployed on Arbitrum, in order for your to use that deployment you will have to bridge some of your funds to Arbitrum. Only then you will be able to use Arbitrum deployment.
How do I get my funds back to the chain?*
You have to bridge it back. Rollups are notorious for this process being pretty slow. Not sure what is expected delay for Arbitrum.

EDIT1:
joined Offchain Labs community to try and find out some more details about how Arbitrum deployment would potentially look for an end user. Couple interesting details

Delay for getting your funds from Arbitrum back to L1 chain is 7 days
Gas cost for getting ETH onto Arbitrum is 70k gas. That is gas cost of ~0.5 swaps on the L1 (Uniswap v3 swap is around 120k-150k gas)

*I would love if someone could expand more on last 4 questions. I think that’d be very valuable info. I just know the basics. Feel free to tell me correct answers and I’ll update. I think these are the interesting questions an average user might have.

4 Likes
30

Thanks for clarifying. It appears that the subdomain v3-core-license-grants has not yet been set on uniswap.eth, so the proposal would need to first do this before setting the text record at that subdomain. I made an initial implementation of this proposal here:

Important to note that I just copied your words directly for the license grant, and I imagine it would need to be updated to be more explicit and professional. This is incomplete in terms of the unit tests, but I can get back to it tomorrow sometime.

31

同意，尽快部署在l2网络上，可以增加uniswap的竞争力。

1 Like
32

I support strongly. Arbitrum Mainnet V3 rollout

33

I support this proposal.

34

Hi Noah. I nearly wrote the proposal to accomplish this task, but there’s a slight problem. The uniswap governance cannot actually control the uniswap.eth ENS name, because it is owned by an EOA: 0x42D44cC7435CCF5DBDfD59e01fe9f4d306365C7A.

This EOA needs to do one of several things to give uniswap governance control of the uniswap.eth name, so that the governance can create the v3-core-license-grants.uniswap.eth subdomain:

  1. call setApprovalForAll(...) on ENSRegistryWithFallback

This would make uniswap timelock contract an operator of the uniswap.eth node, allowing it to create subdomains. Alternatively,

  1. call setSubnodeRecord(...) directly from the EOA to create the subdomain, instead of requiring the governance to do so

This would need to be followed up with,

  • call setAuthorisation(...) on ENSPublicResolver2, setting the uni timelock as authorized on the newly created v3-core-license-grants.uniswap.eth subdomain.

As it is, the uniswap governance has no power to issue licenses as detailed in V3 announcement post. In other words, the uniswap license is currently centralized by this EOA!

I’ve since updated the proposal repository. Take note of this line, which is the only way I could get the proposal to execute. It took me quite a while to dig through etherscan, ENS, etc. to solve this problem.

1 Like
35

I can not agree more ; I support this proposal. how can I to take part in voting?

36

I brought this up on twitter, but want to raise it here. If we are going to as a community support a brand new platform that is not battle-tested, we should be:

  1. EXTREMELY confident in the security of the platform.
  2. Given that confidence, we should put the weight of our bug bounty programs behind it by extending it such that if there is a bug in Arbitrum, that results in loss of LP funds, that is eligible for the full reward ($500k, soon to be $1.5m I believe).

One of Uniswap’s benefits is their exceptional track record. It falls on the community to ensure that an underlying platform we deploy on isn’t an extreme risk for general users. I imagine a lot of people in this thread are both UNI holders and uniswap exchange users. As uni holders, we have an obligation to make the best decisions possible for the broad set of users. This includes evaluating the safety of a particular platform. The only thing worse than not deploying is deploying and people losing serious amounts of money.

I have faith in the Arbitrum team’s execution, but it won’t be battle-tested for some time. They have undergone audit, but it is a very complex, built from scratch, L2 node + contracts.

Anyway, food for thought

9 Likes
37

Absolutely agree with this. Uniswap’s untarnished reputation is priceless, and we should make sure that any decision made that has the potential to change this should be scrutinized (I say this in the best possible way), in order to preserve this reputation

38

The uniswap governance cannot actually control the uniswap.eth ENS name, because it is owned by an EOA: 0x42D44cC7435CCF5DBDfD59e01fe9f4d306365C7A .

Not quite true! We transferred ownership of uniswap.eth to timelock in this transaction soon after governance launch.

The controller was still set to the EOA but the owner can change the controller at any time (while the controller has no ability to change the owner).

Thanks for pointing this out, was still an oversight. The current controller EOA just transferred its role to timelock to save needing to add this step to a gov vote.

2 Likes
39

I did see that it was transferred a while ago. Strangely enough, the problem was that ENSRegistry didn’t update its owner variable, despite the domain having been transferred according to ENSPublicResolver2, so the governance couldn’t make the subdomain until you transferred the controller to the governance. I think it was a weird quirk of ENS that no one noticed until now. It is fixed now, thanks!

40

I’m not sure if I’m too late to have my say but I fully support

41

This part just clicked for me. I was wrong, you were right! I get it now, the path to issue a license would begin with transferring the controller, then creating the subdomain, then setting a text record. Out of curiosity, why wasn’t the license subdomain made before setting the controller to governance though? This still has to be done by governance.