- Uniswap v3’s BSL expires this 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 recommended approach to Uniswap governance, with guidance to stakeholders on how they might go through the governance process. This approach allows 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 approach 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 the same, with some specific recommendations in approach to:
- Take into account the fact that deployments may now be done prior to the Uniswap governance process being completed to identify it an official deployment.
- Allow 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 we propose, v3-deployments.uniswap.eth, to track official deployments of Uniswap v3 on other chains. This RFC is kicking off the governance process to do that.
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.
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 recommendations being made to the stakeholders on how they approach 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.
- 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.
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.
- 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 approach 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.
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 RFC is kicking off that process, as the new subdomain can only be created through an on-chain governance vote.
If and when the on-chain vote passes to create this new subdomain, we will pre-populate deployment information for all deployments which have already been “approved” by the DAO (i.e., on Polygon, Optimism, Arbitrum, etc.).
Over the next week, we are excited to hear your feedback and integrate it into this proposal. After a week, if there is no strong disagreement from the community, we will move to a Temperature Check.
If and when the proposal successfully passes:
- V3-deployments.uniswap.eth will have been created, and it will have been populated with information on deployments which have already been approved by the DAO
- The UF will update its cross-chain deployment guide to incorporate these recommendations
- The UF will direct all interested in launching Uniswap v3 on new chains after the BSL expiry to this process