As Bill Parcels said, “The best ability is availability”.
Uniswap v3 finds itself in an interesting position with its licensing that legitimate teams cannot legally fork the code. This is great for maintaining a competitive advantage, but also has Uniswap Labs in a hard place when it comes to deploying the smart contracts to new chains that they did not previously plan to support.
I believe that there is immense value in being available for swaps on every EVM compatible network. Since there is no liquidity mining, it is hard to make the case that multiple deployments will segment liquidity, and long term if this is an issue governance can flip the switch on liquidity incentives for the chains it desires deepest liquidity. In the meantime, not deploying to new and growing networks like Arbitrum and Matic just allows for other exchanges to come in and fill that spot. This could potentially eat into fees earned by governance in the future.
Alongside this, it will help to grow the potential list of projects that can be built on Uniswap v3. Growing the public smart contract libraries interfacing with and using the v3 codebase will only expedite Uniswap adoption on all chains as the code and integrations become more battle tested.
Arbitrum launches later this week on May 28th. I think it would be best to start a discussion ASAP around deploying the Uniswap v3 code to Arbitrum network.
In my opinion it would be good for Uniswap with regards to L2, Arbitrum is an alternative implementation of an optimistic rollup with different design principles and thus tradeoffs. Optimism can automatically follow Ethereum hardforks but Arbitrum has far less risk of reaching a non-deterministic state and it can be used with the same contract bytecode as used for Ethereum L1 contracts.
We can’t know yet which one is going to be more attractive for developers, if Uniswap decides to only integrate with Optimism and Arbitrum becomes the most popular rollup then we could leave a big void that will be filled by a competitor.
Last but not least, Arbitrum is launching the 28 of May and we don’t know when Optimism is launching, deploying v3 to Arbitrum will mitigate in a short timeframe the “high gas fees” bad publicity Uniswap is having without requiring practically any contract changes from the dev team.
Arbitrum is strongly aligned with Uniswap & Ethereum values: it inherits the trust assumptions of mainnet and uses ETH for transaction fees.
While I agree that Uniswap shouldn’t chase every side-chain out there, I do think Arbitrum has solid potential to be one of the primary Ethereum scaling solutions, operating alongside Optimism.
Arbitrum will have a version of Uniswap on it, either a fork of V2 or an anonymous fork of V3. I believe it is in the best interest of UNI holders, as well as the Ethereum ecosystem as a whole, for there to be an officially-supported instance of Uniswap V3 deployed to Arbitrum.
I storngly support this proposal. If the overall community too supports this proposal, this proposal will serve as a strong litmus test for whether Uniswap governance will be able to respect the wishes of the community.
There have been rumours that Uniswap investors such as Paradigm and a16z will be reluctant to deploy Uniswap to Arbitrum due to vested financial interest in Optimism. Deploying Uniswap to Arbitrum will quash these rumours and strongly signal that the there is no misalignment of goals amongst the various investors, funds, and individuals invested in Uniswap.
Uniswap should aim to be public infrastructure and deploy itself wherever possible. This is simultaneously also the path to maximising revenue. Projects such as Sushiswap and Aave have already soft-signalled intentions to deploy to Arbitrum, this indicates that a vibrant DeFi ecosystem is going to grow on Arbitrum, whether we are prepared for it or not.
Uniswap v3 has a competitive moat due to its licensed codebase and capital efficient model, it must take full advantage of this. Not deploying to all chains could be interpeted as some as an action undertaken in bad faith, this in turn could lead to someone not respecting the license and forking the codebase.
To conclude, I can’t think of a single reason why the broader community should not want Uniswap deployed on Arbitrum.
I would specifically request the Uniswap team and lead engineers - Hayden Adams, Noah Zinsmeister, Dan Robinson and anyone else involved - to let the community know if and how such a deployment could take place, and any roadblocks they may face. Such information would be helpful as we head towards an official vote.
I´d say its too early to decide for Arbitrum…Give it a few weeks time for the community to make it crystal clear which one will be the leader. Then this discussion would be on point. I´d say that I am hesitant to support this proposal until more data is available. I bet the Uniswap team is a little bit busy with Optimism already right now. The die has been cast…do you truly want to complicate it now?
I mean, I think we are kind of getting a little bit ahead of ourselves. We have optimism coming up, Vitalik´s proposal, and now pleas for Arbitrum. Its turning into a bit of a mess at the time. So just to sum it up, Im NOT against it, but I´d prefer to wait just a little bit.
Agreed, is it imperative that Uniswap leads the way in it’s original goal of allowing anyone to swap in an uncensored, decentralised and permissionless system. If the judgements of large VC’s impedes on the governance because of their other interests, it would be devastating for the defi ecosystem as Uniswap is the poster-boy of defi and it will set a dangerous precedent for other protocols. If Arbitrum is sufficient to support the requirements of Uniswap I see no reason for it not to go ahead.
I understand the idea was to deploy Uniswap on Optimism, but the realty is Arbitrum is way ahead of Optimism and who knows how long will we have to wait until Optimism is ready. I strongly support deploying on Arbitrum Mainnet!
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.