Thank you for initiating this discussion around the post-BSL proposal standard, @devinwalsh. Appreciate your helpful input @Kydo & @devenmatthews.
Establishing a coherent deployment structure is imperative for signaling to the Uni community and all external stakeholders in the space that Uniswap has a systematic process behind multi-chain expansion.
We want to make sure that post-BSL standards are decided on as soon as possible to begin expanding to more alt-L1s and L2s. Ideally, a more rigorous expansion initiative should have taken place months ago when Uniswap still had the BSL as a competitive advantage. Unfortunately, we did not see as many deployments as we likely should have, partially due to organization/coordination problems that have been quelled after the establishment of the Uniswap Foundation in Fall 2022, voted in by the Uni DAO. The tumultuous market conditions further complicated matters, causing numerous chains to delay ecosystem expansions–not to mention exploits that prevented certain deployments from commencing, namely the Nomad debacle which has delayed both a Uni v3 deployment onto Moonbeam and Gnosis Chain.
Deploy Uni v3 Sooner Rather Than Later
Although the argument of deploying Uni v3 on X chain due to license expiration urgency is now moot, I still believe that going to market sooner rather than later could save Uniswap some headaches in the future. Here are a few reasons why:
A Bad Consumer Experience Hurts Uni’s Reputation:
The more time that passes, the more v3 forks will arise. A major issue with numerous, unruly deployments is that deciding between various forks will be cause for an unsatisfactory consumer experience. Where does a user go for the “real” Uniswap?
Numerous users are also not privy to the license ordeal at all. So when they see an unofficial Uni fork on their chain, they may subject themselves to unforeseen risks, especially if the deployers have altered contracts, deployed recklessly, or even employed malicious contract modifications. The mistakes of forks could incorrectly be attributed to Uniswap itself thereby damaging the protocol’s reputation.
Liquidity Segregation Among Forks & Battling for Market Share with Modified Forks:
Ideally, we get to market first on X chain with an “official” deployment that prevents segregated liquidity amongst unofficial forks. A fork of Uni with slight contract alterations may achieve higher TVL and activity on a chain–but that fork cannot be considered official since its code has been tampered, regardless of how much activity it has. So, instead of allowing a modified version of Uni present on X chain to dominate an L1 market–one that has garnered a ton of attraction and is not able to be considered an “official” fork due to its alterations–it’s best if we deploy untampered v3 contracts soon, making sure those deployments attain the most traction on X chains.
However, the above arguments are primarily for EVM chains. Non-EVM chains that alter v3 code out of necessity is a topic for later. It’s a good thing most large L1s have some way to support EVM-equivalent dapp deployments. For example, Avalanche has the C-Chain, Polkadot has Moonbeam parachain, Near has Aurora, Cosmos has app chains like Evmos & Kava…and a bunch of L1s just use EVM like BNB Chain.
Deciding From a Pool of Good Uni Forks:
Correspondingly deciding which fork we want to deem “official” by taking it through Uni governance rails could also become more complicated as more forks arise. What if multiple forks on X chain want to become official? And what if they’re all properly deployed? Who do we say yes to and who do we deny, especially if none of the forks happen to dominate the market on X chain? Although we will likely run into this issue, we can mitigate it as much as possible via conducting deployments in the near future.
Selecting a Deployer
Even though ramping up deployments has its benefits, we should not sacrifice safety for speed. Delineating some of the tasks for deployments will help in this arena. A tangible step the community has recently taken is creating the Bridge Assessment Committee.
Now that bridge assessment has been delegated to a committee, the stakeholder that requires the most scrutiny from the DAO is the deployer. The DAO must make sure that the deployment team is capable of proper contract implementation on the desired chain. So who will be assessing if the deployment is done correctly? If a proposer has yet to coordinate with a deployer, we may see an influx of forks wanting to have their deployment be used. And the process of vetting which forks are proper is necessary. A heuristics approach to this is simply coordinating with a well-known team with deployment history & technical capability, like Plasma Labs, LayerZero Labs, Wormhole, etc. It may also be the case that one or more of these entities begins deployments on multiple chains right as the BSL expires. This may be cause for concern–but would also alleviate issues regarding deployment reliability.
Furthermore, the deployer will likely be coordinating with Uni Labs after the onchain vote passes to complete front end integration. This process is most seamless if the deployer is a known, reliable entity.
The Stakeholder List
In reference to @devinwalsh’s post, I also suggest that the initial RFC requires have a section called “stakeholders”, where the tentative deployer is mentioned. It just makes it more clear for everyone assessing the deployment in general. I concur with @devenmatthews that the temp check should ONLY be a vote on the DAO’s desire to deploy on X chain, so the temp check must omit any mention of deployer, bridge, or any other stakeholder, BUT those stakeholders must be in the RFC. And later, the onchain vote should include the final full list of stakeholders.
Note that the bridge and deployer sections may be denoted as “unassigned” for an RFC. It’s up to the proposer to decide this–but if they have already selected a deployer and/or bridge, they should mention it for transparency.
In short:
- Proposer should include a list of all stakeholders in the RFC, but this is just for clarity and transparency purposes
- To make sure that the temp check is ONLY voting on the DAO’s interest of deploying on X chain, the temp check should NOT include the list of stakeholders
- The onchain vote should include a full list of involved stakeholders