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

This will be our (FranklinDAO/Penn) last post here seeing the impending 3 hour deadline for votes. Since we last posted here a few hours ago where we expressed our opinions regarding how we believe future bridging solutions should go, we are currently abstaining from a vote.

For some background, this has certainly been the #1 most lobbied vote on Uniswap that we have ever partaken in. Our opinions expressed above should be coupled with this thought: no matter the outcome, this should be a short term victory for either party. In the very near future, we would like to once again enforce that we think a multiple bridge multisig should be used to give us the best of both worlds.

At the end of the day, taking away our opinions regarding the jurisdiction of this vote, if we were forced to choose on this proposal, our team is genuinely split right down the center with our decision. In short, we believe Wormhole’s council of 19 at face value is more appealing to us, however, custom solutions that L0 have promised @Kydo bring them back up to pretty much par in our eyes if not slightly the edge, given proper execution, which is a whole another story.

Ultimately, this has definitely been a pretty “stressful” day as we’ve been trying to digest information in real time (while trying to grind for the Starknet Hackathon lol). Truly, to everyone who reached out to us, thanks for your time and please understand that this “fence-sitting” by us is not one of inactivity and irresponsibility, but one of careful thought, debate, ultimate stalemate. We’d also like to note that as an organization, we’ll look to continuously improve our internal governance decisions and poise ourselves to better tackle similar situations like this in the future.

Finally, we’d once again like to thank the UF team for their constant communication these past few weeks, the BD teams of both LayerZero and Wormhole who we’re sure have both lost many hours of sleep, and other participants who have either reached out to us or been very responsive with help (@GFXlabs, @Kydo & other schools, VCs, and other interested projects and protocols). We truly are impressed with the activity around this and hope to see it stay around.

PS: Seeing that there’s a good chance this vote might come down to a16z’s verbal communication on the forums, but no vote on Snapshot (custody hurdles?), we’re interested in how this situation will be handled, is there a precedent set here yet?


A Multi-bridge Implementation for Uniswap Governance is Now Available

It is now quite clear that the initial concern raised by the community about Celer’s upgradability contract, which we addressed here and plan to deprecation soon, is absolutely not bigger concerns comparing to many of the issues revealed and discussed in the forum.

While we have a lot to say about the ongoing debates in the forum and CT, we refrain from doing so and instead now deliver a multi-bridge Uniswap governance solution that is vendor-lock-in-free for Uniswap community to consider.

For Uniswap community who has not casted votes yet, please vote for Celer to express your support for this kind of multi-bridge solution.

This solution is strictly better than choosing a single bridge in terms of security and availability. In addition, it also retains the strongest bargaining power in the hands of Uniswap community to always receive the best services. See this for more context.

The implementation combines both Celer and Wormhole and is open-sourced here

All other bridges/cross-chain solutions such as LayerZero can be added easily via adapters.

We are setting up a testnet transaction to demonstrate this end-to-end. @Wormhole team we hope that you can help to set up a relayer for this because otherwise the only easy way would be deploying on Avalanche and BSC testnet where Wormhole generic relayers are available to our knowledge. Feel free to DM!

Now let’s get to the solution specification.

Send Cross-Chain Messages through Multiple Bridges

This is a solution for cross-chain message passing without vendor lock-in and with enhanced security beyond any single bridge. A message with multiple copies are sent through different bridges to the destination chains, and will only be executed at the destination chain when the same message has been delivered by a quorum of different bridges.

The current solution are designed for messages being sent from one source chain to multiple destination chains. It also requires that there is only one permitted sender on the source chain. This would be the use case for Uniswap governance contract on Ethereum
calling remote functions of contracts on other EVM chains.


Send message on source chain

To send a message to execute a remote call on the destintion chain, sender on the source chain should call remoteCall() of MultiBridgeSender, which invokes sendMessage() of every bridge sender apdater to send messages via different message bridges.

│ Source chain                                                                                            │
│                                                                                                         │
│                                                             ┌─────────────────┐   ┌───────────────────┐ │
│                                                         ┌──►│ Bridge1 Adapter ├──►│ Bridge1 Contracts │ │
│                                                         │   └─────────────────┘   └───────────────────┘ │
│                                                         │                                               │
│ ┌────────┐remoteCall()┌───────────────────┐sendMessage()│   ┌─────────────────┐   ┌───────────────────┐ │
│ │ Caller ├───────────►│ MultiBridgeSender ├─────────────┼──►│ Bridge2 Adapter ├──►│ Bridge2 Contracts │ │
│ └────────┘            └───────────────────┘             │   └─────────────────┘   └───────────────────┘ │
│                                                         │                                               │
│                                                         │   ┌─────────────────┐   ┌───────────────────┐ │
│                                                         └──►│ Bridge3 Adapter ├──►│ Bridge3 Contracts │ │
│                                                             └─────────────────┘   └───────────────────┘ │
│                                                                                                         │

Receive message on destination chain

On the destination chain, MultiBridgeReceiver receives messages from every bridge receiver adapter. Each receiver adapter gets encoded message data from its bridge contracts, and then decode the message and call receiveMessage() of MultiBrideReceiver.

MultiBridgeReceiver maintains a map from bridge adapter address to its power. Only adapter with non-zero power has access to receiveMessage() function. If the accumulated power of a message has reached the a threshold, which means enough number of different bridges have delivered a same message, the message will be executed by the MultiBrideReceiver contract.

The message execution will invoke a function call according to the message content, which will either call functions of other contracts, or call the param adjustment functions of the MultiBridgeReceiver itself. Note that the only legit message sender is the trusted dApp contract on the source chain, which means only that single dApp contract has the ability to execute functions calls through the MultiBridgeReceiver contracts on different other chains.

│ Destination chain                                                                                          │
│                                                                                                            │
│ ┌───────────────────┐   ┌─────────────────┐                                                                │
│ │ Bridge1 Contracts ├──►│ Bridge1 Adapter ├──┐                                                             │
│ └───────────────────┘   └─────────────────┘  │                                                             │
│                                              │                                                             │
│ ┌───────────────────┐   ┌─────────────────┐  │receiveMessage()┌─────────────────────┐ call()  ┌──────────┐ │
│ │ Bridge1 Contracts ├──►│ Bridge2 Adapter ├──┼───────────────►│ MultiBridgeReceiver ├────────►│ Receiver │ │
│ └───────────────────┘   └─────────────────┘  │                └─────────────────────┘         └──────────┘ │
│                                              │                                                             │
│ ┌───────────────────┐   ┌─────────────────┐  │                                                             │
│ │ Bridge2 Contracts ├──►│ Bridge3 Adapter ├──┘                                                             │
│ └───────────────────┘   └─────────────────┘                                                                │
│                                                                                                            │

Add new bridge and update threshold

Below are steps to add a new bridge (e.g. Bridge4) by the dApp community.

  1. Bridge4 provider should implement and deploy Bridge4 adapters on source chain and all destination chains. The adapter contracts should meet the following requirements.
    • On the source chain, the sender adapter should only accept sendMessage() call from MultiBridgeSender.
    • On the destination chain, the receiver adapter should only accept messages sent from the Bridge4 sender adapter on the source chain, and then call receiveMessage() of MultiBridgeReceiver for each valid message.
    • Renounce any ownership or special roles of the adapter contracts after inital parameter setup.
  2. Bridge4 provider deploy and open source the adapter contracts. dApp community should review the code and check if the requirements above are met.
  3. dApp contract (Caller) on the source chain adds the new Bridge4 sender adapter to MultiBridgeSender on the source chain by calling the addSenderAdapters() function of MultiBridgeSender.
  4. dApp contract (Caller) on the source chain adds the new Bridge4 receiver adapter to MultiBridgeReceiver on the destination chain by calling the remoteCall() function of MultiBridgeSender, with arguments to call updateReceiverAdapter() of the MultiBridgeReceiver on the destination chain.

Updating quorum threshold is similar to configure a new bridge receiver adapter on destination chain. It requires a remoteCall() from the source chain Caller with calldata calling updateQuorumThreshold() of the MultiBridgeReceiver on the destination chain.


Use case: contract A on Goerli send message to contract B on BSC Testnet in order to call enableFeeAmount() for state change. Apply a 2-of-3 messages governance model with message bridge C, D and E.

Deployment and initialization

  • Deploy MultiBridgeSender on Goerli, set address of A as allowed caller.
  • Deploy MultiBridgeReceiver on BSC Testnet.
  • Each message bridge provider prepare their own SenderAdapter and ReceiverAdapter, named with a prefix of their bridge name. Take preparation of CSenderAdapter and CReceiverAdapter as an example.
    • Deploy CSenderAdapter on Goerli, set address of MultiBridgeSender as multiBridgeSender.
    • Deploy CReceiverAdapter on BSC Testnet, set address of MultiBridgeReceiver as multiBridgeReceiver.
    • Call updateReceiverAdapter() of CSenderAdapter, set address of CReceiverAdapter on BSC Testnet(chain id 97) as a valid ReceiverAdapter.
    • Call updateSenderAdapter() of CReceiverAdapter, set address of CSenderAdapter on Goerli(chain id 5) as a valid SenderAdapter.
    • Transfer ownership of CSenderAdapter and CReceiverAdapter to address(0).
  • Once all message bridges are ready, somehow let contract A call addSenderAdapters() of MultiBridgeSender with an address array of CSenderAdapter, DSenderAdapter and ESenderAdapter.
  • Call initialize() of MultiBridgeReceiver, with an address array of CReceiverAdapter, DReceiverAdapter and EReceiverAdapter, and power threshold 2.

Sending your message

Prepare a calldata for contract B for calling enableFeeAmount(), then somehow let contract A call remoteCall() of MultiBridgeSender with _dstChainId = 97, _target = <address of contract B> and _callData = <calldata you prepared>.


Imagine that the messages sent via C, D and E received by MultiBridgeReceiver on BSC Testnet in an order of 1.C 2.D 3.E. During receiving message sent via D, accumulated power reaches power threshold 2, which result in message execution(the calldata will be sent to contract B).

Notes to the community

We are more than happy to answer any questions, help with tests, collaborate with similar-minded builders like @AlexSmirnov, iterate based on feedbacks and provide audits from community selected firms.

Although Celer, being a 2018-vintage project, does not have the backing of large UNI-holding investors at this moment, we do trust the integrity and intelligence of all the Uniswap delegates to choose this positive-sum path that ensures the highest level of security and service quality for Uniswap’s multi-blockchain expansion.

We will update this post with testnet transactions once we worked through the small integration work using @Wormhole .


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