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.