As many Defi traders, I am really against. Gnosis has to work as a real partner and much more as their are investors/ associates in Nomad entreprise.

A strong consensus I will repeat here, the trust in Gnosis will not come back as long as Nomad victims do not received a decend compensation plan.

Nomad can not solve it alone, needs their partners and shareholders as Gnosis.

I strongly agree that Uniswap should distance themselves from Gnosis, not work with, as long as they do not participate as a real partner/ associate, on a refinancing compensation plan for retailers Nomad victims . It very desapointed to be here, the low ethics there is in Gnosis.

Thanks @MattOnChain ! We are completely aligned with the research process and we have submitted a multiple provider approach ourselves (link to post). As mentioned above, we plan to reassess the approach the moment we get feedback from the committee.

However, we believe that currently is vital to proceed and complete a plan that was initiated almost a year ago.

Additionally, votes for Avalanche and Kava are also on-going with promising support.

As many Defi traders, I am really against. Gnosis has to work as a real partner and much more as their are investors/ associates in Nomad entreprise.

A strong consensus I will repeat here, the trust in Gnosis will not come back as long as Nomad victims do not received a decend compensation plan.

Nomad can not solve it alone, needs their partners and shareholders as Gnosis.

I strongly agree that Uniswap should distance themselves from Gnosis, not work with, as long as they do not participate as a real partner/ associate, on a refinancing compensation plan for retailers Nomad victims . It very desapointed to be here, the low ethics there is in Gnosis.

Thanks @MattOnChain ! We are completely aligned with the research process and we have submitted a multiple provider approach ourselves (link to post). As mentioned above, we plan to reassess the approach the moment we get feedback from the committee.

However, we believe that currently is vital to proceed and complete a plan that was initiated almost a year ago.

Additionally, votes for Avalanche and Kava are also on-going with promising support.

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.

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.

As the Uniswap V3 license is nearing its expiration, it is crucial to acknowledge that the concentrated liquidity is likely to be adopted by other protocols. This makes it strategically important to maintain a first-mover advantage by expanding its presence across various chains, ensuring it remains a leading platform in the face of increased competition.

A trade-off exists between selecting the most efficient and secure bridge solution and the urgency of deployment. Notably, the bridge assessment committee's findings are not expected to be released until early May (with likely further delays), and in this context, the deployment on the Gnosis Chain under the proposed conditions before the expiration appears to be a reasonable decision. We recognize that Wormhole bridge is a well-capitalized solution that collaborates closely with its partnered entities, providing a reliable and secure infrastructure for multichain deployment of Uniswap. With the previous BNB deployment that Wormhole oversaw, they already have the necessary parameters.

The Gnosis team has been working diligently on this proposal over a year with both temperature & consensus checks being passed with decent votes. It is acknowledged that the current bridging solution may not be the ultimate choice, and we are open to the possibility of future changes as more efficient methods are finalized.

Emphasis should be placed on the primary purpose to execute proposals governing this deployments. This ensures that Uniswap's decentralized governance model stays robust and responsive to the evolving needs of the ecosystem, regardless of the underlying chain.

We support the continuation of Uniswap V3 deployment on the Gnosis Chain with the Wormhole bridge, recognizing the importance of maintaining advantage and facilitating multichain governance parameters.

As the Uniswap V3 license is nearing its expiration, it is crucial to acknowledge that the concentrated liquidity is likely to be adopted by other protocols. This makes it strategically important to maintain a first-mover advantage by expanding its presence across various chains, ensuring it remains a leading platform in the face of increased competition.

A trade-off exists between selecting the most efficient and secure bridge solution and the urgency of deployment. Notably, the bridge assessment committee's findings are not expected to be released until early May (with likely further delays), and in this context, the deployment on the Gnosis Chain under the proposed conditions before the expiration appears to be a reasonable decision. We recognize that Wormhole bridge is a well-capitalized solution that collaborates closely with its partnered entities, providing a reliable and secure infrastructure for multichain deployment of Uniswap. With the previous BNB deployment that Wormhole oversaw, they already have the necessary parameters.

The Gnosis team has been working diligently on this proposal over a year with both temperature & consensus checks being passed with decent votes. It is acknowledged that the current bridging solution may not be the ultimate choice, and we are open to the possibility of future changes as more efficient methods are finalized.

Emphasis should be placed on the primary purpose to execute proposals governing this deployments. This ensures that Uniswap's decentralized governance model stays robust and responsive to the evolving needs of the ecosystem, regardless of the underlying chain.

We support the continuation of Uniswap V3 deployment on the Gnosis Chain with the Wormhole bridge, recognizing the importance of maintaining advantage and facilitating multichain governance parameters.