[RFC - Update] Deploy Uniswap v3 (1 / 0.3 / 0.05 / 0.01) on BNB Chain (Binance)

Posting here that I fall into camp that Leighton and Jesse do above.

I abstained from the vote, as I think the process here was unclear and not a comprehensive look at solutions. I also think that singular bridge choices are worse for the ecosystem. Agree with Jesse that competition and choice are best for everyone.

Based on everything above I’d probably lean Layer Zero, but my perspective on the process here is more important to me.


A testnet deployment is done.


  • Source Chain: Avalanche Fuji testnet
  • Destination Chain: BSC testnet

The reason we did not use Ethereum Goeril is that there is no available generic relayer from @Wormhole on Goeril and Wormhole team has not responded to us in assisting things.

Test results:

Happy to answer any questions!

1 Like

On Monday, I posted a few thoughts which amounted to my decision to abstain from a voting on which bridge Uniswap should use in its deployment of v3 to BNB.

I want to take the opportunity to expand and point to areas for development where I’m excited to see progress. I also wanted to more explicitly commend Devin and UF for their work in stewarding the process here and on other issues, which in sum, has resulted in a lot more momentum in community governance.

Process-wise, the Uniswap Foundation holding a temperature check on which bridge to use in the BSC deployment served both to generally highlight the issue of bridge selection in cross-chain deployment, and advance the decision in this particular instance. Action begets action, and continued forward movement is critical in decentralized governance.

The discussion around the merits of each bridge being considered here was absolutely better than leaving that discussion unconsidered at all. Was it comprehensive? No. That is why I abstained from voting. Was it forward progress? Yes, and I am glad to see that.

Even more importantly this Snapshot highlighted the need for more bridging research - both on existing solutions for future deployments, and so that a single bridge selection doesn’t need to be bundled to new deployments going forward (for example, as Martin proposes here.) That this came up as a result of this Snapshot is a win in my eyes.

Coming on the back of this Snapshot, the focus moving forward is on improving the cross-chain deployment process from first principles. Encourage folks to follow and contribute to the new Cross-Chain Bridge Assessment discussion as a first step there.

There’s already good discussion emerging around multi-bridge deployment designs, as well as the merits of individual bridges. My view stands that the best outcome is for new chain dapp deployments to be bridge agnostic, and to embrace modular standards that foster more competition. Im looking forward to more forthcoming research / commentary on this topic.

Disclaimer: Variant is an investor in the UNI tokens. Disclosures – Variant


Hi all. Following the community discussion on this proposal over the past week, the UF is posting here to answer some open questions and draw attention to next steps.

Next Steps on the BNB Proposal

  • The final Governance vote will move forward with the results of the most recent Snapshot Poll. In other words, no votes voiced outside of the Snapshot poll will be counted in the results. The proposal to deploy Uniswap v3 on BNB Chain will go forward to the final governance vote with Wormhole as the selected bridge.
  • Delegates, as always, will have the opportunity to vote for or against the proposal in this final vote, based on their view of which choice is best for Uniswap.

Timeframe and Context on Bridge Selection Temperature Check

  • Dec. 11, 2022: The Request for Comment (RFC) to deploy Uniswap v3 on BNB was posted in the Uniswap governance forum. This proposal initially contemplated HyperLoop as the bridge. After initial community discussions, DeBridge and Celer were considered as new options. Ultimately 0xPlasma, the proposer, decided to use Celer as the bridge for its proposal.
  • Jan. 16 to Jan. 21: Temperature Check to deploy Uniswap v3 to BNB Chain using Celer as the bridge goes live. It passes with 20M UNI votes in support. At this point, the proposal could have moved forward to the final Governance vote.
  • Jan. 20: GFX Labs summarizes its diligence on Celer in a forum post. Celer responds to GFX, and other delegate questions, on Jan. 23 (here) and Jan. 24 (here). This discussion focused on the security setup of Celer. [Note that the Assessment process will diligence Celer, and provide an independent review of its security setup for the community’s benefit]
  • Jan. 24: Wormhole posts in the forum.
  • Jan. 25: LayerZero posts in the forum.
  • Jan. 26: UF proposes an additional Temperature check take place to vote on a bridge for the BNB deployment. This proposal was made in order to 1) allow the BNB proposal to move forward in a timely manner, as the community had expressed its support for a BNB deployment in the initial Temp Check, and 2) to allow for a community review of relevant information on Celer, and to consider other bridge providers discussed in the forum: Wormhole, LayerZero, and deBridge.
  • Jan. 27 to Jan. 31: A new Temperature Check is posted on bridge selection.

Cross-Chain Bridge Assessment Process

  • As the BNB proposal governance process progressed, we also saw the clear opportunity to create a better process for future cross-chain deployment proposals.
  • We have proposed the creation of an Assessment Group for bridges here. Community members will have until at least Friday February 17th to review and provide feedback on the process.
  • Applicants to join this team can express their interest in the forum by posting the following: a. Name and affiliation, b. Qualifications as they relate to the criteria stated above, stated briefly, c. Explanation of why you are interested in becoming a member of this team. The exact process by which applicants become team members will be confirmed after community feedback is incorporated over the next 2.5 weeks. In the interim we are excited to hear from interested parties.
  • Bridges that wish to be assessed may also post their responses to the questions listed in the forum until at least that date.

Clarity on deploying cross-chain with no bridge, and changing the bridge used for a chain

  • Upon deployment to X chain, the “owner” of the Uniswap v3 factory contract on that chain is set to a bridge contract which receives and relays messages from the Ethereum L1 timelock contract.
  • It is technically possible to deploy Uniswap v3 without a bridge on X chain. However, an implication of that decision is that no future information can be communicated to that deployment by Uniswap governance. Uniswap governance would not be able to turn on the fee switch on X chain or “add” a bridge later on. No fee tiers could be added, unless the deployment includes an affordance for anyone to be able to add any fee tier.
  • If a deployment of Uniswap v3 to X chain is made with bridge A chosen, it is possible for Uniswap to later update the bridge to bridge B. This decision would go through the governance process. The final governance vote calldata would be sent from the Ethereum L1 timelock to the X chain deployment through bridge A, and would communicate a change of the Uniswap v3 factory owner from bridge contract A to bridge contract B.

General Comments

  • This proposal has received more attention than any Uniswap proposal in recent memory. It has drawn widespread attention to the role that bridges play in governance, and begun to inform a larger audience about the tradeoffs in and intricacies of bridge design. Delegates had the opportunity to speak directly to bridge teams to learn from them and ask questions.
  • The discussion also highlighted the urgent need for a better process to be implemented for bridge selection. We mentioned this above, and are excited to receive your feedback and move this forward.
  • It also highlighted the need for more extensive research into bridges for governance, and into bridge-agnostic solutions for protocols. The Uniswap and broader crypto community mobilized themselves to do considerable work in this area in a short period of time. Kydo proposed a Multi Message Aggregation method. Celer designed, deployed, and has already conducted tests for a multi-bridge implementation for Uniswap governance. Martin Koppelmann (Co-founder and CEO of Gnosis) proposed a general bridge framework that may operate independent of, and provide more security than, any single team or approach. This work would not have materialized over such a short time frame without the fervent community discussion here. These solutions, and more, will be processed and assessed by the Bridge Assessment team for future usage by Uniswap governance.
  • Uniswap is one of the largest DeFi communities on Ethereum to pursue cross-chain deployments, and is having these difficult but important conversations in public. We hope our learnings, and the new process we create from here, will contribute to the creation of more seamless, standard processes and technological solutions that other protocols can benefit from as they consider deploying across other chains.
  • While the focus on and fervor of the discussion was not anticipated by many in the community, including the UF, we believe the developments above are a net positive for Uniswap, and the space as a whole.

We’re happy to lead this off and vote to deploy Uniswap on BNB Chain. Thanks to everyone who contributed to the process for the hard work to get this over the line.

Update with rationalehere.

1 Like

a16z voted against Proposal 31. We voted this direction for two reasons:

  1. As many others have commented on, the selection of a bridge provider for cross-chain governance messaging should be a comprehensive, structured process that allows for equal comparative analysis between each option. While that didn’t fully occur for this vote, @devinwalsh’s new cross-chain bridge assessment process can help to solve this moving forward. Given the number of possible upcoming bridge deployments, we agree that it’s important to have an independent third party weigh in with their relevant experience and expertise. Consequently, our vote against this proposal is to reset the Binance Uniswap v3 deployment process until the formal assessment is completed.

  2. Second, we do not believe Wormhole offers the most secure or decentralized bridging option. The Wormhole bridge suffered a $326M exploit last year. The bridge then had another critical vulnerability that put all $1.8B TVL at risk. Wormhole has since reduced their maximum bug bounty from $10M to $2.5M. Additionally, the Uniswap DAO will not have the ability to run and control the bridge independently if Wormhole is selected as the provider. We believe this is an equally important factor to consider.

As Uniswap token holders, we are ultimately interested in the long-term success of the Uniswap protocol. We hope to see the Binance deployment process restarted so that all bridge providers can participate in a formal assessment process. We will evaluate all bridge providers in good faith and subsequently vote in the best interest of the Uniswap protocol’s future growth and success.


GFX Labs voted for proposal 31 to deploy Uniswap v3 on BSC. Setting aside the bridge provider discussion after the completion of the Snapshot vote, we would like to elaborate upon our reasoning for voting to deploy on BSC, which some view to be controversial.

Revisiting our post from December, it is evident that Pancake Swap has significant trading volume and utilization. For those who are not familiar, PancakeSwap is a direct Uniswap v2 fork. If Uniswap v3 were to be deployed to BSC, we could significantly reduce PancakeSwap’s position in the DEX market and reduce the incentive for PancakeSwap to fork Uniswap v3 when the BSL expires in April.

The best example of Uniswap v3 competing with a Uniswap v2 fork is Polygon’s QuickSwap. Before Uniswap v3’s deployment on Polygon, QuickSwap had the majority of Polygon DEX market share. Within two months of Uniswap v3’s deployment, it took over most of Polygon DEX’s market share.

Planning beyond proposal 31, we believe Uniswap should be deployed on other popular and up-and-coming EVM chains to reduce the incentive for forks to be launched post-BSL.

There are currently five deployments of Uniswap v3 and one pending deployment (zkSync). In addition to BSC, we expect at least 2-5 more deployments before April 1st, approximately ten deployments by the end of April, and 20-30 by year-end. The question we should be working to solve now is what should Uniswap be doing to make certain it maintains its market share domiance post-BSL?


I was in the Layer Zero camp due to their straightforwardness with technical information and documentation. The risks were presented clearly to me vs the other bridges. However, it is important to expand Uniswap into other ecosystems.

From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind… The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.

Devin’s comments resolved my worries about bridge flexibility. My priorities for this proposal are expanding to BSC first, and the bridge is secondary. Once passed there is time to test out the multi bridge tooling without rushing to simultaneously launch on BSC. Wormhole’s history shows that it has been battled tested through failures; and will suit the purpose of a temporary bridge for BSC. My biggest concern with DAO governance is the inability to make actions in a timely manner.

1 Like

Good news is that it does not actually take months to figure out a multi-bridge solution as there is already one running on testnet that can integrate deBridge, Celer and Wormhole all together. This solution is being audited as we speak.


Proposed Implementation of a Multi-Bridge, Agnostic Solution

Over the past few months, LI.FI (a bridge aggregator supporting 13 bridges) has been closely monitoring the development in Uniswap’s Forum related to the BNB Chain Deployment Proposal, its subsequent Snapshot Poll which ended on Jan 31, and the current on-chain vote in favor of implementing Wormhole.

While we applaud the interest shown by key stakeholders of the crypto ecosystem in finding a suitable bridging solution for Uniswap’s Cross-Chain Governance, we strongly recommend that Uniswap not select one bridge provider for its BNB Chain Deployment Proposal. Specifically, we do not believe the BNB Chain Deployment Proposal should move forward before more research can be done, even if this may come as a letdown to many community members – be it bridge builders or other individuals.

Instead, we urge the Uniswap Foundation and the Uniswap community to fully immerse themselves in the Cross-Chain Assessment Process outlined by @devinwalsh. While the sprint to move to BNB Chain before the business license expires is important, we believe finding a long-term solution for cross-chain governance to be far more important than the short-term win of deploying V3 code first. There will be new chains, new versions of Uniswap, but there will never be another chance to expand governance safely and securely on the first try. Uniswap is a market leader in design (AMMs), token structure (airdrops), and overall competency, and LI.FI believes that the model Uniswap chooses for cross-chain governance has a high chance of becoming industry standard. We – as members of the crypto industry – want to see this done the correct way, and from the start.

Bridges, specifically arbitrary messaging bridges (AMBs), are in the nascent stages of development. Short-term, Wormhole, LayerZero, Celer, Axelar and deBridge are certainly viable solutions for cross-chain governance and have received substantial traction in terms of volume at the liquidity layer and development by dApps at the messaging layer.

That being said, we at LI.FI have done the research on AMBs (Navigating Arbitrary Messaging Bridges) and have delved deeply into the pros and cons of eight different AMB solutions. Our conclusion is simple: no single AMB is tested enough to be considered a robust and secure solution that a project of Uniswap’s size can solely rely on at this point. If there was a single, obvious AMB solution that could be trusted by Uniswap, then this forum post would not be necessary. Lest it be forgotten, two major AMBs were exploited in the past twelve months (Nomad and Wormhole), while LayerZero has also come under fire recently for its security model (Prestwich, L2Beat). We do not say this as condemnation, rather, we point this out to highlight just how difficult it is to build secure AMBs and the subsequent risks a dApp is exposed to by choosing a single bridging solution. In addition to this sentiment, we believe AMBs like Axelar, Synapse, Hyperlane, Multichain, Connext Amarok, and Hop deserve to be considered by Uniswap and the deadline of two and half weeks is too short for them to be formally introduced, debated, and voted upon again.

To summarize, LI.FI stands staunchly behind the concerns previously raised by @Kydo, @AlexSmirnov, and @modong. LI.FI believes that a multi-bridge, agnostic approach is best suited for Uniswap cross-chain governance because of the following reasons:

  • By picking one bridging solution, Uniswap will be selecting a winner in a niche that is perhaps yet to find the most optimal solution, resulting in a lack of innovation going forward and a dominance by the AMB that will not help the space move forward in the right direction.
  • With bridges, trust is a spectrum, and all the AMBs make different trade-offs resulting in unique strengths and weaknesses. However, when it comes to Uniswap’s use case of cross-chain governance, security can never be a trade-off. This is where a multi-bridge solution comes in to overcome these trust trade-offs, offering better security than any one bridging solution.
  • Aggregating the best, most trusted AMBs will be in the best interest of the Uniswap community as, irrespective of shortcomings in any individual bridge, Uniswap will always receive the best services required for cross-chain governance.

So, where do we go from here?

More research is in order, which we believe should be two-pronged.

1. Cross-Chain Bridge Assessment Framework

We would like to add our own feedback to Devin’s framework and add an additional step to the process.

The MMA solution or any other multi-bridge solution is built on the idea of Uniswap choosing multiple bridges as “adapters.” The first thing to do, therefore, is to determine which bridges meet Uniswap standards, as outlined by @devinwalsh.

We believe that Uniswap should first build a unique framework to both quantitatively and qualitatively measure and allow for the ranking of different bridge solutions by the engineering team. This would decrease the workload of the engineering team by letting them focus on stress-testing bridge solutions without having to create the parameters of such a test themselves.

As one of the largest players in DeFi, Uniswap has the chance to create the de facto bridge assessment criterion.

By our estimation, there are four bridge framework solutions currently in the ether.

Uniswap has the chance to build upon, combine, and quantify the works of four major research pieces without having to start from scratch.

With that in mind, we recommend that Devin’s initial Cross Chain Bridge Assessment make room for four researchers, who can help build this framework to assist the engineering team, who can then test out different bridging solutions based on the criteria mentioned in the framework and select which bridges make the cut to become a part of the multi-bridge solution.

The researchers will then explain the decision of the team through easy to digest articles, which can be used by other builders to assess bridges for their own dApps and by users to expand their knowledge of bridges and make more informed decisions when it comes to choosing a bridging solution for their needs. To this end, collaborations with other public good infrastructure projects like L2BEAT, Ethereum.org, among others, should also be considered to spread awareness and educate the public about bridges.

As Devin laid out, these individuals should be available for 10-15 hours per week over the next few weeks to participate in the assessment process, and to write up their findings in a report to share with the community.

To this end, we recommend Peter Robinson, Arjun Chand, Ermyas Abebe, and Bartek Kiepuszewski (though we believe Uniswap should have the final call here).

We believe the current timeframe is aggressive but doable. However, if the list of bridges were to expand, we would recommend pushing back the March 27th date.

2. Consideration of Making the Universal Governance Model an EIP

Uniswap pushing for a cross-chain governance EIP would be net positive for the industry, in our opinion, specifically in the context of a multi-bridge solution. Such an EIP would give dApps a shared template for creating safe, secure governance modules, while also giving flexibility for dApps to choose different bridging solutions based on their security, time, and cost preferences.

To that end, we believe that Uniswap should create and propose a new cross-chain EIP based on the design outlined by Mo Dong from Celer and Alex from deBridge (with, of course, any tweaks recommended by the engineering and research team).

Additionally, there are two EIPs and one forum post that Uniswap should consider learning from and building upon in addition to the framework above.

  • EIP 5164, as explained by Brendan Asseltine, is a PoolTogether and Hop-backed EIP looking to standardize governance message passing. While EIP 5164 is not a perfect fit for Uniswap – it proposes that all bridges provide the same interface to apps so that apps can just build against this interface and choose one bridge later – it does provide insight into the difficulties that EIP writers will have in coming up with a single design.
  • EIP 6170, is a common smart contract interface for interacting with messaging protocols.
  • Principled approach to bridges, proposes block header based bridges.

In our estimation, none of these solutions have captured enough mindshare to become industry standard. However, they have all pushed the envelope in what can be done in standardizing messaging, and Uniswap could learn much from it.

We recommend that Uniswap employ the same four-engineering team to standardize the MMA solution as an EVM-compatible EIP.

Given Uniswap’s position and influence in the ecosystem, it has the power to push an EIP that can potentially become the de-facto solution for any project indulging in cross-chain governance.


A multi-bridge, agnostic solution that the community invests resources into is a win-win-win for all the parties involved (Uniswap, bridging solutions, and the dApps that will implement this solution for cross-chain governance in the future).

As Devin said, the developments as a result of the proposed deployment on BNB Chain are net-positive for the ecosystem. Open discussions about bridge designs and frameworks for assessing security risks associated with them are exactly what we need to fast-forward the maturity of the bridging solutions and enable the development of secure bridges.

We look forward to the feedback of the UF and the community on our proposal.


Thanks to all for actively participating in our discussion regarding the infrastructure of the bridges. I think these tech assessments and proposals could be better posted on this thread.

My only question to the Uniswap community: are we ready to lose now a market share of the protocol on many new chains forever, or will we take a chance to speed up the deployment with current conditions and solve a bridge dilemma with the next proposal, when the solution will be found?

For me, the answer is obvious: now or never :exclamation:


for sure LI . FI is huge player on crypto field, technology is very fresh and crypto community need it
YES! :slight_smile:

The urgency of the Uniswap governance making a decision on launching Uniswap V3 and incentivizing LP to migrate from PancakeSwap on BSC should be the overriding factor in this discussion - not bridge choices. With PancakeSwap detailing plans to launch their V3 model on the same day as the expiration of Uniswap’s V3 BSL licence, it is crucial for the Uniswap governance to act swiftly and make a decision to remain competitive in light of PancakeSwap’s dominance in BSC decentralized exchange market. PancakeSwap already owns the largest liquidity depth in their V2 system, and having PancakeSwap launch a V3+ V2 router would only result in further lowering slippage within their ecosystem. Failure to accept the on-chain vote as-is could not only result in a failure of Uniswap V3 garnering enough liquidity to be competitive over PancakeSwaps V2 model, but also hinder Uniswap V3 as a second-tier decentralized exchange on BSC.

See: https://twitter.com/PancakeSwap/status/1620427176356216835?ref_src=twsrc^tfw

1 Like

It’s a yes for me, sir.
Thanks a bunch, sir

that’s a good idea and can help the Crypto

Hey All. Sergey from the Axelar Network here.

It’s great to see Uniswap expanding! We note that choosing a cross-chain provider is a highly technical and delicate question that requires careful planning, resource allocation, and coordination for a successful deployment. We support pursuing the Cross-Chain Assessment Process outlined by @devinwalsh to better benchmark the pros and cons of each proposal and will post answers on that thread.

The Axelar network is built from the ground up using Cosmos SDK and already connects over 30 chains including Ethereum, Cosmos chain, Arbitrum, Polygon, Avalanche, and others (see https://axelarscan.io), and new chains are added regularly. The Axelar network has been running on mainnet since Jan 2022 and has processed over $1.75 billion of volume in >350k transactions. Axelar’s ecosystem has thousands of builders using our decentralized and permissionless infrastructure, creating hundreds of unique cross-chain applications. Multiple connectivity paths can be connected to the Axelar network, leveraging its many-to-many transport and routing properties, improving the security of individual connections. Applications built on top can benefit from these improvements without additional changes.

We propose to instantiate interoperability for Uniswap by leveraging the Axelar decentralized network, powered by Proof of Stake consensus and many safety features, and augment it with an additional Uniswap-specific validator set. The Uniswap-specific validator set may be elected via UNI governance, and be instantiated based on Proof-of-Stake, Proof-of-Authority, or any other validator selection rule deemed needed. A custom policy can be instantiated to authorize messages of different value/importance. See our recent blog post for how to instantiate deployments based on different validation logic using Axelar. We’ll post full answers to the questions asked in Cross-Chain Assessment Process shortly and look forward to continuing the discussion with the Uniswap community.


Jesse here, commenting both on behalf of Variant and separately, in my role as a delegate.

I and Variant decided to vote “no” on the Uniswap v3 deployment to BSC.

Earlier I commented that it’s suboptimal for communities to be voting on singular bridges, and that the v3 BSC discussion has highlighted a valuable opportunity to rethink deployment design from first principles. Luckily, the ball is already rolling:

  • The Uniswap Foundation set up a new cross-chain bridge assessment process for evaluating modular deployment designs
  • Martin proposed an additive security model that integrates multiple bridges
  • Hyperlane detailed their design for a modular multi-bridging architecture that wouldn’t require building out exhaustive infrastructure, and is easy to change. Their protocol provides a standard format for incorporating any existing bridge into individual “security legos”, which are composable and thus can be combined in any way to create a validating condition before an interchain message is accepted.
    • For example, you can build out these “legos” for Wormhole, L0, and Celer, and then use Hyperlane to combine these to create the condition “message X is valid IFF all of these 3 ISMs have confirmed the message”.
  • Zefram built a universal bridge that can wrap multiple bridges simultaneously, to reduce security assumptions tied to any single bridge

Uniswap is a leader within the broader ecosystem, and the process here has the potential to set a standard for new chain deployments. There’s good progress in the works for building more modular deployment solutions, and I think it’s better for the protocol to fully explore those – and other emerging solutions – before finalizing a v3 BSC deployment.

Disclaimer: Variant is an investor in UNI tokens and Hyperlane. Disclosures – Variant


This is the only reason you needed to give, tbh. We get it.

1 Like

Hello, the Deployment Accountability Committee understands that there was no specific commitment your team has made to support the Uniswap Ecosystem. However, we do want to discuss some assumptions and explore with the community how to better improve such expectations.

In reality, TVL for Uniswap on BSC is only $13.17m at the moment and unlikely that it gathered 1-2M new users. What do you think were the issues that hindered meeting initial expectations? Note that this information is being sought in an effort to provide a collective update to the community that will be publicly available.

Greetings @Doo_StableLab
To reach the anticipated figures, extensive business development is crucial for the chain’s protocols and operations. Simply deploying the protocol is insufficient. This approach can be adapted for any other chain deployment.

1 Like