100% support this proposal.
Good idea. Maybe we give it a full 24 hours and if sentiment is still highly in favor we move to a snapshot vote?
Just adding this here for everyone’s reference. The current official procedure seems to be to do two sentiment polls with passing thresholds of 25k UNI and 50k UNI respectively, followed by a on-chain governance proposal.
The governance proposal requires the proposer to have 10m UNI ($260 million at today’s prices) delegated to them. Passing the vote requires 40m UNI ($1 billion at today’s prices).
I’m supportive of this as well. As a tangible follow-up, it might make sense to deploy to the Arbitrum testnet and ensure everything is working as intended. AFAIK this is as simple as adding a new network in
hardhat.config.ts, but please correct me if that isn’t the case.
I understand the Uniswap Labs team needs to prioritize what it works on, and understand if they don’t currently have the bandwidth. That being said, I’m confident that the community (including myself) would be down to put in the technical work to make this happen and allay relevant concerns.
Absolutely support this proposal. In my mind, Uniswap doesn’t have the luxury of waiting for OE to get it done. Arbitrum is a very strong and like-minded project, and there is very low friction to deploying to it. Let’s make it so!
I support this proposal. Like other commentators mentioned, Arbitrum will host UNI, whether a clone or a direct deployment. Furthermore, I don’t think that L2s should be thought of as competition, especially since Arbitrum does not have a direct token associated with it - the tech is neutral and developers should think of it like building an app for release on both Mac and Android. The end result is that the consumers and users of that tech benefit and create a synergistic effect.
Also it’s worth considering that the low gas fees could lead to explosive TVL growth the way that BSC had explosive growth this year primarily due to low cost gas fees.
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