Hi everyone,
First a quick personal update. I'm super excited to announce that I've joined the Uniswap Foundation as Governance Lead. There's a ton of interesting and important work going on and I'm really excited to dig in. With that in mind, read on for my first temp check...
Snapshot Update: On-chain vote
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:
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:
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.
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 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:
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:
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.
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.
Code Pending a successful Snapshot vote, we will move forward with an on-chain vote that:
v3-deployments.uniswap.eth)Other Output Following a successful onchain vote, we will update the forum guidelines for posting with the recommendations contained here.
To voice your opinion on this proposal, please visit the Snapshot here.
Hi everyone,
First a quick personal update. I'm super excited to announce that I've joined the Uniswap Foundation as Governance Lead. There's a ton of interesting and important work going on and I'm really excited to dig in. With that in mind, read on for my first temp check...
Snapshot Update: On-chain vote
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:
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:
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.
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 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:
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:
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.
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.
Code Pending a successful Snapshot vote, we will move forward with an on-chain vote that:
v3-deployments.uniswap.eth)Other Output Following a successful onchain vote, we will update the forum guidelines for posting with the recommendations contained here.
To voice your opinion on this proposal, please visit the Snapshot here.
Great work, this will provide clarity onto the deployments under the license. I wonder how i can access this sub-domain. How does this work in practice? For example i know Pangolin Exchange use Uni V3 code for their concentrated AMM but there is no way to verify apart from comparing the code or reading their medium article where they explain it. I'd appreciate your help here; thanks.
By the way, this is great that the tracking of Uniswap on different chain happens with v2 deployments as well. Refer to here
Great work, this will provide clarity onto the deployments under the license. I wonder how i can access this sub-domain. How does this work in practice? For example i know Pangolin Exchange use Uni V3 code for their concentrated AMM but there is no way to verify apart from comparing the code or reading their medium article where they explain it. I'd appreciate your help here; thanks.
By the way, this is great that the tracking of Uniswap on different chain happens with v2 deployments as well. Refer to here
Kydo from Stanford Blockchain Club here.
Thank you @eek637 for compiling this.
I have a few comments carried over from the discussions in the [RFC] Post-BSL Cross-chain Deployment Process & New Uniswap.eth Subdomain.
Kydo from Stanford Blockchain Club here.
Thank you @eek637 for compiling this.
I have a few comments carried over from the discussions in the [RFC] Post-BSL Cross-chain Deployment Process & New Uniswap.eth Subdomain.
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.
Following @AbdullahUmar 's comment around speed, I do believe in the post-BSL world, things can move faster with new V3 deployments. However, I do not see how the current proposed process can be speeded up (currently it is one week). @AbdullahUmar what do you think?
I believe this "list of actors" should be at the top of each BSL V3 proposal given its importance. It will drastically help community members to save time reading these proposals. If a part is not decided, then it should be left empty. Moreover, by having this at the top of each proposal, it highlights the points raised by @devenmatthews such as proposer-deployer separation.
Lastly, I think we should specify a mechanism to change v3 domain name in case of deployment errors. I think the changing of a canonical deployment can only happen when there are significant errors in the deployed contract.
Once again, thank you so much for compiling this!
Kydo from Stanford Blockchain Club here.
Thank you @eek637 for compiling this.
I have a few comments carried over from the discussions in the [RFC] Post-BSL Cross-chain Deployment Process & New Uniswap.eth Subdomain.
Kydo from Stanford Blockchain Club here.
Thank you @eek637 for compiling this.
I have a few comments carried over from the discussions in the [RFC] Post-BSL Cross-chain Deployment Process & New Uniswap.eth Subdomain.
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.
Following @AbdullahUmar 's comment around speed, I do believe in the post-BSL world, things can move faster with new V3 deployments. However, I do not see how the current proposed process can be speeded up (currently it is one week). @AbdullahUmar what do you think?
I believe this "list of actors" should be at the top of each BSL V3 proposal given its importance. It will drastically help community members to save time reading these proposals. If a part is not decided, then it should be left empty. Moreover, by having this at the top of each proposal, it highlights the points raised by @devenmatthews such as proposer-deployer separation.
Lastly, I think we should specify a mechanism to change v3 domain name in case of deployment errors. I think the changing of a canonical deployment can only happen when there are significant errors in the deployed contract.
Once again, thank you so much for compiling this!
The pangolin example is actually a great one - that is not a canonical deployment. There will only be one canonical deployment per chain, and that deployment's contracts will match those in the Uniswap V3 repo exactly (and be verified on that chain's block explorer).
You can access the v3deployments.uniswap.eth subname and see the text records here.
The pangolin example is actually a great one - that is not a canonical deployment. There will only be one canonical deployment per chain, and that deployment's contracts will match those in the Uniswap V3 repo exactly (and be verified on that chain's block explorer).
You can access the v3deployments.uniswap.eth subname and see the text records here.
