In alignment with our belief that the Uniswap community should be empowered to make informed governance decisions regarding cross-chain deployments, Uniswap Labs would like to propose a template for such proposals.
We have previously written here about the importance of paying close attention to the security and trust assumptions of the bridge being used to relay governance to the chain. As discussed in this post, Uniswap Governance contracts live on L1 Ethereum, so when the Protocol is deployed to a new network, UNI holders need a bridge contract to govern the Protocol on that network.
We believe users should be able to access the Uniswap Protocol, as well as other DeFi and web3-based protocols, across chains which are important to them. We also believe that Uniswap Protocol community members should be informed about the relevant security and trust assumptions in the bridge design, and particularly in the current implementation of the bridges which will be used for the deployment.
We also recently released the deployment script and documentation outlining how to deploy Uniswap Protocol v3 to other chains. Teams are now able to deploy the Protocol across chains entirely on their own, without the direct assistance of the Uniswap Labs team. To carry out the deployment, teams will have to request an exemption from the Uniswap Protocol v3 Business Source License. We have included sample language to use to make that request.
As such, we suggest that all future proposals for cross-chain proposals use the template below.
Cross-chain Deployment Proposal Template
- Summary of the Proposal.
- TL;DR including Proposed Chain, Deployer, Chain, Timeline to deployment, Benefits to Uniswap Community, and any other relevant information
- About the Proposed Chain
- Including, for instance, history of team, application ecosystem, size of user base, daily transfer volume, etc.
- Benefits to Uniswap Community and/or DAO Treasury
- Any planned Liquidity Mining (optional)
- Bridge security (Provide details based on current implementation as of proposal post date)
- Does the bridge support arbitrary message passing?
- Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?
- Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity?
- Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
- What are the ramifications of fraud to the malicious actor?
- Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
- License Exemption - if Uniswap Labs is not deploying the protocol
- Sample language for a Layer 2 solution: "Team [or Company] X may use the Licensed Work to deploy it on Y, a layer 2 solution for Ethereum, provided that the deployment is subject to Ethereum layer 1 Uniswap Protocol governance and control.”
- List the entity receiving the exemption - important that the exemption isn’t for anyone to deploy on the chain but a specific entity/team.
- Timeline for deployment after Governance approval
We welcome feedback from the community on the template, including suggestions on how it can be improved.