Thanks @devinwalsh for formalizing this post into an [RFC] and @Kydo for furthering the conversation.
New subdomain
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.
Proposer-Deployer Separation
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.
Recognition of Subjectivity
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.
Testing Required
This framework would greatly benefit from a sister-framework for analyzing the security of a deployment.
- For EVM-equivalent deployments, there should be a standard set of tests run and published before going to on-chain vote
- any deployments which utilize a level of EVM byte-code interpretation should publish relevant audits about this process
- any deployments which adapt code on a language level should undergo audits which adhere to a set of standards set by the DAO
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).
Changing an official/recognized deployment
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.
Summary
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.