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

Hi raz from LayerZero.

So I want to first say we’ve never spoken to GFX Labs (despite reaching out) and although we now have time scheduled tomorrow (Monday), this analysis was written without a single question sent to us. I’ve gone through and done a line-by-line response to everything above but wanted to tl;dr some of the obvious mistakes in the analysis in case they get lost below in the broader post.

Firstly, GFX Labs missed the _getAppConfig() function which is the very first line of validateTransactionProof() with comments “Retrieve UA’s configuration using the _dstAddress from arguments.”

Taking a look at this function, you can clearly see that the first thing that it does is retrieve the User Application’s config and the default config.

Then it goes through each config item and if and only if the configurations are not set, the contract sets it to the default config item.

The crux of the GFX Labs argument seems to be centered around the perceived ability for the LayerZero ULN owner to be able to modify application parameters, however this is clearly not possible and enforceable in the immutable base layer of the code.

This seems clearly misleading as the two parties (oracle and relayer) are abstracted accounts with arbitrary implementation e.g. a fully decentralized network, not to mention the current proposal which I had assumed GFX Labs had reviewed extensively prior to this is for a new architecture with a number of major Uniswap delegates participating within the validation set.

The owner of the ULN contract cannot choose proof libraries on behalf of the user application. The owner can only add new proof libraries (i.e. append-only registry) of which the user application can select from.

The ULN can hold multiple validation libraries within itself for applications to choose from (ex. A zk-Validation Library could be added to the ULN V2 as a different method for verifying messages). This is an explicit design decision; LayerZero’s architecture supports the evolution of best cryptographic security practices. These libraries and the ULN itself are immutable and only by selection of the user application.

Most other bridges and messaging protocols offer blanket validation techniques and only upgradeable smart contracts. Many notable hacks have occurred due to a buggy upgrade forced upon applications built on top of a bridge’s infrastructure, including two identical instances from Wormhole resulting in a $10m bug bounty paid and then later reducing their bug bounty from $10m to only $2.5m.

To be clear, both of these issues are completely separate from the $325m hack Wormhole suffered.

We believe critical infrastructure should be immutable, open source, and always owned by user applications.

It is common practice to not open source or verify Oracle and Relayer smart contracts. These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library. In a competitive marketplace of Oracles and Relayers, unique pricing mechanisms are often the proprietary edge for providers. These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.

The governance section of our documentation is in reference to the upcoming open source governance module we proposed in this forum thread (see above).

The Endpoint Contracts are for setting default configurations for developers to be able deploy and test easily. It is recommended that applications desiring more control over their security opt to set their own configuration settings. Default configuration cannot override user application configured settings; this is an explicit design decision and a feature of a true protocol.

The UltraLightNodeV2 settings are a combination of default configurations and one-time setters for adding new chains and proof libraries. The multisig owner cannot change any existing configurations set by the user or modify any existing validation libraries.

This statement is both entirely verifiably false and addressed in the opening part of the post.

I hope the line by line was helpful. I know we haven’t gotten to speak yet but looking forward to speaking to GFX Labs tomorrow and addressing any outstanding concerns and walking through the proposed security configuration in detail.



Hey all, it’s Abdullah from Blockchain at Michigan

Firstly, we are glad to see the community’s ability to coordinate an unorthodox approach for deciding the Uni<>BNB bridge via an extra temp check. In an instance like this, it is imperative that we derive a quantitative measure for what the community is feeling as opposed to a soft metric like forum-based sentiment.

To that end, we believe that instead of prolonging the bridge discussion beyond necessary means, it is important for us to efficiently decide on a single messaging system. After one solution is implemented, we can focus on a multi-bridge system. The primary reason for this haste, as @Porter mentioned, is the limited amount of time we have to deploy Uni v3 prior to the license expiring on April 1st of this year. Perhaps this urgency is not warranted for other L1s–but for BNB Chain, quick deployment is necessary due to the BNB community’s hankering to quickly deploy forked code (the BNB ecosystem is very much quantity over quality at the moment) and capture much of the present user activity.

As of now, we are inclined to side with LayerZero for handling cross-chain governance. We put Wormhole and Celer in a similar bucket due to their reliance on a validator set, emblematic of a proof of authority mechanism. Naturally, such designs are less decentralized and subject to collusion.

Potentially, Celer’s current total stake is not large enough from a dollar-value standpoint to be secure. Over time, this should resolve since the ability of an entity to buy up 2/3 of staking dominance will become harder–granted the SGN system proves viable over time and the CELR token remains strong. As for Wormhole, they have stood the test of a major exploit and have since made their system more robust, with a continual promise to prevent future exploits via a large bug bounty program and a multitude of audits. However, our main contention with Wormhole is, again, the limited 19-entity validator set. We realize the credibility of the guardians and how much stake they have to lose from a reputation perspective. But when the going gets tough, entities often focus on doing whatever they can to merely survive, forgoing their pristine reputation.

We are not limiting the merits of Wormhole or Celer; however, we feel that when the option to select a system that allows for a higher degree of control over the messaging stack is present, we should select that method. LayerZero would allow the Uni community to control its parameters (oracle and relayer) however it deems fit without the risk of collusion between a handful of validators. Yes, the risk assumption for LZ is that the relayer and oracle are themselves uncorrupted–Uniswap is not likely to face this issue. Unlike other applications using LZ, Uniswap has a robust, distributed governance base. The alteration of the relayer and oracle would require the community to collectively decide parameters, making malicious activity very difficult. That is, unless a hacker alters the parameters by subverting the governance process somehow.

We will cast our vote later tonight after our final discussions with Jump and LayerZero.


Hi Raz,

We devoted a chunk of time to reviewing and researching a bit over the last few days. The questions and concerns raised in our message come from our good-faith efforts to review the resources available. To recap, as part of our review of Celer’s system, we identified significant differences between what was advertised and what is actually happening. Since then, we’ve been attempting to verify anything we read on the forum as part of our own due diligence process.

We have made efforts to review each bridge with the limited knowledge and resources we have available. While we have a pre-relationship with Wormhole, GFX only works with projects that we believe in and have first-hand knowledge about. Our primary duty, however, is to advocate for Uniswap’s success. While our post might, in hindsight, contain some inaccuracies, it was made with good intentions after reviewing publicly available documentation and included an open offer to utilize your technology — importantly, many of the core criticisms remain.

Regarding the only owner functions. We’ll edit our prior post to reflect that change. Thank you for the clarification.

LayerZero is running the Relayer, and Chainlink is running the Oracle. While these are independent entities of which multiple could theoretically exist to process messages, only two exist at this time. This is functionally a 2/2 multisig, both parties must agree; otherwise, the message will not be processed. We were able to find information on how to run an oracle, but as you said, the existing relayer is currently closed source, and we cannot find an MVP example for a full relayer setup (both on and off-chain components).

  • Could you help us understand what would happen to message passing if either of these two systems went offline?
  • What would happen if the two systems colluded?
  • We assume the goal is to have multiple relayers. Can you estimate when you think the code or simpler version of the relayer might be released so additional members can participate?
  • What is the incentive for new participants to join the system as an oracle or relayer?

As for the unique signing model proposed, we’ve discussed with a few delegates about utilizing a multisig for UniV3 deployments over a bridge and came to the rough conclusion that delegates would not be comfortable being on that multisig due to the perceived legal risks. Our intent is not to need additional signers. Thus our efforts have been put toward finding a bridge partner. The recommendation of additional signers seems to speak to the lack of parties participating in Layerzero 0.

Suppose Uniswap was to consider the signer method. Would it not make the most sense to utilize Chainlink’s Oracle system directly, with the Uniswap signers filling the role as the relayer? It seems that would be the strongest combination because the alternative would be to remove the most secure component (Chainlink) from the stack and replace it with the least secure solution (Uniswap Signers).

To make sure we are on the same page - is this also the only current possible configuration, assuming that Uniswap does not take charge of the Oracle or Bridge duties?

If this is the case, then what is the true cost of using L0 as a relayer? Assuming that Uniswap will not move to run its own relayer, is there any other mechanism to prevent a monopolistic relayer from price-gouging messages through an upgrade? If not, how quickly would Uniswap be able to modify its cross-chain infrastructure such that it could continue performing cross-chain messaging at a reasonable price?

Thank you for the clarification.

While that makes sense, we think it would have saved a lot of time for everyone if the owner functionality was better documented.

Thank you for the prompt answers. We appreciate the clarification, and I’m sure the other delegates reading the thread do as well.

As a final request for now, can you please deploy your proposed system on testnet and link the relevant transactions as we have done with Wormhole? We don’t want to delay the BSC deployment any further than necessary.

1 Like

I like the new governance flow, but it is difficult to find the snapshot post/link in this thread. Have to keep scrolling up to find this post, when checking on the vote status.

A suggestion if possible: have a “snapshot is live” button under the thread scroller on the right side where the “reply to thread” and “notifications” buttons are.

1 Like

Throwing in some comments here. We’ll preface by saying that considering how “unexpected” this discussion arose, we appreciate the UF team for their quick thinking and on the feet decisions.

When looking at the main debate surrounding L0 and Wormhole, we’re still internally conflicted on which is ultimately the best, and think each has benefits of their own. Ultimately, we don’t think this proposed structure of finding a bridge partner is ideal and sets a bad precedence. We propose:

  • A working group that gets set up will “whitelists” all bridges looking to be a bridging solution. This can be confirmed with a governance vote if deemed necessary.
  • Once a bridge passes this step, they will enter an “approved” pool
  • When “x-chain” wants to deploy, they can work out individual relations with any “approved” bridge as their partner
  • As @Kydo mentioned with us, the partner bridge for “x-chain” can be multiple bridges that cross check each other and can decrease further the chance of malicious actors.

Overall, this reasoning stems from: 1) we believe there are multiple valid bridges/solutions to this question. 2) Combining L0 & Wormhole & maybe other bridges with a majority rules outcome will present the best security 3) Puts incentives with bridges and “x-chain” better in our opinion to market compete in each situation.


Just to be completely objective when we are choosing a bridge for Uniswap v3, I ask all community members also to read the report published today by James Prestwich, regarding the potential vulnerabilities in LayerZero contracts.

@GFXlabs @pennblockchain @AbdullahUmar @Kydo @Porter

:exclamation:Full article: ZeroValidation - by James Prestwich - Proof of James

We are very much looking forward to the comments from the LayerZero team @raz , as our snapshot bridge poll is coming to an end tomorrow.


I would say that’s one of the least objective posts of all time. I responded to it here albeit in not a very formal tone and I’d like to state clearly that it’s both wrong, misleading, and has absolutely 0 impact on the proposed Uniswap architecture because as discussed in the proposal Uniswap would not be using the defaults and would be selecting their own oracle, relayer, and VL.


Did anyone consider Axelar?

With Osmosis opting for it over Wormhole in their search for a canonical Ethereum bridge, which some might argue was more thorough, I think it’s worth considering.

1 Like

Thanks for the clarification, Bryan!

Yup 100%! Just want to make sure there is clarity

I believe it’s too early to pick any solution. Because all these solutions are early, Uniswap is way too important for this ecosystem’s health, and we still haven’t fully understood each provider’s implications and loopholes.

Would love to provide some insightful links, but don’t have the permissions.

1 Like

We know we’re late to the party, but we wanted to throw our hat in the ring as well. We understand it’s too late to be formally considered in the temp check vote, but we’d love to have Hyperlane (fka Abacus) considered in future votes. We were previously involved in the RFP process, and chosen by several well known delegates alongside Axelar, which is also conspicuously missing from this vote! You can read more about that here: RFC: Uniswap Universal Governance Module - #21 by blockchaincolumbia

We’ll be submitting our case formally through the Cross Chain Bridge Assessment process, in that thread, using the template provided.

1 Like

Hey all, we’ve (a16z) reviewed the various bridge proposals, evaluated each, and strongly support LayerZero. We’re unable to vote in the current Snapshot due to infrastructure limitations with the custodian on short notice, but we will be participating in the on-chain vote when it goes live, in addition to any new Snapshot votes that may come up. We just wanted to put this out before the vote ends tomorrow morning for clarity on the process from our end.

On Running Infrastructure and Bridges

There’s been a lot of back and forth in the thread around immutability, decentralization, trusted entities, and degrees of control by cross-chain messaging protocols. We wanted to clarify these discussion points by calling out the two ways Uniswap would integrate a messaging layer and comparing the guarantees of both Wormhole and LayerZero under each scenario.

Simply put, the two scenarios are:

  1. Uniswap runs infrastructure
  2. Uniswap doesn’t run infrastructure

Uniswap runs infrastructure


LayerZero suggests that integrators can either use their “default” configuration, a low-security option or run infrastructure via a “custom” configuration.

The latter model is proposed as the method by which the application developer (in this case Uniswap) can avoid collusion risk between the default Oracle and Relayer infrastructure operators within LayerZero. Additionally, in this model, Uniswap or its delegates would need to run infrastructure such as a “gasless Oracle” (which has not been released yet), which the LayerZero Relayer would pick up and deliver to the destination. Relayers in LayerZero are always permissioned and are required for liveness and security, thus Uniswap would also have to run Relayer infrastructure. The Relayer source code is currently not open-source, so Uniswap would need to implement a bespoke untested solution or run LayerZero’s proprietary implementation.

However, this may still be problematic. Due to the Proof Library requiring ongoing mitigation with each chain, a non-default config is **insufficient until the issue above is addressed. The LayerZero team can add a new default chain config, register a default proof handler, and exploit an application in a single atomic transaction. The application cannot mitigate this using configuration. Applications can only mitigate via a custom relayer and potentially an “approved chains” list in the application itself. The flagship application on LayerZero, Stargate, itself is semi-immutable and will have a difficult time mitigating this issue, and would need to make a custom Proof Library to implement the approved chains list.

TL;DR — if Uniswap does not want to trust LayerZero’s current default configuration, it needs to run its own infrastructure. Even when doing so, there are underlying issues that necessitate further action from LayerZero’s team to truly make any custom infrastructure setup truly trustless.


We want to clarify that if Uniswap wants to run its own infrastructure with Wormhole, it can achieve the same level of customization that LayerZero touts, as no protocol has a monopoly on deploying bespoke infra. If desired, Uniswap can configure a deployment of Wormhole, which improves upon the security guarantees of LayerZero’s default while also ensuring sovereign security relative to the canonical Wormhole deployment.
Wormhole’s contracts are designed so that the Guardian set is customizable on initial deployment (see here: Setup.sol) and can further be rotated via an in-protocol governance mechanism whereby the current guardian set can vote on the next guardian set. Should Uniswap delegates decide to run their own infrastructure, they may run their own oracle nodes by following instructions at Operations.md. In this model, Uniswap oracles produce signed observations (VAAs) which can be submitted permissionlessly on the target chain (BNB), so no relayer infra is needed, and therefore no need to manage gas funds. However, relayers can very easily be made permissioned if desired, which would allow Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.

From a security and operational load perspective, however, we could offer Uniswap to layer their signers on top of Wormhole i.e. extend the already robust Guardian set with their additional validators. This option surpasses the level of flexibility and security of LayerZero’s oracle (in this case Wormhole) and Relayer (chosen by Uniswap) mode in which Uniswap benefits from Wormhole’s significantly more robust signer set but is safe as long as the signer set does not collude with the Uniswap chosen signers. We start from the far stronger base of 19 signers and can arbitrarily increase security beyond that with additional Uniswap-affiliated validators. The easiest way to produce these additional signatures is for the Uniswap DAO signers to download and run the existing, open-source, and in-production Wormhole oracle software. After verifying the Wormhole signatures, the Uniswap governance contract can verify these additional signatures from the selected Uniswap DAO signers. Additionally, relayers can very quickly be permissioned, allowing Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.

While the proxy contract can point to different implementations, the Wormhole implementation contract is immutable. Thus it is trivial to verify governance messages against a specified implementation. While there are multiple ways to accomplish this, the most straightforward is just including the pinned implementation as an external library in your deployment.

This deployment can be done in a fully permissionless manner without having to trust (or ever interact) with the 19 Guardians that operate the default Wormhole deployment.

Uniswap doesn’t run infrastructure


The security assumption of LayerZero’s default configuration is that the default Oracle and Relayer are independent. Uniswap would have to trust a 2/2 multisig of these two components. The relayer is unverified, but LayerZero claims that this is not an issue:

“It is common practice to not open source or verify Oracle and Relayer smart contracts. *These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library.
*****These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.”

This statement contradicts with the LayerZero whitepaper, which claims the following:

“Given two entities that do not collude, if (1) one entity can produce a block header for the block containing tA on chain A, (2) the other entity can independently produce the proof for tA on that block (transaction proof), and (3) the header and transaction proof in fact agree, then the communication protocol can deliver m to the client on chain B with the guarantee that tA is stably committed on chain A.”

The Oracle is responsible for producing the block headers, and the Relayer is responsible for the inclusion proofs — these responsibilities are far beyond on-chain gas quoting.

“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).”

At this point, it’s unclear if there are other Oracle/Relayer options available to choose from outside of the default. In any case, if the Oracle and Relayer collude, they can forge messages.

Contract upgradeability is a critical discussion point. It’s true that bugs can be introduced in upgrades, but upgrades can (and do) fix existing bugs. Presenting only one side of this coin is misleading at best.
If any bugs are discovered in LayerZero’s contracts, patching them would be a significant task. Such a scenario would involve the proof validation code being implemented with a patch, and then all affected user applications would have to change their configurations to the patched implementation.


The 19 Guardians that operate Wormhole’s default deployment are the largest PoS validator companies. The safety assumption is that of an honest superminority (at least 7 of them are honest) or, conversely, that there are no 13 colluding entities. The equivalent assumption under LayerZero’s setup is that the 2 entities do not collude. The contracts are upgradeable via a governance mechanism that requires the approval of 2/3+ of the Guardians. Importantly, the Wormhole cross-chain governance solution has already been tested (see above) and implemented on testnet and is ready for production.

Happy to answer any additional questions.

1 Like

Hey all, cross-posting a few thoughts from Twitter.

1/ great to see the snapshot driving attention/clarity on bridging’s role in cross-chain protocol deployments

2/ I’m abstaining from the vote as I don’t think the list of options on offer is comprehensive or deeply researched

3/ zooming out, my view is that its suboptimal for communities to be voting on singular bridge choices, effectively king-making solutions.

protocol design needs to adapt for a multi-chain world, to reap the benefits of competition through standardization, not voting.

4/ closing thought: glad the convo is moving forward , and hope this proposal will kick off more efforts to dig deeper into bridge research and protocol design to enable multiple choices.


Blockchain@Columbia’s Uniswap governance team has considered this temperature check with great importance. We appreciated @jkol 's reference to our post the RFC: Uniswap Universal Governance Module - #21 by blockchaincolumbia shared by @jason_of_cs. For anyone who hasn’t, we encourage you to read the post where we proposed a “synergy between Axelar and Hyperlane[previously Abacus] inheriting the PoS validator-set model of Axelar (AXL tokens, which could potentially in an application-specific setting be just the UNI tokens) with the application-customizability of Abacus as having the ideal model for Uniswap’s current purposes, with UNI token holders freely participating in the system (this can be implemented in a variety of ways).” We took extensive time to consider various bridging providers including LayerZero, Wormhole, Nomad, Axelar, and Hyperlane (Abacus), which wouldn’t have been possible without @jason_of_cs a prominent researcher in the AMM space.

As we know, Axelar and Hyperlane weren’t considered for this temperature check, and it raises questions on the hast at which the community is coming to a decision. @pennblockchain, as well as other university organizations, have provided sound commentary on this debate, and we agree with @devinwalsh from the UF team that “assessments of bridge security are time intensive and require significant technical expertise and context.” As of the time of writing this post, it’s clear that LayerZero and Wormhole are the two competing players to win this temperature check, and we’re fortunate to have discussions with both LayerZero and Wormhole

In light of the commentary published by James Prestwich, reading forum responses, and our belief that there are many strong contenders in the bringing space not mentioned in this vote. We find it difficult to choose between, LayerZero and Wormhole, and if an abstain/wait option existed, we’d prefer to vote that way. However, as this is a temperature check, with a deadline of tomorrow, we will be voting for Wormhole.

With more time to assess the technicalities of each bridging option, perhaps we will revise our decision and vote differently for LayerZero or other providers.

1 Like

This will be our (Stanford Blockchain) final post here in this thread. More posts revolving around this issue can be found at Cross-Chain Bridge Assessment Process.

To save time and be succinct, we will focus this thread mainly on the top two contenders, LayerZero (LZ) and Wormhole (WH).

We would love to discuss further around other protocols in the thread above.

First at foremost, we enjoyed chatting with different bridge providers and their advocates. We believe as contentious as this vote is, this will not be the end for the cross-chain (x-chain for shorthand) governance discussion but the beginning.


We believe regardless of who will win the vote, this result should be temporary and should be immediately changed/updated when the Cross-Chain Bridge Assessment Process concludes. Our vote only convenes that we support the following protocol for a period of fewer than three months. In long term we believe Multi-Message-Aggregation (MMA) is the solution.

We have voted for LZ as the current preferred bridge provider. However, our vote is contingent on a few criteria. If LZ cannot fulfill these criteria, we wish to withdraw our support.

  • Uniswap governance message passing will use Uniswap-community-run oracle and NOT the default oracle by ChainLink.
  • The Uniswap-community-run oracle is mainnet functional no less than 3 days after the passing of the snapshot vote.
  • The Uniswap-community-run oracle have no less than 5 independent signers.
  • LZ will provide sufficient technical support for all oracle signers.

If LZ fails to deliver on ANY of the criteria above, Stanford Blockchain Club will NOT support LZ being the bridge provider for Uniswap governance.

Quick word:

We want to say that although the current snapshot will only have one “winner,” it does not mean the work other bridge providers did is wasted. In the next three weeks (laid out in the Cross-Chain Bridge Assessment Process), we would love to continue these conversations and find a long-term and more sustainable solution for x-chain governance.

As we have briefly mentioned in our previous posts (1,2), none of these solutions fits all our requirement and all of them poses serious governance risk to Uniswap; therefore we should not just decide once and move on from this issue. Instead, we should take UF’s proposal seriously and contribute more if not less time and energy to it.

Some key risks: Both WH and LZ’s oracle/relayer networks lack a slashing mechanism for malicious oracles. WH’s contract can be upgraded (can be patched with workarounds). LZ’s relayer is currently just LZ’s core team.

On bridging:

At Stanford Blockchain Club, we understand the difficulties of building bridges and more importantly, the current security gap between any bridge and the Ethereum network. We also recognize how early bridging technologies are and the security assumptions for these bridges might be drastically different from traditional blockchains.

We are not making statements about future designs of these bridges or what they could be; we are stating what we are seeing right now.

LZ and WH on a high level are both multisig bridges.
WH is a 1/1 multisig, with the 1 being 19 validators forming a 13/19 multisig.
LZ is a 2/2 multisig, with 1 being 5 Uniswap members, and the other 1 being LayerZero Lab.

If Ethereum’s current security level is 100, what would you assign to LZ and WH?

Therefore, we would not choose either of them to be the sole message-relaying solution for Uniswap long term. However given we have to make a decision now, we believe the LZ solution is the marginally better one.

Use all of them:

We believe the correct near-term solution is message aggregation from multiple bridges.

From our conversation with bridge providers and other delegates, we believe this is the most logical next step for x-chain governance in Uniswap.

We have proposed an in-depth design on the other thread, but this graph captures it well.

The governance flow is as follows:

  1. Uni Gov passed on Ethereum.
  2. Payload to different bridge contracts sent from Timelock.
  3. Different bridges relay to dst, BSC in this case.
  4. Bridges send governance payload to Message Selection Contract.
  5. A 11/15 multisig decides which message payload to execute.

Security analysis and design trade-offs are discussed more in the post.


To be totally unambiguous, we at a16z would have voted 15m tokens toward LayerZero if we were technically able to. And we will be able in future Snapshot votes. So, for the purposes of a “temperature check”, please count us this way.


The only question I have as a contract deployer is who will run Infra for Uniswap and custom LayerZero, and how we will manage it.

We’re excited to see the support behind deploying Uniswap v3 to Binance Smart Chain prior to the expiry of the Business Source License. At Spartan Group, we believe LayerZero’s bridge will be the most secure and decentralized solution for Uniswap, and will be voting to support their solution. We reviewed the different proposals, and believe LayerZero’s approach is the most thoughtful, and appreciate their willingness to engage with the community. Disclosure: we are investors in LayerZero (for the above reasons) and we are also significant holders of UNI tokens.

1 Like