Continue the Uniswap V3 deployment on Gnosis Chain with different bridge provider


The proposal to deploy Uniswap V3 on Gnosis Chain has been approved by the community since April 2022.

Link to previous discussion

Link to Temperature Check Snapshot

Link to Consensus Check Snapshot

However, it has been put on hold because the proposed bridge provider (Nomad) is no longer an option link.


Gnosis team proposes moving forward with the deployment using Wormhole as the bridge provider for the governance.

As a refresher, Wormhole was just voted in as the cross-chain governance provider on BNB chain with over 66% approval.

Link to Snapshot

Link to Governance Proposal

There are some points ongoing about multi bridge deployment. We will be in support and in line with the community if and when such solution is approved by the Assessment Committee

Summarizing the arguments for this proposal:

  • Gnosis Chain has already been voted in as of April 2022 and was already meant to have a Uniswap V3 deployment.
  • Wormhole contracts are live and the bridge has already been approved by the community for another major deployment (BNB chain).

Therefore we feel very confident that this would be the right step forward in deploying Uniswap V3 on Gnosis chain.


I see the benefit in deploying to Gnosis as soon as possible given the V3 License expires in 2 weeks, but, the foundation just funded research into bridge providers. There are some promising options including protocol agnostic solutions that could utilize multiple bridge providers without relying on one. I think it makes sense to ask for a clear timeline on the bridge research endeavor and wait until this research is done unless the expected timeline is >4 months.

1 Like

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.

1 Like

The Kava vote is not tied to a bridge provider per the latest update in that thread. I’d suggest going the same route post-assessment. We just voted against Avalanche for the same reason.

At this point, rushing to deploy before the results of the bridge assessment committee come back yields zero benefit to Uniswap, marginal benefit to the destination chain, and tangible benefits to the bridge provider.

1 Like

Thanks for your feedback @eek637
I don’t see how the benefits for both Gnosis Chain and Uniswap will be marginal honestly.
We are referring to a proposal that should have been implemented months ago and we don’t want to see this blocked once again.

As mentioned above, we will reassess immediately after the assessment committee comes with a proposal.

I agree that v3 should be on gnosis chain and agree that the long term benefits of a deployment there to both Uniswap and Gnosis Chain are not marginal. But there is no upside to voting on this with a bridge provider attached now and potentially having to re-vote in a month.

Kydo from Stanford Blockchain Club here.

We believe a good middle ground is going on an onchain vote without a bridge provider specified.


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

Several months have passed already and nothing has happened. The communities deserve an update. I personally think it is unfair that other chains (including BNB and BASE) got the deployment much earlier, although the Gnosis vote is much older. I don’t see any valid reasons why the deployment is so delayed.


Any updates on uniswap on Gnosis?