TL;DR
Uniswap v3’s BSL expired Saturday, April 1, 2023.
Post BSL-expiry, it will be beneficial to identify one official Uniswap v3 deployment per chain in order to provide safety & security for users, focused support to ecosystem participants, and clarity to Uniswap governance. This deployment would be recognized in future Uniswap governance actions, by the UF for hackathons, by the ecosystem for liquidity mining campaigns, etc.
In the post below we recommend the following in order to determine and track official Uniswap v3 deployments:
A governance process which mostly remains the same, with some updates to allow for the fact that deployments can now be recognized as official after they have been deployed.
Creation of a new subdomain v3-deployments.uniswap.eth that will be used to track official deployments.
The creation of the new v3-deployments.uniswap.eth subdomain requires a governance vote. We are kicking that off here with an RFC, and we will gather feedback on this proposal as a whole as we go through the governance process.
As many of you know, the BSL is set to expire later this week on Saturday, April 1. Once it expires, it will be possible for any person or team to deploy the Uniswap v3 code for production or commercial use (more on the BSL here). We assume that there will be multiple deployments of Uniswap v3 across other chains.
However, after the BSL expires, it will still be important for the Uniswap DAO to determine which deployment, of many potential deployments, on another chain should be recognized as the Uniswap DAO’s official deployment.
It will be important, and beneficial to both the DAO and Uniswap users, to identify one official deployment per chain for many reasons:
Code Verification: this official deployment will have been verified as equivalent to the source code by the DAO. In other words, the DAO will have verified that no one has altered the deployment code in a malicious or unintentionally harmful manner. If for some reason the code has been altered, for instance to be deployed on StarkNet in Cairo or in another language on another chain, those changes would be vetted by the DAO prior to an on-chain vote.
Ecosystem Clarity & Support: Some Uniswap ecosystem developers may want to focus their efforts on integrating with one designated Uniswap deployment per L1 or L2. Ecosystem or Foundation funded liquidity mining campaigns and hackathons will similarly look to support the official deployment.
Uniswap Governance Control: Only the official deployment will be updated and maintained by Uniswap governance (ie., to add fee tiers or turn on fees).
Below we lay out the process we recommend that Uniswap governance adopts to identify these official deployments. Some of the thinking around these steps were inspired by a post written by @devenmatthews a few days ago, which you might also want to read here.
The governance process will remain mostly the same, with some specific changes being recommended to:
Takes into account the fact that deployments may now be done prior to the Uniswap governance process being completed to identify it an official deployment.
Allows the proposer to change the deployer team if they are unable to fulfill their responsibilities in a timely manner, or to change a bridge if the chosen bridge is hacked, prior to the final on-chain vote.
Still allow for the Uniswap DAO to review and approve specific details, such as the deployment team and bridge, prior to voting a deployment to be official.
Allow for the governance process to track official deployments in a newly created Uniswap.eth subdomain, v3-deployments.uniswap.eth. The on-chain vote will update this subdomain with the relevant deployment information
An on-chain vote is itself required to create the new subdomain v3-deployments.uniswap.eth, which will track official deployments of Uniswap v3 on other chains. This RFC is kicking off the governance process to do that.
List of Actors in a Deployment
First we want to review and clarify the types of stakeholders who participate in a cross-chain deployment. This review may be helpful in understanding not only the recommendation below but the mechanics of these types of proposals as a whole. It’s possible for one entity or person to serve as multiple stakeholders at once – for instance, a proposer can also be a deployer, and a deployer can be a bridge provider.
Proposer: entity or individual that creates the proposal on forum, and manages the governance process
Deployer: entity that handles the deployment of Uniswap v3 contracts on other chains or L2s
Bridge Provider: cross-chain messaging solution selected from the Bridge Assessment Committee’s recommendations
L1 or L2 team: target chain for deployment
Proposal Sponsor: entity that has enough UNI to sponsor the final on-chain vote. The Uniswap Foundation is typically able to serve as the sponsor for these proposals.
Recommended Process
The governance process (defined here) will remain the same in terms of time frame, platform (forum, Snapshot, on-chain vote), and quorum requirements, with specific adjustments being made to the process for ascribing a Uniswap v3 deployment as “official”.
Prior to an on-chain vote, Uniswap v3 should be deployed. During the vote, delegates should assess all components of the proposal and deployment including but not limited to a deployment’s equivalency to source code (potentially leveraging the help of more technical network stakeholders), and whether a bridge or bridging solution is included in the Bridge Assessment Committee’s set of recommendations.
Deployments which pass this governance process will receive support as the official Uniswap deployment on the L1 or L2 from the Uniswap Foundation, DAO, and ecosystem.
RFC:
Minimum 7 days. Post your proposal on the governance forum to allow the community to review and ask questions. Keep the proposal in the forum, responding to questions and iterating upon the proposal based on feedback for at least 7 days prior to moving to the next phase.
Proposal is for an official deployment on the L1 or L2, with the rationale for deploying Uni v3 on that chain.
At this point, the deployment may already be completed. If so, include links to relevant contracts, and include a description of the deployment team and bridge used.
If the deployment has not already been completed, the proposal might reference the deployer and bridge which are intended to be used, but this is neither binding nor required.
If the deployment has not been completed already, the proposer should converse with teams interested in aiding with contract deployment. Deployers can also comment on the RFC, communicating their willingness and technical capabilities to handle deployment.
Temperature Check:
5 days. Create an off-chain Snapshot Poll to ensure community sentiment is in favor of your proposal. A majority of votes in favor, with a quorum of 10M UNI votes, is required to move forward to the last phase.
A Temperature Check is done, assessing Uniswap DAO’s desire to have the deployment done on the L1 or L2. Again, at this point, a deployer and bridge might be determined already, but it’s neither binding nor required.
If and when the Temp Check passes, the deployers will have confidence in Uniswap governance interest in supporting a deployment on the L1 or L2.
Deployment is completed
If a deployment has not already been completed, it should be done following a successful Temperature Check. The proposing team can work with the deployer to execute the contract deployments. Details of the deployment, including contract addresses and messaging infrastructure, should be added to the forum in the proposal for the on-chain vote.
Governance Vote:
11 days (7 day voting period). An on-chain vote is proposed and executed. If successful, the vote would add the new deployment information to the newly created v3-deployments.uniswap.eth subdomain.
The benefits of this process are as follows:
The proposer is not bound to a specific deployment team, if for some reason the original deployment team is unable to deploy in a timely manner prior to the on-chain vote.
The proposer is not bound to a specific bridge if a bridge is hacked between the RFC and deployment. A bridge or agnostic solution should ideally be chosen based on the recommendations from the Bridge Assessment Committee.
Uniswap governance still has final approval of the deployer and bridge used through the final on-chain vote.
Creation of v3-deployments.uniswap.eth subdomain
As we note above, and in alignment with the governance process we recommend after the BSL expires, the UF proposes to create a new ENS subdomain v3-deployments.uniswap.eth to track official deployments of Uniswap v3 on L1s and L2s. This Temperature Check is the second step in that process.
Updates to Proposal from RFC
Thanks to everyone who provided feedback on the Request for Comment. We wanted to call out a couple specific points from the conversation:
Naming Convention
We should settle a single name for the deployments that are the subject of successful governance votes. We recommend “canonical”. E.g. the recent Avalanche deployment will be referred to as the canonical Uniswap v3 deployment on Avalanche.
Non-EVM Deployments
For non-EVM deployments, @deven’s Starknet post is a good starting point. There has been some conversation around conventions for audit requirements and we hope that continues. This proposal is not meant to define the exact process by which those deployments will happen, but I do think that audits from a reputable firm (or firms) that are familiar with the Solidity codebase would be a signal that a given deployment should be taken seriously (and a lack of those audits should be a symbol as well).
Verification of Deployments
For EVM deployments, a standardized verification process that can be performed by anyone and the results of which can be found publicly (and be interpreted by a variety of audiences) should absolutely be the norm. Much like the audit process mentioned above, the presence or absence of these test results will be a valuable signal to delegates when they vote on a deployment. I joined the Foundation 36 hours ago but this topic has already come up in several discussions and I’m excited to help move it forward.
Next Steps
Code
Pending a successful Snapshot vote, we will move forward with an on-chain vote that:
Creates a new subdomain (v3-deployments.uniswap.eth)
Edits the text record of that subdomain to the protocol name and bridge sender contract address of all deployments that were granted BSL licenses
Other Output
Following a successful onchain vote, we will update the forum guidelines for posting with the recommendations contained here.
