Proposed Template for Future Cross-chain Deployment Proposals

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.
  • Proposal
    • 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

Next Steps

We welcome feedback from the community on the template, including suggestions on how it can be improved.

11 Likes

This is Laura and Joanna from Other Internet. We welcome this template and propose the following additions in two areas based on our ongoing strategic research into partnerships and accountability in Uniswap governance:

  • Provide detailed information about the deploying entity in addition to the proposed chain
  • Provide detailed information about both financial and non-financial/indirect benefits to the Uniswap community that the proposer commits to, including a timeline on the delivery of any funds

Our suggested changes are added to the original template below in bold. We look forward to seeing other feedback and suggestions from the community on this initiative!

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. + stage of development of the project (e.g. pre-launch, testnet, mainnet)
  • About the Deployer
    • History of team, relationship to proposed chain team, relationship to Uniswap Labs, Uniswap community and/or UGP, community governance, information about native token, etc.
  • Proposal
    • Financial benefits to Uniswap Community and/or DAO Treasury + timeline on delivery of any funds
      • Any planned Liquidity Mining (optional) + timeline on delivery of any funds
      • Any planned additional grants (optional) + timeline on delivery of any funds
      • If metagovernance/dao2dao deal proposed, provide details of governance implementation
    • Non-financial/indirect benefits to Uniswap community e.g. increased user base
      • Benefits to ethereum/web3 ecosystem, contribution to public goods (scaling, mass adoption, etc.)
      • Any co-branding plans (optional) + details of the program
    • 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
7 Likes

Thank you for these additions - we agree with these suggested changes and will add them to the final version of the template incorporating all community feedback.

2 Likes

We have a clarifying question because there seems to be some confusion about what language should be used for the proceeding deployments of Uniswap V3.

The Voltz Additional Use Grants is:

Voltz Labs Technology Limited (“Voltz”) is granted an additional use grant to allow the Voltz DAO to use the Uniswap V3 Core software code (which is made available to Voltz subject to license available at https://github.com/Uniswap/v3-core/blob/main/LICENSE (the “Uniswap Code”)). As part of this additional use grant, the Voltz DAO receives a limited worldwide license to use the Uniswap Code for the purposes of: creating, deploying and making available aspects of an interest rate swap automated market maker (the “IRS AMM”); to modify and update the IRS AMM over time; and deploy the IRS AMM and portions thereof as smart contracts on blockchain-based applications and protocols. The Voltz DAO is permitted to use subcontractors to do this work. This license is conditional on Voltz and the Voltz DAO complying with the terms of the Business Source License 1.1, made available at https://github.com/Uniswap/v3-core/blob/main/LICENSE.

Our understanding was that Voltz needed the additional use grant because it sought to use the innovations of Uniswap in its derivative product.

This forum thread appears to be for chains seeking a Uniswap v3 deployment where the deployment is owned and controlled by the Unsiwap DAO. In these instances where control is maintained by the DAO and the deployment is done to the DAO’s expectation, the chain requesting the deployment can receive an exemption from the license.

While the additional use grant could apply to chains seeking a Uniswap v3 deployment, it would give them additional breadth that the DAO doesn’t need to give. If our understanding is correct, the proceeding deployments such as Celo, Moonbeam, and Gnosis should be requesting an exemption from the license using the sample language in the first forum post.

2 Likes

Thank you for your reply!

Correct, both projects like Voltz (middleware deploying on Ethereum) and chains like Moonbeam and Gnosis Chain (L2s or protocols that exist on other L1s) need to request an additional use grant to deploy v3. In both cases the deployment needs to be approved by the Uniswap DAO, and it is controlled by it in so far as these projects need to request the additional use grant through the governance process. Only deployments done by Uniswap Labs do not need to request a license.

The suggested additions to the template are to help with the evaluation of projects by the Uniswap community, and we agree that the template needs to be accommodating to the requirements of the different use cases, which is something we are working on mapping right now. So it should be used with some flexibility for the time being.

I hope this answers your questions, let us know if you have any further thoughts.

1 Like

Hi guys,

What is the current update of this deployment proposals?

1 Like

I assume you meant the proposals to deploy uni-v3 on Moonbeam and/or Gnosis Chain? Both proposals have just been put on-chain.

Moonbeam – see here and here.
Gnosis Chain – see here.

As for the uni-v3 deployment on Celo, proposal has passed on-chain (see here). Still waiting for execution (to grant v3 usage license on ENS txt record) and actual deployment.

yj

3 Likes