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

Does anyone think about the risks?

1 Like

Hi Everyone,

We’ve been doing a bit of research on the testnet deployment. Below is a list of the immediately relevant contracts:

  • BSC Testnet Uniswap V3 Factory contract: link
  • BSC Testnet Message Receiver Adapter: link
  • BSC Testnet Message Bus: link
  • Goerli Message Bus: link

Test use of the Celer Messaging system:

  1. Message sent from Goerli: link
  2. Message queued for execution on BSC: link
  3. Message executed: link

At a high level, we can see the Uniswap v3 protocol has been deployed on testnet and that Celer successfully passed a message from an EOA on Goerli, which implemented an additional fee tier on the BSC testnet deployment.

Overall, we’re pleased with the work that Ilia and his team have performed.

However, in reading through Celer’s deployed contracts and documentation, we have a few concerns and questions we would like addressed.

The Message Bus contracts on Ethereum and BSC mainnet have an owner role. The owner controls access to the following functions: setFeePerByte, setFeeBase, setLiquidityBridge, setPegBridge, setPegVault, setPegBridgeV2, setPegVaultV2, and transfer ownership. In addition to this access, since the contract is upgradable, the owner is able to upgrade the implementation of the contract, which means anything is possible. The owner on the Message Bus contracts is the “SimpleGovernance” contract. However, the governance contract functions akin to a multisig since it has five voters with equal voting power. We were unable to find information regarding the five EOAs on the contract, however they appear to be active.

  1. 0x1b9dFC56e38b0F92448659C114e2347Bd803911c
  2. 0x34dFa1226F8b3E36FE597B34eEa809a2B5c0bBf9
  3. 0xDfE4F07D1F36B8d559b25082460a4f6A72531de2
  4. 0x9F6B03Cb6d8AB8239cF1045Ab28B9Df43dfCC823
  5. 0x2FB8783C14A71C08bFC1dE8Fc3D715Dd93039BF2

After reading through the contracts, we tried to find more information on how their “Optimistic-rollup-style” security model works. We were able to find this blog post & doc page, but it only had the same information from the forum post. We did find this reference to a “DelayedTransfer”, but it is unclear how this is “optimistic-like” rather than a simple delay.

We were also unable to find documentation or implementation instructions for running an app guardian. If the Celer team could please share the technical documentation and implementation of their proposed security model, we would appreciate it.

While the messaging contract appears to have been audited, their audits are from PeckShield & Slow Mist which do not inspire a high degree of confidence. Both audits were conducted in February 2022, before the addition of the delay mechanism.

We continue to be supportive of a Uniswap v3 deployment on BSC; however, the Celer team controlling ownership of the Message Bus and limited information on the security model makes it hard for us to support the proposal.

Additional Resources:


Thank you for the comments and questions. I wanted to reply here first to acknowledge the receipt of your comments. However, since today is the Lunar New Year and many of our team is on family or religious holidays, a detailed reply with technical documentation updates might be a bit delayed. Apologies for this and we will reply as soon as we can.

1 Like
1 Like

I explained above that since BNB Chain doesn’t have a canonical bridge, any interoperability solution will inevitably have a validation layer and Uniswap governance will still have to bear the risk that participants of the validation layer will not collude.

zk, optimistic — are just different implementations of the validation layer. As an example, here is an article from L2Beat with an interesting experiment that shows that “oracle and relayer” implementation of the validation layer is a 2/2 consensus mechanism, where validation of headers/proofs doesn’t add any security guarantees, but only gas costs since oracle and relayer can always collude.

I think the best way to move forward for Uniswap is to have a framework for bridges so that instead of relying on a single solution, Governance decisions are sent from Ethereum to other chains (e.g. BNB Chain), my multiple bridges. The passed decision is executed on the destination chain only in case the content of the messages sent by all bridges participating in the framework is matching.

deBridge team can help to prepare this framework so that Uniswap governance can have an established process for adding any new chains in the future


GFX Labs team, thank you again for your questions. We would love to provide some responses to your questions.

On audits and security track records

First, we would like to elaborate a bit on our security audits and track records. We respect that different people may have different opinions about security firms, but we believe that both Peckshield and Slowmist are well-regarded security audit firms. Peckshield, in particular, has been consistently the first to report many security incidents and coordinate major security investigations with top security researchers and firms such as banteg, samczsun, and others. If you have any specific concerns about the quality of these firms, we would be happy to relay them and invite these firms to answer or clarify.

Regarding the audit dates, we built Celer’s system in such a way that our optimistic rollup-like security model can be securely and easily added to dApps as a design pattern. The capability to do so has been available before Feb 2022, and we only began talking about it proactively later when we realized that some teams were marketing it as a unique feature.

In addition to security audits, Celer also has a standing $2M bug bounty on ImmuneFi since November 2021, which has not been claimed yet.

In terms of our security track record, Celer’s cross-chain system is the ONLY ONE that has processed a meaningfully large volume (bigger than $1 billion in asset bridging volume) without any critical security issues being reported or exploited. Additionally, throughout Celer’s development history since 2018, none of the systems or products built by Celer, including the world’s first Generalized State Channel Network, have been exploited in any way. Celer has a security operation team that is active 24/7 to monitor the public blockchain transactions for any anomalies related to Celer’s systems and respond to any reports from security firms and independent security researchers with a 3-minute SLA. Of course, we know blockchain is a dark forest and our flawless record does not automatically guarantee future security, but we hope that the information provided gives you more confidence from a comparative perspective.

On optimistic rollup-like security model

The security model of the optimistic rollup-like system has two components: 1) a two-phase commit pattern in the smart contract, and 2) an off-chain App Guardian that can halt the execution of a message during the delay between commit and confirmation.

We would be happy to explain this in more detail using the DelayedTransfer example you mentioned. DelayedTransfer is related to the optimistic-rollup-like security model used in cBridge, an asset bridge built on the Celer Network. When an asset bridge transaction is initiated and the message is relayed to the destination chain, the message is placed in a DelayedTransfer queue on the destination chain, where it must wait a set delay before funds are released with a confirm transaction.

During this delay, an App Guardian cross-checks the source chain to verify the presence of a corresponding bridge transaction. If a match is found, the App Guardian takes no action and the confirm transaction is executed as normal. However, if a matching transaction is not found (indicating a problem with the bridge), the App Guardian can halt the asset bridge smart contract, preventing any malicious transactions from executing and safeguarding funds. The App Guardian is operated by every validator of SGN and can also be run by additional parties, such as the Uniswap foundation, for their own dApps.

The above security model will be applied to Uniswap’s governance use case. We hope this explanation has provided clarity, but we are available for further discussion via a call or in a Twitter space.

We have recently taken down some of the documentation and reference implementation for the dApp side of the optimistic-rollup-like security model, in order to make it more adaptable for various application use cases. We will follow up with links to the updated documentation and App Guardian repositories within the next two days.

On governance multisig

You are correct in noting that the MessageBus contract is upgradeable through a governance multisig. Our governance process involves a community voting process, and the execution of governance decisions for on-chain contract upgrades is carried out by a subset of validators including InfStone, Binance Staking, OKEX and Celer Foundation.

We made the MessageBus upgradeable with the goal of making it easier to address any potential security issues just in case and add must-have features. However, we approach this process with care and continually evaluate and improve our governance process. We welcome additional active contributors such as GFXLabs to be more involved.

We hope the above clarifies the concerns to some degree and we are always happy to answer any further questions!

Hi Mo, I love the tech that you’re building at Celer, but I think that the Uniswap community may misinterpret a number of your points, so these need to be clarified.

Consensus Model

When you say a “Cosmos-consensus Security Model” or “L1-PoS-blockchain security mode,” someone may interpret that Celer inherits the security model from the Cosmos chain or from the layer-1 where the message was initiated — both of these statements are not the case. Instead, it is accurate to say that with this model, the Celer network is using Tendermint and Cosmos SDK as a set of ready-to-use tools and technologies for implementing consensus and networking layers for the project.

The PoS consensus implementation allows anyone with ⅔ of the voting power (i.e. ⅔ of the amount of staked tokens) to have full control over the consensus and validation of cross-chain messages.

The current total stake is 2,587,158,380 CELR and thus, if nodes with more than 2/3 of the total stake act maliciously, they can forge any message. 7 nodes currently have enough stake to control consensus.

⅔ of the total current stake is 1,724,772,247.33 CELR ≈ $25M at current market price. This is the approximate cost that would allow an attacker to withdraw liquidity from all Celer liquidity pools and forge any message to extract value from any Apps built using Celer Network, and, importantly, I assume the potential value extracted by an attack on Uniswap may be higher than the cost of attack.

The only staked asset is the CELR governance token, which means that validators’ collateral directly correlates with the protocol’s performance. This is why an attacker could open a large short perpetual futures position before attacking the protocol, and recover/hedge the cost of their acquired stake.

Having more than 2/3 of the protocol voting power would allow a malicious entity to control the consensus process and make arbitrary decisions about which blocks to add to the blockchain, forge cross-chain messages, reverse and censor transactions, create fake transactions, and create their own set of validation nodes.

Correct me if I’m wrong, but this attack can be performed by any single whitelisted Celer validator now.

Optimistic security model

You may say that the described problem can be solved through an Optimistic rollup-like security model which is the second alternative provided by Celer. My guess is that this wouldn’t add any additional security to the validation layer for a few reasons:

  1. The optimistic component can always be implemented on the application level, where the receiving smart contract in BNB Chain can have a “quarantine zone” for a configurable period of time, during which whitelisted App Guardians can cancel execution of the message content. If any app can easily add an optimistic component, then why should it be provided by the interoperability solution itself as a second security model?
  2. If an optimistic approach is implemented into the interoperability protocol itself, it delegates responsibility from the validation layer of cross-chain infrastructure to the application, which should elect “App Guardians” who become participants of the new validation mechanism. This approach performs implicit change from the “shared” to “isolated” security model of the validation layer. The reasoning behind why the isolated security model is not suitable for a validation layer can be found in this L2Beat article and my Twitter thread.

I’m not trying to attack a competitor here, I want to make sure that all trust assumptions and risks are made clear for the Uniswap community, as Celer has been endorsed in the temperature check.

Repeating what I posted in Discord:

Is Uniswap aware/worried about the possibility of a security issue regarding repairing hashes with Beacon Chain?

If this thing is not really a blockchain it means whoever is repairing these hashes is operating the system. We can debate how and to what degree Bitcoin, Ethereum and other blockchains are decentralized. But nobody there is repairing hashes looking backwards whereas here things look decidedly less like Satoshi’s vision.

(I know nothing about “datafinnovation” except they were mentioned in an Arthur Hayes blog post and many of their posts seemed prescient of later issues being revealed.)

Aave, for example, will go on a chain and then remove support if there is security risk (i.e. a reliance on a single bridge, pre-or-post that bridge being compromised). This post suggests serious security risks. I know BSC is attractive considering its TVL, but this could have serious implications, no?

Hi Everyone,

In light of our concerns with Celer, we thought we should propose a solution to the Uniswap Community. To effectively but quickly evaluate cross-chain messaging protocols, we came up with a few key criteria to asses protocols.

  • How long has the system been running, and how much value has it been responsible for?
  • What degree of security and decentralization do they offer?
  • Have their contracts been audited & do they have a bug bounty program?
  • Do the contracts have an owner? If so, what can the owner do?
  • Does their documentation clearly explain how their system works, not just in concept but, most importantly, in execution?
  • What do we know about the team?

It’s a mix of subjective and objective items that have helped us navigate the space. Through this process, Wormhole stood out to us, so we decided to see how the rubber met the road. To best understand the technology, we deployed a copy of Uniswap v3 onto BSC’s testnet and developed a message sender and receiver contract.

Deployed Contract Addresses

  • Uniswap Factory Contract: link
  • Uniswap Wormhole Message Sender: link
  • Uniswap Wormhole Message Receiver: link


The current flow:

  1. At the Uniswap Message Sender (Goerli) - sendMessage(targets[ ],values[ ],data[ ],messageReceiver). The message is encoded and published. The function is only callable by the contract owner. For testing purposes, it is currently an EOA, but in production, it should be the Uniswap Timelock contract.
  2. Wait for the guardians to complete their verification process. Since we have hardcoded the consistencyLevel to 1, it will wait for finality. Once the Verified Action Approval (VAA) is published, then we may proceed.
  3. At the Message Receiever (BSC testnet) - receiveMessage(bytes[ ]). The contract calls Wormhole’s core bridge contract to verify the VAA. After it verifies the sender is the Uniswap Message Sender contract, it verifies the message has not already been processed and will finally execute the message.

There are three key points. First, the Uniswap Message Receiver must verify the sender is the Uniswap Message Sender. Second, the content received must be the content sent. Third, the message must not have been previously executed.

We would love it if the community reviewed our work. We believe utilizing this configuration for the BSC deployment makes the most sense. If we proceed with this implementation, we’ll conduct an additional test to verify this works with the Uniswap Governance system and coordinate with Ilia.

On a related note, from having spoken with the Wormhole team, it’s our understanding that Wormhole is also preparing a forum post with additional information.


We had the chance to connect with @ilia_0x yesterday over Telegram — we’ve answered the questions you’ve posed to us! The Wormhole community is excited to throw our hat in the ring, and we look forward to engaging with the Uniswap community more broadly :slightly_smiling_face:

Hi everyone —We’re Wormhole, a leading arbitrary message passing protocol that connects 22 heterogeneous chains. Today, the Wormhole community includes several independent core contributing teams as well as a network of 19 industry leading Validators securing the network. The Wormhole community is investing deeply in a fully trustless future and is working on a Zero-Knowledge (ZK), light client based, backend designed to deprecate the Guardian software. Once enabled, chains can trustlessly validate other connected chains.

  1. Does the bridge support arbitrary message passing?
    a) Yes, Wormhole is one of the first and longest serving arbitrary messaging protocols. Since launching on mainnet in August 2021, 185 million messages have been transmitted, with 2 million messages currently generated daily between asset transfers and messaging through organic usage.

  2. Is the bridge secured by a trusted entity, by a multi-sig, or a protocol/set of incentivized nodes?
    a) Wormhole is secured by 19 validators (aka: Guardians) who jointly attest to messages. Each message must be attested by at least 13 of the 19 Guardians. Our Guardian set comprises the leading PoS validators, including Staked, Figment, Chorus One, P2P, and more. The complete set of current validators can be found here: https://wormhole.com/network/
    b) As mentioned above Wormhole is making significant progress in developing ZK-based light clients to facilitate completely trustless message-passing.

  3. Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity?
    a) Wormhole message security waits for both consensus to be reached on the source chain as well as additional safety features provided by the bridge. Additionally, Guardians run full nodes to protect the protocol against consensus-level exploits in the connected chains and further reduce contagion risk.

  4. Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
    a) All messages passing through Wormhole require a minimum of observation and signing by a majority of the Wormhole Guardian set (13 of 19).
    b) While there is currently no out-of-the-box recall mechanism for messages, a minority (7 of 19) Guardians may refuse to sign a fraudulent message and thwart an attack.
    c) Simple yet customized message recall functions can be built by individual integrators. An integrator would simply build “edge contracts” to introduce a time delay on message acceptance, providing an integrator with an opportunity to recall the message before it becomes effective.

  5. What are the ramifications of fraud to the malicious actor?
    a) Wormhole’s Guardians are leading PoS validators and some of the most respected names within the validator community. They collectively represent tens of billions in value staked and carry valuable reputations in the communities where they serve. Should they act maliciously (such as sign or forge fraudulent messages), they risk reputational consequences, external PoS businesses, and ejection from the Wormhole Guardian set.
    b) There is little incentive for an individual Guardian to act maliciously. Even if a Guardian were to succeed in forging a fraudulent message, it would not affect the network state because a single signature isn’t enough to establish the super-majority required to gain quorum. Finally, a fraudulent message would be immediately attributable to the offending Guardian to the rest of the Guardian network.

  6. Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
    a) The bridge has been audited 25+ times by leading audit firms, including Certik, Trail of Bits, and OtterSec, and the cohort of auditors continues to grow. You can see the complete list of auditors and publicized findings here. Those 25 audits are in addition to Wormhole’s already rigorous internal auditing standards, where a team of 6 experienced security engineers regularly perform review the protocol’s security.

As these 3rd party audits are completed and issues are sufficiently addressed, we make those audits public.

Find all audits here.

We feel Wormhole is well-qualified to support Uniswap’s cross-chain messaging between ETH and the BNB PoS Chain, and we appreciate GFX Labs’s proposed solution. If anyone has additional questions, we would be happy to answer them.

Wormhole Resources:


Hey Alex, thank you for your comments. Always great to have discussions with fellow builders in the space. Here are some quick replies:

Consensus model

What do we mean by “Cosmos-consensus Security Model” or “L1-PoS-blockchain security mode”

When we say L1-PoS-blockchain security model, we mean that the consensus algorithm is essentially acting like any other PoS blockchain. The closest in terms of consensus algorithm/mechanism is Cosmos-SDK/Tendermint chains such as Polygon PoS, BNB Chain or Sei Network. This is to stress that Celer uses a time-tested consensus engine and economic security engine, unlike some other multi-sig solutions or solutions with untested economic security models. We are not saying in any way that Celer’s shares the exact same PoS setup with any other blockchain.

Consensus failure != all money stolen

Unfortunately, you are not correct in stating that if the PoS consensus fails (2/3 stake colluding to behave maliciously), all liquidity in Celer’s Bridge can be withdrawn. This is precisely where the model of optimistic rollup-like security model shines. cBridge is built with this model from day 1 and even if the majority stake is acting maliciously, large fund withdrawing (in a cumulative sense) transactions can be canceled by any Celer validator plus a group of app guardians from security firms such as Peckshield and others. So what you described won’t happen. From a more practical point of view, Celer validators are highly reputable validators from the Cosmos community and incidentally share many with deBridge we believe.

Optimistic rollup security: application design pattern or protocol built-ins?

Implementing an optimistic rollup security model can be done in the application domain and in the protocol at the same time. They are not mutually exclusive. For Celer, every single validator can cancel messages that are maliciously passed by the consensus protocol if the message is sent through an OR model. This enhances the security from trust majority to trust-any validators.

In addition, application builders, governance bodies or security firms independent from application builders can run app guardians for specific applications even if they don’t trust any validators in Celer. For example, Certik, Trial of Bits and other security firms that are independent of both Celer and application builders can run app guardians for applications to offer “external security firms certified” services. The architecture is highly flexible with a high level of redundancy.

Hi Wormhole team,

While we are looking at the 2M message per day stats you stated, we noticed that 99.97% of those messages are from a network called Pythnet. If we exclude Pythnet, there are 719 message per day in the last 7 days on Wormhole. To put it into perspective, Celer processes 1958 messages per day during the same period of time.

In addition, we could not find any contract address deployed on Pythnet based on your documentation section describing contracts deployed on supported networks.

With the lack of information and significantly skewed volume, could you please elaborate on the Pythnet use case so everyone in the Uniswap community has a clear understanding on the usage level of Wormhole?

  • Who are sending all the 2M messages?
  • Where are those messages going? If there are 2M messages initiated from Pythnet per day, does it mean that there are 2M transactions somewhere on a destination chain? We searched from all your public contracts but did not find the matching 2M transactions. Could you please elaborate?

With 2M messages processed per day, one would imagine that there are a lot of unique wallet addresses interacting with Wormhole. Could you please share that data too? This way we can have a more complete comparison.

1 Like

Hi GFX Labs team,

Just a gentle reminder that we have replied to all of your concerns. Since you have done an evaluation of multiple solutions using the criteria you mentioned and are now championing one single solution, could you please post the evaluation matrix with facts for all the criteria?

With this, different solution providers can clarify if needed, and the Uniswap community and delegates can do a peer review and make informed decisions. Many community members and delegates may reach different conclusions by looking at all the facts.

In addition, we would add the following criteria to the evaluation matrix:

  • Are there any closely resembled use cases already live and running in production?
  • What is the security track record of the protocol?
  • What are emergency response plans or security operation measures in place to prevent and/or limit the scope of unforeseen smart contract bugs and consensus/multisig failures?

However, we feel that we may be having the wrong discussion here. Cross-chain governance is a unique use case and it can be built as a vendor-lock-in-free architecture where multiple cross-chain solutions can co-exist to serve Uniswap with super-charged security properties.

1 Like

Thanks for the deep analytics and numbers, but I think we as a Uniswap community should evaluate and compare first the security part of different solutions.

I also do not rule out that the following proposals for BNB and other chains may use different cross-chain solutions and not rely on a single point of failure.


I appreciate all the information about the different bridge solutions. I am not familiar with bridges or the security vulnerablilities. I have only heard of the Wormhole bridge from it’s $320 million bridge exploit.

How would an exploit like this impact Uniswap on BSC? Would all LP’s be vulerable?

Is the $320 million that was exploited still an issue that could impact protocols using Wormhole’s bridge solution in the future?

@modong what are the risks related to validator’s using Celer native token as stake to be slashed?

If Celer token prices get low enough, could there be malicious actor’s/validator’s that see more opportunity in the value of the bridge assets vs being slashed in Celer?

Would be good to have a combination of bridges, but due to my unfamilarity in this area I am unsure what is possible.

1 Like

A Vendor-lock-in-free Universal Governance Mechanism for Uniswap

In this sub-proposal, we present a vendor-lock-in-free Universal Governance Mechanism (UGM) for Uniswap that utilizes multiple cross-chain protocols simultaneously. This architecture significantly enhances the security of Uniswap UGM and, at the same time, eliminates any potential alignment risks down the road.

While we believe that Celer alone can effectively solve the Uniswap UGM use case, as a long-time advocate for open protocols, we propose this solution with the best interest of the Uniswap community in mind.

Which one to choose? Wrong question!

It may seem that Uniswap’s delegates and community must make a choice to select a single cross-chain messaging protocol for Uniswap’s multi-blockchain expansion.

However, if we go down this path, it will be a TRAGIC day for Uniswap community because Uniswap, the most open dex in the world, will be vendor-lock-in to a single cross-chain protocol.

Vendor lock-in carries a multitude of risks, most notably:

  • Security risk: Uniswap will be relying on a single cross-chain protocol and if that cross-chain protocol is hacked, Uniswap will also be at risk.
  • Interest alignment risk: This lock-in makes it harder for Uniswap to switch out of the solution even if the interests between the cross-chain messaging protocol and Uniswap become misaligned down the road.

But are we asking the right question?

Does Uniswap have to choose one single solution between different ones or can it utilize multiple solutions to achieve a better outcome for the community?

An Open UGM for An Open DEX

Cross-chain governance use cases have the following properties:

  • No room for security breaches as governance decisions are mission-critical parameters for the protocol with astronomical financial impacts
  • Latency is flexible with the governance process being multi-day if not longer
  • Costs are secondary due to the low frequency of governance decisions

With these properties, it is a perfect use case to utilize multiple cross-chain messaging solutions simultaneously.

We propose utilizing multiple cross-chain solutions simultaneously through the use of a “MessageProcessor” contract that acts as the executor for UGM calls to Uniswap contracts on the Binance Chain. This contract would have the following functionalities:

  • The ability to receive messages from multiple cross-chain messaging solutions through one interface.
  • An internal state machine to track messages received from different protocols and to release the message and trigger governance decisions only when a threshold is reached.
  • The capability to remove and add different cross-chain solutions using the same UGM mechanism with potentially different thresholds.

This architecture ensures that even if a single bridge is compromised, Uniswap’s governance process remains intact. Additionally, the Uniswap community can continuously evaluate participating cross-chain protocols with all bargaining power on their side.

We believe this architecture should be implemented to avoid vendor lock-ins, even if the Uniswap community decides to use a single cross-chain solution for now. Celer is committed to a vendor-lock-in-free future and is more than happy to implement this vendor-lock-in-free UGM for Uniswap.


Thrilled to see the community support for expanding Uniswap v3 to BNB Chain. BNB has long been a thriving part of the LayerZero ecosystem as BNB Chain was one of our initial launch chains and Binance was our first investor leading our seed round.

The BNB Chain team and the Uniswap Foundation recently reached out to LayerZero Labs about this opportunity and connected us to Ilia at Plasma to submit a proposal. Backed by a16z, Sequoia, Uniswap Labs, and Binance to name a few, LayerZero is supported by thousands of cross-chain builders with over 2,000 contracts deployed on mainnet, ~700 unique applications, ~2M total messages, ~$5B transactional volume, and billions of dollars in TVL. Builders include SushiSwap, PancakeSwap, BTC.b, Pudgy Penguins, Radiant, Stargate, Kanpai Pandas and many more unannounced integrations. Notable bridges built with LayerZero include the rebooted Harmony Bridge, CoreDAO bridge, and the Aptos Bridge.

Since our last proposal, we have built a fully functional governance implementation for Uniswap based on specs provided by the community and feedback from delegates and university groups, which is currently under audit with Zellic and Ottersec. These audits will be complete with fully tested code ready to be deployed within the next 2 weeks.

Uniswap v3 was approved by the community for deployment on both Moonbeam and Gnosis Chain last year. With this implementation, Uniswap can swiftly deploy Uniswap v3 to BNB Chain, Moonbeam and Gnosis maintaining a unified multi-audited governance model for interacting with all cross-chain deployments of Uniswap v3. With the community’s support, Uniswap v3 can expand to all three ecosystems in as soon as 2 weeks!

The complete omnichain governance module for Uniswap can be found here.

How It Works

LayerZero is a lightweight universal messaging interface that allows developers to seamlessly interact with contracts across dozens of blockchains. LayerZero Endpoints rely on an innovative architecture leveraging Ultra Light Nodes and independent Oracles and Relayers to securely relay messages between chains.

Communication flow in a single LayerZero crosschain transaction.

In a single call, paying only source gas, users and protocols can send a message (or a bundle of messages) to contracts on any supported chain. Thus, users are able to create a single contract that is capable of interacting simultaneously across multiple chains via our arbitrary messaging primitive.

LayerZero is currently live on 25+ chains including BNB Chain, Ethereum, Polygon, Arbitrum, Optimism, Avalanche, Gnosis, Metis, Aptos, Celo, Moonbeam and Fantom, and on testnet and undergoing audit on 6+ chains including Solana among other non-EVM chains. With a fully functional governance implementation, Uniswap can quickly deploy Uniswap v3 to all chains that LayerZero supports without compromising on security or introducing the complexity of multiple cross chain messaging protocols and services.

Security FAQ

Does the bridge support arbitrary message passing?

LayerZero enables smart contracts in disparate blockchains to communicate via arbitrary message passing of bytes payloads.

Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?

The current recommended configuration is secured by Chainlink as an oracle entity (currently securing tens of billions of dollars) and the LayerZero Labs (currently securing billions in TVL) operated relayer entity. All applications building on LayerZero have the choice to opt-in to default security or select a set of oracles and relayers. The architecture is entirely modular to allow Uniswap to run any portion of this validation layer if they so choose i.e. additional relayers and/or oracles.

LayerZero is a true protocol comprised entirely of immutable smart contracts and is not dependent on LayerZero Labs to be leveraged by applications in perpetuity.

Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity?

LayerZero leverages direct MPT validation construction of the source transaction and verifies the merkle inclusion proof directly on the destination chain via the protocol’s novel Ultra Light Node (ULN).

Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?

LayerZero provides the most secure solution for communication and puts control directly into the applications hands. It is worth noting that it is technically impossible to enable communication between blockchains in a fully trustless manner. Via the LayerZero protocol, the only way a fraudulent message may be passed to the destination chain is if both the Oracle entities and Relayer entities – selected by Uniswap - actively collude together and against the application to approve a fraudulent message.

Additionally, LayerZero is secured by a Pre-Crime, the proprietary security layer which has successfully secured the protocol and applications like Stargate since May 2022. Pre-Crime takes an outbound transaction and makes sure that it’s legitimate by running it against a set of application-defined invariants before the delivery of each message. Pre-Crime first forks every chain locally then it runs the state transaction locally to make sure the resulting state meets the list of defined invariants the application sets. Once this is confirmed Pre-Crime then provides an attestation that this is a legitimate transfer and the message is delivered.

What are the ramifications of fraud to the malicious actor?

Applications own all their smart contracts and maintain the ability to swap out Oracles and Relayers and/or expand their sets at their community’s discretion. Participating entities, including Chainlink, in the LayerZero network are thoroughly tested and vetted against rigorous standards in order to be supported in LayerZero documentation and are subject to re-evaluation at any time. Refer to an overview of Pre-Crime above for the additional security layer designed to prevent malicious actors from successful message delivery.

We designed LayerZero to be censorship resistant. Oracles and Relayers cannot censor messages without censoring all messages due to the sequential nonce ordered enforcement on the receiving chain. As a result, if an attacker obtained control of the Uniswap-selected Oracles or Relayers, and succeeded in censoring a message, every subsequent message would also be censored and the vote would stop. Uniswap could then expediently resolve the issue by updating configurations and messaging would resume.

Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?

LayerZero Labs has commissioned 35+ audits with the most recent audits on Github here. Nearly all code written by LayerZero Labs since inception have been immutable smart contracts audited externally and rigorously reviewed internally at least 3+ times each. LayerZero is the only major cross-chain messaging protocol to have secured significant transaction volume (~$5B) over time without any exploit, compromise of key infrastructure, or loss of user funds. Additionally, LayerZero has the largest live bug bounty across the industry at up to $15m.

Our sole focus at LayerZero Labs is building best-in-class cross-chain infrastructure. We have infinite runway and are building for the developer community. Learn more at Developers | LayerZero.


Kydo from Stanford Blockchain here. We would love to chime in on the bridging part of this discussion.

Message passing is hard. So please do not take the rest of this as criticism.

First, to echo a few things @devenmatthews and @GFXlabs said earlier.

No amount of dollars can help you forge a digital signature. So, we believe in the future, when cryptographically-secured message passing exists, Uniswap should heavily prioritize it (not choosing it straightaway since the complexity could also increase attack surfaces).

This is an important question to answer explicitly with data (this behavior → this slash amount, etc). Moreover, we would add that the provider should lay out how to become a validator in the network. This demonstrates how easy it is to collude across your validator set.

We should not lock in one vendor when the possibility of choosing multiple exists.

The recency of the audits is very important. These unaudited features, especially the delay mechanism, should not be implemented by Uniswap before a formal audit is complete.

Moreover, if your system requires honest interactions with external third parties, you should clearly explain how the external third parties work or link to their technical documentation (in another thread).

Second, we want to explore further the A Vendor-lock-in-free idea from @modong

We believe the best way forward, especially after the Nomad hack, is to use multiple bridge providers for message passing. We do not believe this is theoretically hard but would require significant engineering hours. We would love to see more discussion surrounding this topic.

Lastly, here’s what we think about the current providers.

We do not have the expertise to analyze the actual implementations and understand the complexity levels of each codebase; so we made our decision based on the assumption that all these implementations (up to the most recent audit) are equally secure/insecure.

Our ranking is subject to change, based on answers provided by the service providers.

Our tentative ranking is as follows:

  • Wormhole
  • Celer & LayerZero

To us, all these providers pose significant risks (relative to native L2 bridges or light client bridges). So, the ranking should not be taken at face value that any provider is “better” than another. Note: we are talking about using this for governance instead of a simple bridge transfer. So the evaluation criteria are a lot stricter.

We ranked wormhole as number 1 because of its diverse validator set. However, we would love to understand how does Wormhole penalize malicious validators? Does Wormhole have legally binding agreements with each validator? If so, what actions can Wormhole pursue?

We ranked Celer and LayerZero second. Celer has a decently sized validator set but the economic guarantee behind them is much weaker. I do not see that being a fixable problem, therefore I placed them (Celer) second.

LayerZero depends heavily on Chainlink’s oracle relay service. However, I was not able to find any information with regard to Chainlink’s implementation on their documentation or your website. Can you share more with regard to how does this specific chainlink oracle work? And if it is similar to Chainlink’s price feed, who are the multisig signers (providers) for it? With regard to the relayer, other than LayerZero, is there any other entity running a relayer? If Uniswap wants to run our own relayer, can LayerZero commit human capital to assist us in running it?


We believe the best course forward is the Multi-Provider-Aggregation method. I would love to hear thoughts from other technical delegates on the difficulties of the design and a potential timeline.

If the above method is infeasible, I would recommend using Wormhole at this point. However, BNB Uniswap should have the ability to switch the message-passing provider at a later date through governance.

We hope @devinwalsh could open a new thread specifically for x-chain messaging outside this one since this discussion is going to be important for future and past x-chain developments.

Edit 2: Add clarification around ranking.


Hi @modong,

While we appreciate your reply to questions and concerns, we do not feel as though you sufficiently addressed them.

From our post we raised the following concerns and questions:

  • The Message Bus contract has an owner which can upgrade the contract implementation, thereby changing the logic.

  • We don’t know who the EOAs are on the SimpleGovernance contract.

  • You did not share any further documentation on your “optimistic-rollup-style” security model.

  • You did not share any further documentation regarding running an app guardian.

In your reply to said the following:

If we are understanding this correctly, the App Guardian has the ability to pause the bridge contract autonomously if no matching transaction is found. Can you please confirm this point or point us toward documentation?

Also, the current cBridge contract on BSC appears to have six Pausers. Of which, all but one are also on the governance contract.

  1. 0x1a0aec0fc48f1b5cc538be74a90e340b278189e4

  2. 0x2fb8783c14a71c08bfc1de8fc3d715dd93039bf2

  3. 0x9f6b03cb6d8ab8239cf1045ab28b9df43dfcc823

  4. 0x34dfa1226f8b3e36fe597b34eea809a2b5c0bbf9

  5. 0xdfe4f07d1f36b8d559b25082460a4f6a72531de2

  6. 0x1b9dfc56e38b0f92448659c114e2347bd803911c

Do you have some documentation you could share on the above quote?

Separately, to address your latest post, “A Vender-lock-in-free Universal Governance Mechanism,” this forum thread is only regarding the BSC deployment.


great information about cross-chain