Decoupling additional use grants from bridge provider is probably fine. I would support a proposal that does not specify bridge provider.
Some conversation about the future of deployment proposals:
I want to explore this from the framework of what gives a deployment team confidence the work they are doing will be 1. legally safe 2. supported by the DAO.
I obviously do not speak for gnosis team, but I imagine this is a concern to most organizations deploying Uniswap on an external chain.
Giving an additional use grant to a deployment team allows them to deploy with legal clarity, and they can begin work immediately.
At some point, a deployment team needs to be confident the DAO will chose to support their specific deployment which utilizes a specific bridge.
There needs to be a separate process for the DAO to chose to respect the external deployment using the specified bridge. This should likely come ideally come BEFORE the team spends a significant amount of time integrating with a bridge provider. Though the issue with this is it gives the deploying team little flexibility, as they are bound by the terms of the original vote.
With the license expiring, we are going to see a ton of ‘deployments’ of Uniswap v3 in all sorts of environments. Even multiple deployments on the same chain.
The only ‘official’ deployments becomes those which Uniswap governance choses to send governance proposals to (please correct me if the former statement is incorrect). We could run formal votes to say ‘we respect this deployment as the official deployment on X chain’, or we could informally determine official deployments by only sending proposals to those deployments.
My suggestion is after the expiry, we host 2 votes
1. Uniswap signaling to support a deployment on X chain
-
This should not specify a bridge provider to give the deploying team maximum formalized flexibility. This reduces the need for additional votes if the specified bridge provider is no longer suitable, or any other issues that arise in the process.
-
As per Penn Blockchain’s point here, this should be left very general, and be an overall assessment of the chain’s liquidity, technical interest, alignment, etc.
-
There should be off-chain, non-binding discussion about the deployment details to give the deploying team comfort in the work they will begin doing at this point. Though, the statements made will not be binding to either party to give flexibility to the team. This means: working with the assessment committee to ensure they are confident in the bridge solution being used, providing a timeline and method for deploying, being transparent in the forum about any changes in direction taken, having active conversation about the rewrite/transpilation/audit process for non-EVM native deployments.
-
This gives the deploying team relative confidence in the direction they are taking without strictly binding them to any methods during the deployment process.
2. Uniswap officially supporting a deployment
-
This is to be done after the deployment is successful and can be fully assessed, with a given bridge provider and verified contract addresses. The deployment can even be tested, the only contingency is Uniswap DAO has not agreed to govern the deployment yet.
-
This is more ideal as any deployment can be verified before being ‘official’. This becomes particularly relevant as we explore Uniswap moving outside of native-EVM execution environments where there is increased subjectivity about each deployment.
Overall, I’m looking ahead where there becomes a lot more nuance about what a Uniswap deployment looks like, and hope the governance process incorporates a final vote after the deployment has been made. There should also be a method to switching the official deployment on a destination chain.
For example, if someone rewrites v3 with intense gas optimizations and pays for suitable audits, it’s my opinion the DAO should be able to make the decision to support such a deployment on an L2 over another one that’s a native fork of the official github contracts (this may be a controversial take). But this logic also applies to non-EVM native deployments where there is inherently increased subjectivity.
The only other thing I can think of as a deployment being ‘official’ is being supported by the ‘official’ frontend. Does UL run this? Is there a plan to make this community managed (forgive me if it already is)? Could/should/can we incorporate being listed on the front end as part of this governance decision?
Sorry for the long post in the Gnosis thread. I am supportive of the teams current plan, just wanted to raise these concerns and figured this conversation was relevant.