Hi all. This post is meant to open conversation about Uniswap DAO's deployment proposal process and suggest some specific improvements. The discussion below explores a potential reframing of the process following the expiration of the Uniswap v3 BSL.
UniswapFDN recently created the Bridge Assessment Committee, tasked with both doing individual analysis on specific bridging solutions (and their suitability for governance message passing) as well as developing an agnostic framework for analyzing bridge solutions.
This arose after there was some dispute over which bridge provider should be used for a BNB deployment, where the community was supportive of deploying on BNB chain but had no clear consensus on which bridge was the most suitable.
The current process requires that a deployer specifies which chain they wish to deploy on, and which bridge they will use to support this deployment. This proposal text (i.e. the specified bridge provider) becomes conditions of the BSL exemption, hence must be specified prior to deploying.
The current process for deployment proposals implies there are three distinct choices UniswapDAO must make
Should we deploy on chain X
Does the DAO trust the proposing team to deploy on chain X
Is the chosen bridge suitable for the Uniswap community's standards
I'd hope to see the DAO adopt a deployment proposal framework that recognizes and allows for more nuance amongst deployments, greater flexibility for the deployment team, and a strong notion of official deployments following the flood of Uniswap v3 forks expected to arise after the BSL expiry.
The current deployment proposal process is formally framed around supplying BSL exemptions to deploying teams. The passing of a deployment proposal informally implies Uniswap governance will recognize this deployment by sending governance proposals through the message passing bridge (and potentially other collaborations like foundation supported liquidity mining programs, grants programs for developing on specific deployments, etc.). Following the expiry, the process must be reframed so the latter becomes formally assured.
Currently, all deployments of Uniswap v3 code legally should be approved by the DAO, making it very straightforward to recognize deployments as official. This is going to change shortly after the BSL expiry.
As deploying Uniswap v3 code becomes permissionless, I propose we develop a framework where the DAO selects official deployments (only one allowed per chain). This means the official deployment isn't simply which deployer passed a proposal first, but is retroactively recognized by the DAO and can be changes at any time.
Why is this neccessary?
Mostly because the current framework relies on the assumption that the only nuance amongst deployments is which bridge provider is used. I think this assumption is limiting for the DAO, and boxes in what we consider a Uniswap deployments.
Conversation around this arose in the Starknet deployment proposal, which was proposed as the first non-EVM equivalent deployment of Uniswap v3. This conversation is relevant because the process in which Uniswap is deployed on Starknet (or any non-EVM equivalent) becomes extremely important: is it transpiled using the Warp transpiler, deployed using a bytecode interpreter like Kakarot, or is it a completely native rewrite. All of these proposed deployments make different security/efficiency tradeoffs. Furthermore, even after the deployment is made, the DAO currently has no way to analyze the deployment retroactively before making it official since the proposal process happens prior to contracts actually being deployed.
This conversation is relevant for native EVM deployments as well. Recognizing the non-fungibility amongst Uniswap deployments may open up the design space for Uniswap's multichain ecosystem. I'd be welcoming of community members tweaking the v3 codebase to achieve better gas efficiencies or leverage specific precompiles/features available on the destination chain.
Forum discussion created by anyone to discuss the DAOs desire to deploy on the destination chain and potential bridge options. If enough traction is gained, the Bridge Assessment Committee should provide specific guidance on which bridge options they find suitable. Deployment teams can volunteer themselves to handle the deployment, as well as detail their plan to deploy (such as any tweaks to the codebase, proposed liq. incentives, etc.). This discussion should not bind the team to any terms, but act as guidance and an open communication channel (giving the team some assurance their deployment will be supported if they abide by the terms they made a soft commitment too within' reason).
Temperature Check on if the DAO wants to deploy on the destination chain. This should purley be an assessment of the desination chain (liquidity, security, alignment with Uniswap visions, etc.). This vote should not specify the bridge used, nor the deploying team. This is to act as assurance to anyone who is working on a deployment that the DAO is interested in the destination chain.
Deployments should only be recognized as official AFTER they have been deployed. This should happen via an on-chain vote which sends a message to the deployment and marks this deployment as official via an on-chain registry on L1. This registry could potentially be used by Uniswap Labs to inform listings on the official frontend. The vote to recognize a specific deployment should likely undergo a temp. + consensus check as well.
Step 3 can be repeated to change the official deployment of Uniswap on a specific chain. I think it is unlikely this option will be used (as it will cause a mass migration of liquidity), but the option should be there if vulnerabilities are found in the current deployment or a new deployment is sufficiently more favorable to justify switching cost.
Healthy competition amongst deployment teams- we currently see deployment proposals which have been approved by governance but not acted upon for months on end. Because the deployment team was specified beforehand, there is no sense of urgency to deploy. This proposed process means the DAO does not commit to a specific deployer (or bridge) until an actual deployment exists.
Flexibility regarding bridge providers- In light of several major bridge hacks over the last years, I think it is important to allow deployment teams to remain completely flexible/dynamic and not bound to a specific bridge (or any deployment conditions for that matter). There will still be provided guidance by the Bridge Assessment Committee (and community members), but these assessments are not binding. In the current process, if the specified bridge is hacked (or deemed unsuitable) after a proposal passes but before the deployment is made, a new proposal is required. I believe the off-chain discussion via the forum will provide the deployment team with adequate assurance that the work they are doing will likely be recognized unless there is strong deviation or deep flaws in their deployment. This model only makes deployments official AFTER the contracts are deployed, so any last minute decisions made by the deployment team will undergo final review by governance.
Accountability and assurance - We've historically seen proposals which specified conditions of deployment (like grants programs), that were not properly followed through with. By approving deployments after they have been made, the DAO has no reason to place trust within' deploying organizations, and can verify all conditions have been met before official choosing to support deployment.
Inclusion of altered codebases- since deployments which make adaptations or improvements to the Uniswap codebase have a strong sense of subjectivity, a deployment process which accounts for gives Uniswap DAO has a sufficient framework for supporting such deployments if it chooses.
Relevant Links Cross-Chain Deployment Guide Deployment Proposal Template
Hi all. This post is meant to open conversation about Uniswap DAO's deployment proposal process and suggest some specific improvements. The discussion below explores a potential reframing of the process following the expiration of the Uniswap v3 BSL.
UniswapFDN recently created the Bridge Assessment Committee, tasked with both doing individual analysis on specific bridging solutions (and their suitability for governance message passing) as well as developing an agnostic framework for analyzing bridge solutions.
This arose after there was some dispute over which bridge provider should be used for a BNB deployment, where the community was supportive of deploying on BNB chain but had no clear consensus on which bridge was the most suitable.
The current process requires that a deployer specifies which chain they wish to deploy on, and which bridge they will use to support this deployment. This proposal text (i.e. the specified bridge provider) becomes conditions of the BSL exemption, hence must be specified prior to deploying.
The current process for deployment proposals implies there are three distinct choices UniswapDAO must make
Should we deploy on chain X
Does the DAO trust the proposing team to deploy on chain X
Is the chosen bridge suitable for the Uniswap community's standards
I'd hope to see the DAO adopt a deployment proposal framework that recognizes and allows for more nuance amongst deployments, greater flexibility for the deployment team, and a strong notion of official deployments following the flood of Uniswap v3 forks expected to arise after the BSL expiry.
The current deployment proposal process is formally framed around supplying BSL exemptions to deploying teams. The passing of a deployment proposal informally implies Uniswap governance will recognize this deployment by sending governance proposals through the message passing bridge (and potentially other collaborations like foundation supported liquidity mining programs, grants programs for developing on specific deployments, etc.). Following the expiry, the process must be reframed so the latter becomes formally assured.
Currently, all deployments of Uniswap v3 code legally should be approved by the DAO, making it very straightforward to recognize deployments as official. This is going to change shortly after the BSL expiry.
As deploying Uniswap v3 code becomes permissionless, I propose we develop a framework where the DAO selects official deployments (only one allowed per chain). This means the official deployment isn't simply which deployer passed a proposal first, but is retroactively recognized by the DAO and can be changes at any time.
Why is this neccessary?
Mostly because the current framework relies on the assumption that the only nuance amongst deployments is which bridge provider is used. I think this assumption is limiting for the DAO, and boxes in what we consider a Uniswap deployments.
Conversation around this arose in the Starknet deployment proposal, which was proposed as the first non-EVM equivalent deployment of Uniswap v3. This conversation is relevant because the process in which Uniswap is deployed on Starknet (or any non-EVM equivalent) becomes extremely important: is it transpiled using the Warp transpiler, deployed using a bytecode interpreter like Kakarot, or is it a completely native rewrite. All of these proposed deployments make different security/efficiency tradeoffs. Furthermore, even after the deployment is made, the DAO currently has no way to analyze the deployment retroactively before making it official since the proposal process happens prior to contracts actually being deployed.
This conversation is relevant for native EVM deployments as well. Recognizing the non-fungibility amongst Uniswap deployments may open up the design space for Uniswap's multichain ecosystem. I'd be welcoming of community members tweaking the v3 codebase to achieve better gas efficiencies or leverage specific precompiles/features available on the destination chain.
Forum discussion created by anyone to discuss the DAOs desire to deploy on the destination chain and potential bridge options. If enough traction is gained, the Bridge Assessment Committee should provide specific guidance on which bridge options they find suitable. Deployment teams can volunteer themselves to handle the deployment, as well as detail their plan to deploy (such as any tweaks to the codebase, proposed liq. incentives, etc.). This discussion should not bind the team to any terms, but act as guidance and an open communication channel (giving the team some assurance their deployment will be supported if they abide by the terms they made a soft commitment too within' reason).
Temperature Check on if the DAO wants to deploy on the destination chain. This should purley be an assessment of the desination chain (liquidity, security, alignment with Uniswap visions, etc.). This vote should not specify the bridge used, nor the deploying team. This is to act as assurance to anyone who is working on a deployment that the DAO is interested in the destination chain.
Deployments should only be recognized as official AFTER they have been deployed. This should happen via an on-chain vote which sends a message to the deployment and marks this deployment as official via an on-chain registry on L1. This registry could potentially be used by Uniswap Labs to inform listings on the official frontend. The vote to recognize a specific deployment should likely undergo a temp. + consensus check as well.
Step 3 can be repeated to change the official deployment of Uniswap on a specific chain. I think it is unlikely this option will be used (as it will cause a mass migration of liquidity), but the option should be there if vulnerabilities are found in the current deployment or a new deployment is sufficiently more favorable to justify switching cost.
Healthy competition amongst deployment teams- we currently see deployment proposals which have been approved by governance but not acted upon for months on end. Because the deployment team was specified beforehand, there is no sense of urgency to deploy. This proposed process means the DAO does not commit to a specific deployer (or bridge) until an actual deployment exists.
Flexibility regarding bridge providers- In light of several major bridge hacks over the last years, I think it is important to allow deployment teams to remain completely flexible/dynamic and not bound to a specific bridge (or any deployment conditions for that matter). There will still be provided guidance by the Bridge Assessment Committee (and community members), but these assessments are not binding. In the current process, if the specified bridge is hacked (or deemed unsuitable) after a proposal passes but before the deployment is made, a new proposal is required. I believe the off-chain discussion via the forum will provide the deployment team with adequate assurance that the work they are doing will likely be recognized unless there is strong deviation or deep flaws in their deployment. This model only makes deployments official AFTER the contracts are deployed, so any last minute decisions made by the deployment team will undergo final review by governance.
Accountability and assurance - We've historically seen proposals which specified conditions of deployment (like grants programs), that were not properly followed through with. By approving deployments after they have been made, the DAO has no reason to place trust within' deploying organizations, and can verify all conditions have been met before official choosing to support deployment.
Inclusion of altered codebases- since deployments which make adaptations or improvements to the Uniswap codebase have a strong sense of subjectivity, a deployment process which accounts for gives Uniswap DAO has a sufficient framework for supporting such deployments if it chooses.
Relevant Links Cross-Chain Deployment Guide Deployment Proposal Template
I know this was posted a while back but I’ve been reading through it and I wanted to put in my 2 cents. Well said Toby and I agree 100% with you that
I know this was posted a while back but I’ve been reading through it and I wanted to put in my 2 cents. Well said Toby and I agree 100% with you that
This post about 'official deployments' would be related to which deployments the Uniswap DAO choses to govern.
Some examples of cross-chain governance proposals can be found here:
This post about 'official deployments' would be related to which deployments the Uniswap DAO choses to govern.
Some examples of cross-chain governance proposals can be found here:
Uniswap's experimentation with cross chain governance is in it's infancy. I would hope there still is still a valid way for deployments to be recognized and included under governance's control following the end of the BSL (and hence sunset of current deployment proposal framework). If Uniswap wishes to continue cross-chain governance, I believe an updated framework for recognizing deployments is necessary.
I understand the DAO has no technical control over Uniswap branding. This is not the point of this discussion, though I imagine some notion of DAO recognized deployments could act as guidance for Uniswap Labs choosing which deployments are listed on the frontend (this is only a potential effect, and not the motivation behind this post).
Conversation about migrating Uniswap branding to be under control of the DAO is very attractive, and I believe would be a strong signal of Uniswap labs commitment to decentralization and acting as a public good. Would be interested to hear UL legal team weighing in here.
Though, this is not something the DAO has direct influence over, while recognizing deployments for L1 governance maintenance is.
Too sleepy to go through this but here is a similar post I made about this topic a few days ago regarding the Gnosis deployment https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-gnosis-chain-with-different-bridge-provider/20724/8?u=devenmatthews
This post about 'official deployments' would be related to which deployments the Uniswap DAO choses to govern.
Some examples of cross-chain governance proposals can be found here:
This post about 'official deployments' would be related to which deployments the Uniswap DAO choses to govern.
Some examples of cross-chain governance proposals can be found here:
Uniswap's experimentation with cross chain governance is in it's infancy. I would hope there still is still a valid way for deployments to be recognized and included under governance's control following the end of the BSL (and hence sunset of current deployment proposal framework). If Uniswap wishes to continue cross-chain governance, I believe an updated framework for recognizing deployments is necessary.
I understand the DAO has no technical control over Uniswap branding. This is not the point of this discussion, though I imagine some notion of DAO recognized deployments could act as guidance for Uniswap Labs choosing which deployments are listed on the frontend (this is only a potential effect, and not the motivation behind this post).
Conversation about migrating Uniswap branding to be under control of the DAO is very attractive, and I believe would be a strong signal of Uniswap labs commitment to decentralization and acting as a public good. Would be interested to hear UL legal team weighing in here.
Though, this is not something the DAO has direct influence over, while recognizing deployments for L1 governance maintenance is.
Too sleepy to go through this but here is a similar post I made about this topic a few days ago regarding the Gnosis deployment https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-gnosis-chain-with-different-bridge-provider/20724/8?u=devenmatthews
Thanks for the post Deven. I agree that "recognized deployments" are going to be important after BSL expires. The elephant in the room missing from the discussion is the Uniswap trademark and brand assets.
As I understand it the "official deployments" idea you're outlining effectively a franchising program. The desired system behavior, from my point of view is:
Thanks for the post Deven. I agree that "recognized deployments" are going to be important after BSL expires. The elephant in the room missing from the discussion is the Uniswap trademark and brand assets.
As I understand it the "official deployments" idea you're outlining effectively a franchising program. The desired system behavior, from my point of view is:
Use of the Uniswap brand needs to have functional equivalence to being a recognized deployment. Uniswap stands for quality, security, etc. A risk scenario as it stands is someone else going ahead with deploying a Uniswap Chain built on Cosmos SDK without our permission and fully, or someone deploying a "Uniswap" on an L2 with insufficiently secured bridge. It's obvious that these are unstrategic and actively harmful for the brand.
In short, the expiry of BSL turns deployments from a code licensing issue into a brand licensing one.
We are currently not set up for success when it comes to brand licensing issues. To the extent of my knowledge, Uniswap Labs fully owns the trademark of the Uniswap name and all other brand property. The trademark policy is visible here:
You may do the following without receiving specific permission from Uniswap Labs:
- Use Uniswap wordmarks in text to truthfully refer to and/or link to unmodified Uniswap smart contracts, protocols, interfaces, programs, products, services and technologies (“Uniswap software”).
- Use the Uniswap wordmarks to truthfully describe modified versions of Uniswap software that you may create or make available. For example, you may say “This software is derived from Uniswap software.” or “This service uses software derived from Uniswap software.”
- Use the Uniswap logos in software or aggregators that integrate with Uniswap software to truthfully refer to, and, where possible, link to the applicable Uniswap software hosted on the Ethereum blockchain.
- Use Uniswap wordmarks to clearly signal to users that there is no affiliation with or endorsement by Uniswap Labs.
- Follow the terms of the open source licenses for Uniswap software.
This is a very permissive policy and one that largely would undermine the goals of the "official deployments" strategy you've outlined above. Unlike BSL (whose expiry date I've been told is firm and irrevocable) Uniswap Labs' trademark policy is malleable. I suggest that we continue these discussions Marvin and the Uniswap Labs legal team and consider putting the Uniswap trademark in the possession of the DAO. Without this I'm not sure what teeth the "official deployments" strategy actually has.
Thanks for the post Deven. I agree that "recognized deployments" are going to be important after BSL expires. The elephant in the room missing from the discussion is the Uniswap trademark and brand assets.
As I understand it the "official deployments" idea you're outlining effectively a franchising program. The desired system behavior, from my point of view is:
Thanks for the post Deven. I agree that "recognized deployments" are going to be important after BSL expires. The elephant in the room missing from the discussion is the Uniswap trademark and brand assets.
As I understand it the "official deployments" idea you're outlining effectively a franchising program. The desired system behavior, from my point of view is:
Use of the Uniswap brand needs to have functional equivalence to being a recognized deployment. Uniswap stands for quality, security, etc. A risk scenario as it stands is someone else going ahead with deploying a Uniswap Chain built on Cosmos SDK without our permission and fully, or someone deploying a "Uniswap" on an L2 with insufficiently secured bridge. It's obvious that these are unstrategic and actively harmful for the brand.
In short, the expiry of BSL turns deployments from a code licensing issue into a brand licensing one.
We are currently not set up for success when it comes to brand licensing issues. To the extent of my knowledge, Uniswap Labs fully owns the trademark of the Uniswap name and all other brand property. The trademark policy is visible here:
You may do the following without receiving specific permission from Uniswap Labs:
- Use Uniswap wordmarks in text to truthfully refer to and/or link to unmodified Uniswap smart contracts, protocols, interfaces, programs, products, services and technologies (“Uniswap software”).
- Use the Uniswap wordmarks to truthfully describe modified versions of Uniswap software that you may create or make available. For example, you may say “This software is derived from Uniswap software.” or “This service uses software derived from Uniswap software.”
- Use the Uniswap logos in software or aggregators that integrate with Uniswap software to truthfully refer to, and, where possible, link to the applicable Uniswap software hosted on the Ethereum blockchain.
- Use Uniswap wordmarks to clearly signal to users that there is no affiliation with or endorsement by Uniswap Labs.
- Follow the terms of the open source licenses for Uniswap software.
This is a very permissive policy and one that largely would undermine the goals of the "official deployments" strategy you've outlined above. Unlike BSL (whose expiry date I've been told is firm and irrevocable) Uniswap Labs' trademark policy is malleable. I suggest that we continue these discussions Marvin and the Uniswap Labs legal team and consider putting the Uniswap trademark in the possession of the DAO. Without this I'm not sure what teeth the "official deployments" strategy actually has.
