On chain governance votes should involve concrete actions rather than intention. So if the snapshot poll(s) resolve favorably, I think it would be worth taking time to plan a scope of work and estimate cost of development/deployment. We’ll then be able to hold a proposal to fund development and take any other actions needed to make this happen.
I have a crazy idea that could be used to concretely incentivize Uni v3 deployment onto Arbitrum: we use counterfactual address prediction and a custom UNI token locking contract to temporarily stake UNI treasury funds. The funds would only be able to be returned to the treasury once the pre-computed, counterfactual addresses of UNI on Arbitrum are verified programmatically. We would use a publicly claimed Uni deployer address and a custom written deployer contract (with the Uni deployer whitelisted on it) to achieve this trustless incentivizer. The funds would stay on L1 and only be unlocked by a valid L2ToL1Message from Arbitrum. We could use a multisig emergency backdoor in the locking contract to prevent permanently locking the funds, and we would make it so that the contract could only transfer back to the treasury to prevent theft.
I think this is good idea. v3 is so efficient that I think there is enough liquidity in DeFi to make both Arbitrum and L1 deploys work. Additionally, arbitrage opportunities would probably boost up volume a little bit also.
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!
I support this proposal. I’d love to try uniswap with cheap fee
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.
I support this proposal too.
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
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.
I 100% support this proposal.
Just a quick write up on what we know about this proposal
What is Arbitrum?
L2 scaling solution based on rollups (link)
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.
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
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.
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.
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.
I support strongly. Arbitrum Mainnet V3 rollout
I support this proposal.
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
This would make uniswap timelock contract an operator of the
uniswap.eth node, allowing it to create subdomains. Alternatively,
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,
setAuthorisation(...)on ENSPublicResolver2, setting the uni timelock as authorized on the newly created
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.
I can not agree more ; I support this proposal. how can I to take part in voting?
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:
- EXTREMELY confident in the security of the platform.
- 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
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
The uniswap governance cannot actually control the
uniswap.ethENS 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.