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 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:
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.
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 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:
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 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:
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.
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 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:
Kydo from Stanford Blockchain Club here.
Thank you for the thoughtful response @AbdullahUmar . Wrt to "Quality vs Quantity" claim, I will say we might hold different views around individual chain quality and growth potentials. I think that is perfectly fine and we can agree to disagree. I am no expert in growth strategy and will defer this decision, like you have said, to the community, which has welcomed new chains with open arms. I can (and probably is) very much be wrong here.
Kydo from Stanford Blockchain Club here.
Thank you for the thoughtful response @AbdullahUmar . Wrt to "Quality vs Quantity" claim, I will say we might hold different views around individual chain quality and growth potentials. I think that is perfectly fine and we can agree to disagree. I am no expert in growth strategy and will defer this decision, like you have said, to the community, which has welcomed new chains with open arms. I can (and probably is) very much be wrong here.
Probably a larger concern exists about unbranded deployments on Uni v3 contracts made by multiple reliable deployers who want their deployment to be used as the “official” Uniswap
Can you elaborate on what exactly is the problem here? A, B, and C all deployed UniV3 to a chain. What're their incentives to compete for this deployment role? If you are talking about changing things within V3, then I think that's a separate conversation and I think the DAO should have the power to deem a deployment official/recognized even if changes were made to contract logics, agreement with @devenmatthews here.
I think if we want to hire someone to do this, in addition to the community member / committee doing it, I am all for it. However, I am not seeing why WH or LZ would want to dedicate engineering resources to this contract work. And if the incentive is not clear from the contractor side, it is better to not have it.
All in all, I think we are mostly in agreement here in the forum.
I would heed against centering this redesign opportunity around a sense of urgency to deploy across EVM chains as quickly as possible. This process should be left as general as possible to be future-proof.
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
Kydo from Stanford Blockchain Club here.
Thank you for the thoughtful response @AbdullahUmar . Wrt to "Quality vs Quantity" claim, I will say we might hold different views around individual chain quality and growth potentials. I think that is perfectly fine and we can agree to disagree. I am no expert in growth strategy and will defer this decision, like you have said, to the community, which has welcomed new chains with open arms. I can (and probably is) very much be wrong here.
Kydo from Stanford Blockchain Club here.
Thank you for the thoughtful response @AbdullahUmar . Wrt to "Quality vs Quantity" claim, I will say we might hold different views around individual chain quality and growth potentials. I think that is perfectly fine and we can agree to disagree. I am no expert in growth strategy and will defer this decision, like you have said, to the community, which has welcomed new chains with open arms. I can (and probably is) very much be wrong here.
Probably a larger concern exists about unbranded deployments on Uni v3 contracts made by multiple reliable deployers who want their deployment to be used as the “official” Uniswap
Can you elaborate on what exactly is the problem here? A, B, and C all deployed UniV3 to a chain. What're their incentives to compete for this deployment role? If you are talking about changing things within V3, then I think that's a separate conversation and I think the DAO should have the power to deem a deployment official/recognized even if changes were made to contract logics, agreement with @devenmatthews here.
I think if we want to hire someone to do this, in addition to the community member / committee doing it, I am all for it. However, I am not seeing why WH or LZ would want to dedicate engineering resources to this contract work. And if the incentive is not clear from the contractor side, it is better to not have it.
All in all, I think we are mostly in agreement here in the forum.
I would heed against centering this redesign opportunity around a sense of urgency to deploy across EVM chains as quickly as possible. This process should be left as general as possible to be future-proof.
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
I would heed against centering this redesign opportunity around a sense of urgency to deploy across EVM chains as quickly as possible. This process should be left as general as possible to be future-proof.
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
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.
I disagree that Uniswap should push off this conversation. There are greatly interesting projects which offer Uniswap better scalability without targeting EVM, which are ready to begin a deployment process.
Altering code out of requirement is also not a fully encompassing description; Starknet specifically supports EVM byte-code interpretation, but it would be far more efficient to do a native rewrite in Cairo. There are also other major chains which are not EVM-equivalent per say. We may see EVM-compatible chains adopt new precompiles which could offer a Uniswap deployment better efficiencies (this is simply an example scenario). If a team is willing to support proper audits and security measures, and the DAO finds the changes fitting, I see no reason to prevent these activities.
Again, I think the process itself should not limit design space, the DAO should have the freedom to chose its philosophy.
I'm somewhat confused how this fits into the suggested framework. If the UniswapDAO is recognizing deployments AFTER they have been deployed, the community has full clarity over the deployed code. I believe this is the function of the accountability committee to do technical reviews of the deployment process.
Using a 'trusted deployment team' as a heuristic is unnecessary and I would greatly contest any efforts to formalize this. Let anyone deploy, the DAO choses if they want to adopt a deployment.
Creating some pseudo-reliance on specific teams would greatly screw Uniswap deployments onto chains which the mentioned bridge teams support.
I see no reason to include these in the governance process.
This process is most seamless if the deployer is a known, reliable entity.
Kydo from Stanford Blockchain Club here.
I want to draw more attention to this topic as it relates to the core of Uniswap governance for the foreseeable future. Firstly, I would like to express my gratitude to @devenmatthews and @devinwalsh for bringing attention to this topic. You can find @devenmatthews's post here.
In my opinion, there are a few layers to the Post-BSL deployment question:
Kydo from Stanford Blockchain Club here.
I want to draw more attention to this topic as it relates to the core of Uniswap governance for the foreseeable future. Firstly, I would like to express my gratitude to @devenmatthews and @devinwalsh for bringing attention to this topic. You can find @devenmatthews's post here.
In my opinion, there are a few layers to the Post-BSL deployment question:
A "recognized" deployment is a deployment that is recognized by the DAO.
- It MUST be controlled by the Uniswap DAO on Ethereum mainnet based on cross-chain governance standard (in progress by the bridge committee).
- The Uniswap DAO MUST technically review its deployment.
- The Uniswap DAO MUST on-chain approve its deployment.
- It SHOULD be used by Uniswap liquidity providers and users.
- Uniswap developers SHOULD use it as the base infrastructure.
Answer: ONE
I agree with @devenmatthews and @devinwalsh that there should be one "recognized" deployment on every chain (L1/L2/L3...). This lowers the coordination cost between different stakeholders within the Uniswap ecosystem.
Answer: Devin-proposed process.
The current selection process can be summarized as the following:
I believe this flow (FCFS) is sufficient for EVM deployments. However, deployment on non-EVM chains could be problematic as different providers may want to transpile/rewrite Uniswap V3. An application-based selection process may be more appropriate for those deployments.
For EVM chains:
Check out these resources for EVM deployments:
Regarding non-EVM chains, I would defer this discussion to another thread due to the complexity of the issues involved.
Answer: Yes
Allowing changes provides the DAO with flexibility to fix mistakes.
Answer: Follows the selection process
While changing the "recognized" deployment may not occur frequently, I believe the process should be similar to the selection process described above. It is important to follow a clear and transparent process for making changes to the deployment.
In summary, the Uniswap governance community should focus on identifying how many "recognized" deployments are needed per chain and how to select, deploy, and potentially change those deployments. By following a clear process and involving the community, we can ensure that Uniswap remains a trusted and valuable participant in the decentralized finance ecosystem.
Thank you for the feedback, @Kydo.
As we have mentioned before in the Boba vote, we do not believe more numbers of deployments would benefit Uniswap
Kydo from Stanford Blockchain Here.
We are in full agreement with the points @devenmatthews raised around
With regard to @AbdullahUmar 's point, we agree that
Thanks @devinwalsh for formalizing this post into an [RFC] and @Kydo for furthering the conversation.
I would like to throw my support behind creating a new subdomain to track 'official/recongnized deployments' (we should likely settle on a term here). I think the formality of an on-chain vote and registry is important, as well as could be a useful tool for integrators.
Thanks @devinwalsh for formalizing this post into an [RFC] and @Kydo for furthering the conversation.
I would like to throw my support behind creating a new subdomain to track 'official/recongnized deployments' (we should likely settle on a term here). I think the formality of an on-chain vote and registry is important, as well as could be a useful tool for integrators.
One rational in my original post for not making any binding decisions until a deployment has been made was to remove any contingencies that might harm a deployment process.
I'd like to underline that the initial Temperature Check should purely be an analysis of Uniswap's interest in deploying on a specified L1/L2/L3. The proposer should only serve the informal role as being a coordinator, overseeing that the deployment is made and governance process is completed.
The original temperature check should not have any formal ties to the proposing team. The proposing team should not have any technical ownership of the governance process for a deployment on a specific chain. Informally, it should be assumed they will work cordially with a deployment team and help bring the final vote on-chain once a viable deployment has been made.
The Uniswap DAO should have no problem continuing the governance process with a deployer who was not recognized by the original proposer. Situations like this may arise if a proposing team/chosen deployer become unfit to make the deployment. There should be no issue with independent actors making a deployment and continuing the governance process with an official on-chain vote, when the original temperature check was proposed by a different party.
In my post, I try to generalize the 'subjectivity' of a Uniswap v3 deployment.
In summary, the current process recognizes the only nuance of v3 deployments being the bridge they use. Minor changes to the codebase which accomodate different features on EVM chains, as well as the vast subjectivity prevalent in non-EVM deployments are not accounted for (see Starknet proposal).
This was a majority of my reasoning for saying official deployments should be chosen after they have been made, to give the UniswapDAO a full overview of the deployed code they will be recognizing.
This framework would greatly benefit from a sister-framework for analyzing the security of a deployment.
This updated deployment proposal process does not require this sister-framework explicitly, so I'll defer this conversation for now. The Nethermind team is hoping to assist in defining these standards and security practices through the Starknet deployment process (which hopes to utilize this new framework).
As mentioned in my previous post, I think it is important that the UniswapDAO reserves the right to change the official deployment on a specific chain. We can reasonably assume this will not be commonplace (as the coordination cost of integrators and movement of capital would be expensive). Though, this has the irreplaceable affect of allowing the DAO to address security concerns later found in a deployment. This also addresses the idea of subjectivity where a new deployment may capture some features specific to the deployed chain which the DAO wants to capture (and justifies switching cost).
This should be done by making an edit to the new v3-deployments subdomain via an on-chain vote. This change should also require a temperature check (as it has a large switching cost associated), perhaps this needs to be detailed in the updated Cross-chain deployment guide.
I think the post made by @devinwalsh is a fantastic framework, I only wanted to make some things more explicit. Really excited the DAO is preparing for a new world where the v3 codebase is available for use by all.
I would heed against centering this redesign opportunity around a sense of urgency to deploy across EVM chains as quickly as possible. This process should be left as general as possible to be future-proof.
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
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.
I disagree that Uniswap should push off this conversation. There are greatly interesting projects which offer Uniswap better scalability without targeting EVM, which are ready to begin a deployment process.
Altering code out of requirement is also not a fully encompassing description; Starknet specifically supports EVM byte-code interpretation, but it would be far more efficient to do a native rewrite in Cairo. There are also other major chains which are not EVM-equivalent per say. We may see EVM-compatible chains adopt new precompiles which could offer a Uniswap deployment better efficiencies (this is simply an example scenario). If a team is willing to support proper audits and security measures, and the DAO finds the changes fitting, I see no reason to prevent these activities.
Again, I think the process itself should not limit design space, the DAO should have the freedom to chose its philosophy.
I'm somewhat confused how this fits into the suggested framework. If the UniswapDAO is recognizing deployments AFTER they have been deployed, the community has full clarity over the deployed code. I believe this is the function of the accountability committee to do technical reviews of the deployment process.
Using a 'trusted deployment team' as a heuristic is unnecessary and I would greatly contest any efforts to formalize this. Let anyone deploy, the DAO choses if they want to adopt a deployment.
Creating some pseudo-reliance on specific teams would greatly screw Uniswap deployments onto chains which the mentioned bridge teams support.
I see no reason to include these in the governance process.
This process is most seamless if the deployer is a known, reliable entity.
Kydo from Stanford Blockchain Club here.
I want to draw more attention to this topic as it relates to the core of Uniswap governance for the foreseeable future. Firstly, I would like to express my gratitude to @devenmatthews and @devinwalsh for bringing attention to this topic. You can find @devenmatthews's post here.
In my opinion, there are a few layers to the Post-BSL deployment question:
Kydo from Stanford Blockchain Club here.
I want to draw more attention to this topic as it relates to the core of Uniswap governance for the foreseeable future. Firstly, I would like to express my gratitude to @devenmatthews and @devinwalsh for bringing attention to this topic. You can find @devenmatthews's post here.
In my opinion, there are a few layers to the Post-BSL deployment question:
A "recognized" deployment is a deployment that is recognized by the DAO.
- It MUST be controlled by the Uniswap DAO on Ethereum mainnet based on cross-chain governance standard (in progress by the bridge committee).
- The Uniswap DAO MUST technically review its deployment.
- The Uniswap DAO MUST on-chain approve its deployment.
- It SHOULD be used by Uniswap liquidity providers and users.
- Uniswap developers SHOULD use it as the base infrastructure.
Answer: ONE
I agree with @devenmatthews and @devinwalsh that there should be one "recognized" deployment on every chain (L1/L2/L3...). This lowers the coordination cost between different stakeholders within the Uniswap ecosystem.
Answer: Devin-proposed process.
The current selection process can be summarized as the following:
I believe this flow (FCFS) is sufficient for EVM deployments. However, deployment on non-EVM chains could be problematic as different providers may want to transpile/rewrite Uniswap V3. An application-based selection process may be more appropriate for those deployments.
For EVM chains:
Check out these resources for EVM deployments:
Regarding non-EVM chains, I would defer this discussion to another thread due to the complexity of the issues involved.
Answer: Yes
Allowing changes provides the DAO with flexibility to fix mistakes.
Answer: Follows the selection process
While changing the "recognized" deployment may not occur frequently, I believe the process should be similar to the selection process described above. It is important to follow a clear and transparent process for making changes to the deployment.
In summary, the Uniswap governance community should focus on identifying how many "recognized" deployments are needed per chain and how to select, deploy, and potentially change those deployments. By following a clear process and involving the community, we can ensure that Uniswap remains a trusted and valuable participant in the decentralized finance ecosystem.
Thank you for the feedback, @Kydo.
As we have mentioned before in the Boba vote, we do not believe more numbers of deployments would benefit Uniswap
Kydo from Stanford Blockchain Here.
We are in full agreement with the points @devenmatthews raised around
With regard to @AbdullahUmar 's point, we agree that
Thanks @devinwalsh for formalizing this post into an [RFC] and @Kydo for furthering the conversation.
I would like to throw my support behind creating a new subdomain to track 'official/recongnized deployments' (we should likely settle on a term here). I think the formality of an on-chain vote and registry is important, as well as could be a useful tool for integrators.
Thanks @devinwalsh for formalizing this post into an [RFC] and @Kydo for furthering the conversation.
I would like to throw my support behind creating a new subdomain to track 'official/recongnized deployments' (we should likely settle on a term here). I think the formality of an on-chain vote and registry is important, as well as could be a useful tool for integrators.
One rational in my original post for not making any binding decisions until a deployment has been made was to remove any contingencies that might harm a deployment process.
I'd like to underline that the initial Temperature Check should purely be an analysis of Uniswap's interest in deploying on a specified L1/L2/L3. The proposer should only serve the informal role as being a coordinator, overseeing that the deployment is made and governance process is completed.
The original temperature check should not have any formal ties to the proposing team. The proposing team should not have any technical ownership of the governance process for a deployment on a specific chain. Informally, it should be assumed they will work cordially with a deployment team and help bring the final vote on-chain once a viable deployment has been made.
The Uniswap DAO should have no problem continuing the governance process with a deployer who was not recognized by the original proposer. Situations like this may arise if a proposing team/chosen deployer become unfit to make the deployment. There should be no issue with independent actors making a deployment and continuing the governance process with an official on-chain vote, when the original temperature check was proposed by a different party.
In my post, I try to generalize the 'subjectivity' of a Uniswap v3 deployment.
In summary, the current process recognizes the only nuance of v3 deployments being the bridge they use. Minor changes to the codebase which accomodate different features on EVM chains, as well as the vast subjectivity prevalent in non-EVM deployments are not accounted for (see Starknet proposal).
This was a majority of my reasoning for saying official deployments should be chosen after they have been made, to give the UniswapDAO a full overview of the deployed code they will be recognizing.
This framework would greatly benefit from a sister-framework for analyzing the security of a deployment.
This updated deployment proposal process does not require this sister-framework explicitly, so I'll defer this conversation for now. The Nethermind team is hoping to assist in defining these standards and security practices through the Starknet deployment process (which hopes to utilize this new framework).
As mentioned in my previous post, I think it is important that the UniswapDAO reserves the right to change the official deployment on a specific chain. We can reasonably assume this will not be commonplace (as the coordination cost of integrators and movement of capital would be expensive). Though, this has the irreplaceable affect of allowing the DAO to address security concerns later found in a deployment. This also addresses the idea of subjectivity where a new deployment may capture some features specific to the deployed chain which the DAO wants to capture (and justifies switching cost).
This should be done by making an edit to the new v3-deployments subdomain via an on-chain vote. This change should also require a temperature check (as it has a large switching cost associated), perhaps this needs to be detailed in the updated Cross-chain deployment guide.
I think the post made by @devinwalsh is a fantastic framework, I only wanted to make some things more explicit. Really excited the DAO is preparing for a new world where the v3 codebase is available for use by all.
Thank you for the feedback, @Kydo.
As we have mentioned before in the Boba vote, we do not believe more numbers of deployments would benefit Uniswap
I would agree that quality is a paramount concern for selecting where we decide to deploy. We at Blockchain at Michigan have turned down a handful of proposal sponsorships and proposal drafting requests because we don't believe that it's in the best interest of Uniswap. I do think that there are chains, however, meeting the quality criteria--like Polkadot, Cosmos, Near--that Uni should aim to attain a foothold in. Even if there is a lesser degree of activity on those chains, a lot of these deployments are meant to be a way for Uniswap to not miss out on promising markets. Expansion during a less active time is one way to position the protocol early on prior to a future market resurgence. Plus, such relationships are often a two way street. The presence of Uniswap on X chain can help incentivize builders and users to partake more actively on X chains. Uniswap is a liquidity facilitator for protocols and its presence helps prop up ecosystems. There is also a question of the extent of expanse Uni has on a chain. Like does Uni go to Kava or Evmos for access to Cosmos?
And at the end of the day, it's ultimately the DAO's decision to decide if certain deployments should go through. If we look empirically at stakeholders' voting decisions and a general outlook on sentiment, most stakeholders are generally in favor of more deployments. But, yes, we will soon reach a plateau where we exhaust expanding into promising chains--just don't think we're there yet.
Another concern is how willing Uniswap Labs will be regarding expending its resources on certain front end integrations. To your point about Boba, Uni Labs would side with you, Kydo, on this topic. They do not presently see Boba as a chain that needs to be integrated into the front end to make Uni more robust. This leads to questions about how much say does the DAO really have over deployment decisions due to Labs' gatekeeping.
time to focus on long-term visions around zkEVM transpiling or rewriting V3 in different languages.
In full agreement with the above.
The “real” Uniswap is the one that can use Uniswap branded assets. Eg, Sushiswap uses Uniswap’s code but not Uniswap’s brand.
100%. New DEXs will be rebranded versions of Uniswap, with copied underlying code. I suppose "real" Uniswap would not be a large cause for concern due to distinctive branding. Probably a larger concern exists about unbranded deployments on Uni v3 contracts made by multiple reliable deployers who want their deployment to be used as the "official" Uniswap. Even this may not turn out to be a prominent concern.
The committee would essentially handle deployment verification with the open-source CLI tools I have listed here:
This is of course the preferred method for assessment, although I am not entirely against attaining help from third parties who've established a track record and are known for quality work. Nonetheless, if this process can be handled by the committee effectively, sounds good to me.
Summary: We're on the same page regarding the concerns you pointed out. The only slight separation is regarding the desire to deploy on more chains. While considering quality of chains is important, we're still of the opinion that there are beneficial deployments to be completed for the sake of positioning Uniswap advantageously. But yes, the list of ecosystems that we hope to expand to, upon further due diligence, may turn out to be less in quantity than we expect. We also recognize that there is certainly a trade-off in the topics the DAO focuses on, and an over saturation of deployment conversations could take away attention from more prudent efforts.
Kydo from Stanford Blockchain Here.
We are in full agreement with the points @devenmatthews raised around
With regard to @AbdullahUmar 's point, we agree that
However, there are a few things we disagree on:
As we have mentioned before in the Boba vote, we do not believe more numbers of deployments would benefit Uniswap. Quality of deployment is a lot more important than quantity.
In our view, we have deployed on the major chains from a growth perspective. Now, it is our time to focus on long-term visions around zkEVM transpiling or rewriting V3 in different languages. Therefore, governance around post-BSL should focus more on these topics instead of GTM to more chains.
Moreover, we should be careful of the Uniswap brand being associated with other chains during this deployment process. Most chains only sound great on paper.
I think this is a valid question. However, this question is less about code-licensing, but more about brand asset control. The "real" Uniswap is the one that can use Uniswap branded assets. Eg, Sushiswap uses Uniswap's code but not Uniswap's brand.
Therefore, the user would not be confused post-BSL to find the "real" Uniswap even if there are many forks.
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.
Currently, the DAO is in the process of forming the accountability committee (which I am a part of). The committee would essentially handle deployment verification with the open-source CLI tools I have listed here:
The committee could also work with the foundation in the future to develop easier testing tools for the community. The current testing toolkit is already intuitive enough for the technical members to use by themselves.
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.
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.
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.
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.
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:
Thank you for the feedback, @Kydo.
As we have mentioned before in the Boba vote, we do not believe more numbers of deployments would benefit Uniswap
I would agree that quality is a paramount concern for selecting where we decide to deploy. We at Blockchain at Michigan have turned down a handful of proposal sponsorships and proposal drafting requests because we don't believe that it's in the best interest of Uniswap. I do think that there are chains, however, meeting the quality criteria--like Polkadot, Cosmos, Near--that Uni should aim to attain a foothold in. Even if there is a lesser degree of activity on those chains, a lot of these deployments are meant to be a way for Uniswap to not miss out on promising markets. Expansion during a less active time is one way to position the protocol early on prior to a future market resurgence. Plus, such relationships are often a two way street. The presence of Uniswap on X chain can help incentivize builders and users to partake more actively on X chains. Uniswap is a liquidity facilitator for protocols and its presence helps prop up ecosystems. There is also a question of the extent of expanse Uni has on a chain. Like does Uni go to Kava or Evmos for access to Cosmos?
And at the end of the day, it's ultimately the DAO's decision to decide if certain deployments should go through. If we look empirically at stakeholders' voting decisions and a general outlook on sentiment, most stakeholders are generally in favor of more deployments. But, yes, we will soon reach a plateau where we exhaust expanding into promising chains--just don't think we're there yet.
Another concern is how willing Uniswap Labs will be regarding expending its resources on certain front end integrations. To your point about Boba, Uni Labs would side with you, Kydo, on this topic. They do not presently see Boba as a chain that needs to be integrated into the front end to make Uni more robust. This leads to questions about how much say does the DAO really have over deployment decisions due to Labs' gatekeeping.
time to focus on long-term visions around zkEVM transpiling or rewriting V3 in different languages.
In full agreement with the above.
The “real” Uniswap is the one that can use Uniswap branded assets. Eg, Sushiswap uses Uniswap’s code but not Uniswap’s brand.
100%. New DEXs will be rebranded versions of Uniswap, with copied underlying code. I suppose "real" Uniswap would not be a large cause for concern due to distinctive branding. Probably a larger concern exists about unbranded deployments on Uni v3 contracts made by multiple reliable deployers who want their deployment to be used as the "official" Uniswap. Even this may not turn out to be a prominent concern.
The committee would essentially handle deployment verification with the open-source CLI tools I have listed here:
This is of course the preferred method for assessment, although I am not entirely against attaining help from third parties who've established a track record and are known for quality work. Nonetheless, if this process can be handled by the committee effectively, sounds good to me.
Summary: We're on the same page regarding the concerns you pointed out. The only slight separation is regarding the desire to deploy on more chains. While considering quality of chains is important, we're still of the opinion that there are beneficial deployments to be completed for the sake of positioning Uniswap advantageously. But yes, the list of ecosystems that we hope to expand to, upon further due diligence, may turn out to be less in quantity than we expect. We also recognize that there is certainly a trade-off in the topics the DAO focuses on, and an over saturation of deployment conversations could take away attention from more prudent efforts.
Kydo from Stanford Blockchain Here.
We are in full agreement with the points @devenmatthews raised around
With regard to @AbdullahUmar 's point, we agree that
However, there are a few things we disagree on:
As we have mentioned before in the Boba vote, we do not believe more numbers of deployments would benefit Uniswap. Quality of deployment is a lot more important than quantity.
In our view, we have deployed on the major chains from a growth perspective. Now, it is our time to focus on long-term visions around zkEVM transpiling or rewriting V3 in different languages. Therefore, governance around post-BSL should focus more on these topics instead of GTM to more chains.
Moreover, we should be careful of the Uniswap brand being associated with other chains during this deployment process. Most chains only sound great on paper.
I think this is a valid question. However, this question is less about code-licensing, but more about brand asset control. The "real" Uniswap is the one that can use Uniswap branded assets. Eg, Sushiswap uses Uniswap's code but not Uniswap's brand.
Therefore, the user would not be confused post-BSL to find the "real" Uniswap even if there are many forks.
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.
Currently, the DAO is in the process of forming the accountability committee (which I am a part of). The committee would essentially handle deployment verification with the open-source CLI tools I have listed here:
The committee could also work with the foundation in the future to develop easier testing tools for the community. The current testing toolkit is already intuitive enough for the technical members to use by themselves.
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.
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.
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.
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.
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:
