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

[Naught]

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.

[modong]

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.

[LayerZeroLabs]

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]

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.

@devenmatthews

cryptographic security >>> crypto-economic incentives

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

@devenmatthews

Does required stake/slash make it significantly unprofitable to exploit bridge

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.

@devenmatthews

Uniswap is not ready to adopt a single bridge provider

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

@GFXlabs

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.

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.

@GFXlabs

Does their documentation clearly explain how their system works, not just in concept but, most importantly, in execution?

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?

Summary

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.

[GFXlabs]

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:

@modong

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.

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

@modong

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.

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.

[Elissawi2021]

great information about cross-chain

[devinwalsh]

Hi all! Thank you for your comments and discussion over the past few days. As you have seen in the forum, new information on the bridge selected in the Temp Check proposal (Celer) has been made available since the Temp Check took place. Additionally, two new bridges – Wormhole and Layerzero – have raised their hands to be the provider for the BNB deployment (in addition to deBridge, the initial bridge selected prior to Celer).

For cross-chain deployment proposals, we believe it is most important to optimize for protocol security — specifically, for community members to be able to make informed decisions based on all available information on risks to bridge security. Secondary to that is clarity of process for all governance stakeholders. In order to satisfy both of those conditions, we propose the following next steps for this BNB proposal:

1. For this BNB proposal only, we will have an additional Temperature Check for the community to vote on the four bridges which have been discussed in the forum or this proposal: deBridge, Celer, Wormhole, and LayerZero. This proposal will be kicked off by 0xplasma team at ~6 AM EST on Friday Jan 27 and last for 5 days until ~6 AM EST Tuesday Jan 31. (To be clear, we do not intend for this to set a precedent of bridge-focused Temp Checks in the future. We speak to creating an improved process in the future below)
   Snapshot poll is live now: Snapshot
2. At that point, the winning bridge with the most UNI votes will be used in the final governance vote for the BNB deployment. The final governance vote will kick off on Tuesday Jan 31 after the completion of the Bridge Temp Check.

Looking forward, it is clear that cross-chain proposals can be improved for all governance stakeholders. Assessments of bridge security are time intensive and require significant technical expertise and context. Tomorrow morning in a new forum post, we plan to propose an initiative which aims to provide the community with an independent technical assessment of bridge risk for the community’s benefit. We plan to move this initiative forward ASAP so the results may be leveraged in upcoming cross-chain proposals.

[DAOstrat.C]

The steps laid out here provide a promising path forward for a successful deployment on BNB sc & future cross-chain deployments.

Special thanks to all the community members who brought research to the forum to aid in the DAO decision-making process. Especially the efforts of @GFXlabs, who worked diligently to review and test various providers.

Regarding future work into bridge diligence, we commend @devinwalsh and the Foundation’s efforts and will assist wherever possible.

[modong]

@GFXlabs team, thank you very much for your replies. We want to summarize and supplement some of our answers to your questions.

@GFXlabs

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

It does have a multisig owner that can upgrade the contract logic. However, for Uniswap’s use case, the upgradability won’t pose a risk because even if a fraudulent message is passed to the destination chain somehow (be that due to a malicious contract upgrade or validator consensus failure), the App Guardian will be able to stop that message from being executed.

@GFXlabs

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

Celer has a total of 21 validators, which are highly reputable PoS validators securing chains such as Binance Chain, Avalanche, Cosmos and more, such as Binance, Everstake, Infstone, Ankr, Forbole, 01Node, OKEX, HashQuark, RockX and more. Many of them are shared validators with Wormhole.

For the simple governance contract used to upgrade smart contract, the signers are InfStone, Binance Staking, OKEX and Celer Foundation. We will add that to our documentation section.

@GFXlabs

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

@GFXlabs

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

Apologies that we forgot to follow up on this. For the most direct reference, please see the reference implementation of the “optimistic-rollup-style” security model that is running for Uniswap testnet and updated doc on how to run an App Guardian.

@GFXlabs

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?

This is correct. However, this is only for the cBridge use case. For Uniswap’s use case, the app guardian set can be different.

@GFXlabs

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

There might be a misunderstanding. The vendor-lock-in-free architecture is relevant in this case because it applies whenever a new chain is added to Uniswap’s supported chains. For this BSC deployment, multiple bridges can be used simultaneously to achieve much better decentralization and security.

To @Kydo team,

Thank you for your review and comments.

@Kydo

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

We 100% agree. deBridge, Celer and you all raised the same point. That is half of the active participants in this discussion. This is not hard to do. In addition, we offered to make an implementation available within 72 hours.

Unfortunately, despite all the above, an option to build a vendor lock-in-free architecture was still not made available in the recent temperature check for the Binance Chain deployment.

There might be a strong and valid reason to push the deployment of a less open architecture under an extremely tight deadline.

If you still would like to support this open architecture for an open dex like Uniswap, please vote for Celer. Regardless of the outcome of the temperature check, we will implement the architecture in a vendor-lock-in-free way in 72 hours and conduct audits with community-approved firms to make it readily available as a contribution to the Uniswap community.

Even if it is too late for Binance Chain, we sincerely hope that future Uniswap expansion can be done using this open and flexible model and the value of Uniswap community can remain open and decentralized.

We hope our push for open and decentralized architecture can be heard in this community.

@Kydo

but the economic guarantee behind them is much weaker.

Could you please elaborate on this concern?

Celer is run by 21 validators who are all renowned PoS providers, such as Binance, Everstake, Infstone, Ankr, Forbole, 01Node, OKEX, HashQuark and RockX, many of which overlap with Wormhole’s validators. In addition, Celer contains built-in slashing mechanisms. Wormhole does not have any economic security or slashing built in the protocol. If there is any other centralized/off-chain agreement, we hope wormhole can make them known to the community. Just by looking at this comparison, a reasonable level of economic security in protocol >> 0 economic security in the protocol.

Of course, Celer is also working towards building additional zero-knowledge-succinct-proof-based cross-chain message-passing mechanisms that remove the responsibility of message correctness/security from the validators altogether and only rely on them for liveness.

[AlexSmirnov]

Proposed implementation of a Vendor-Lock-in-Free Universal Governance Mechanism for Uniswap

We appreciate deBridge being included as one of the solutions proposed in the temperature check, but we’d also like to support points raised by @Kydo and @modong and express concern that the current temperature check process seems rushed in the sense there are options proposed by participants of the discussion that have not been explored. Moreover, we agree with Kydo and Mo that Uniswap should not lock in one vendor when the possibility of choosing multiple exists with a similar level of complexity to the proposed single-bridge solution.

Uniswap must consider several key objectives — to achieve a decentralized and resilient solution with no one point of failure, and to enact a solution that is consistent with the stated goals and objectives of the Uniswap community. In order to achieve this, Uniswap must avoid reliance on any one bridge/interoperability protocol.

A bridge-agnostic solution

Thus, we present a bridge-agnostic approach for Uniswap Cross-chain Governance which suggests leveraging multiple bridges for passing Governance Actions to secondary chains, and executing such Actions only whenever each was delivered by at least a given number of trusted bridges.

At its core, we propose using a set of permissionless smart contracts on both chains (the master chain — Ethereum in this case — where Governance resides, and any secondary chain — BNB Chain in this case, though there can be more) which together form a permissionless multibridge transport protocol on top of existing battle-tested governance model for secured delivering and executing cross-chain governance actions.

Technical breakdown

The first layer of this approach is a permissionless Uniswap Multibridge Sender contract, which is directly controlled by the Governor contract. This contract is responsible for keeping the whitelist of trusted bridges Governance decided to use for message passing, and their corresponding permissionless Bridge Adapter contracts. Whenever there is a necessity to execute a Governance Action in a secondary chain, a Proposal to call a Uniswap Multibridge Sender contract is published using the existing workflow.

When a Uniswap Multibridge Sender Contract receives a Governance Action from a Governor contract, it triggers permissionless Bridge Adapter contracts for every corresponding trusted bridge. These Bridge Adapter contracts are needed to unify interfaces and behavior that are typically different across cross-chain bridges’ contracts. When the Bridge Adapter is triggered, it calls its bridge’s Gate/Relayer contract, passing the Governance Action as a message and specifying the address of the corresponding trusted permissionless adapter on the other chain as a receiver.

Every time the message is successfully broadcasted to the destination chain by any of the trusted bridges, it actually lands on the corresponding destination Bridge Adapter (as specified upon sending). This message is here transformed into a unified structure with technical metadata taken from the bridge’s gate/relayer. This metadata may include the address that actually initiated a cross-chain call.

The unified structure is then passed to the Uniswap Multibridge Receiver Contract, which authenticates the message by checking that it was sent by and received by trusted Bridge Adapters. Then, the actual Governance Action is extracted from the message and is passed to the Delegated Governor contract along with a bridge ID it was sent through for a staging phase.

A Uniswap Delegated Governor Contract accepts Governance Actions from the Uniswap Multibridge Receiver Contract it trusts, grouping them by their hashes and by the bridge IDs they were broadcasted through. Whenever the number of messages coming from different trusted bridges and shipping the same proposal reach the consensus (for example, ⅔ of delivered messages), this proposal is allowed to be executed normally, as it happens within the existing governance framework used by Uniswap.

A more resilient and decentralized solution

The beauty of this approach lies not only in the fact that it is completely bridge-agnostic and thus won’t get stuck due to a third-party failure, but also in fact this approach and any of its underlying components may be governed the same way Uniswap is governed: whenever there is a necessity to disable a specific bridge, or add another one, or change the expected threshold of delivered messages — a Governance votes for Proposals on Ethereum which emit cross-chain Governance Actions, which are then broadcasted and executed as prescribed.

In conclusion, this bridge-agnostic approach will better prevent message forgery while increasing the durability and deliverability of messages, creating a more secure solution that is consistent and compatible with the governance logic of Uniswap. Crucially, this design allows for flexibility and fault-tolerance in the event any participating bridge fails without recovery.

A lot of good business shapes for this approach are described in @modong’s comment

Finally, this generic framework is more scalable than the single-bridge framework — it can be replicated for additional chains, enabling Uniswap to integrate new chains efficiently and safely while having full control over bridge-selection (useful in the scenario the chosen bridge does not support a new chain).

If deBridge is chosen for the temperature check and further governance voting, the Uniswap-deBridge integration will be built in the context of this bridge-agnostic framework and thus, will enable other bridges to participate.

[Porter]

Hey everyone,

Porter and Guy writing from a16z. Given the expiration of Uniswap V3’s BUSL license in early April, we’re generally in favor of deploying Uni V3 to other chains before that date to avoid the copy-paste rush that will likely ensue otherwise. This has the added benefit of ensuring there’s an official deployment cycle so users on those chains can trust they’re using the original code base – preempting possible bad actors or just carelessness. Deploying Uni V3 obviously won’t forestall forks from occurring, but at least it offers an official version to users seeking that forum.

Additionally, as @devinwalsh’s comments suggest, we would also be in favor of a more formal process for choosing third party service providers or integrations for Uniswap going forward.

In our eyes, it’s important that Uniswap is able to create a level, objective playing field for all parties wanting to build or aid in its development. The community remains the ultimate decider once those conditions are set, but it’s key to foster a structured process that enables outside parties to fairly compete on the merits of their proposal. Like anything else, this competition benefits Uniswap long-term as a credibly neutral, market-based platform. It should receive the best services, at the best prices (if pricing is included) by choosing from the widest selection of parties given the same set of operating instructions. A structured process allows time for appropriate due diligence, weighing of pros and cons for each provider, and a comparative analysis that is difficult to conduct otherwise.

---

For transparency and timing, and because an end-to-end process has not fully occurred for this particular vote, the second part of this post outlines our preferred choice for Uniswap’s bridge provider.

To that end, we believe that LayerZero offers the best bridging solution – for transparency, we invested in them. We believe they are the most secure, decentralized, and philosophically aligned partner for Uniswap. Full investment disclosures can be found here. You can read our original investment thesis here for historical context.

LayerZero uniquely offers the capability for Uniswap to own its own immutable smart contract, while also enabling Uniswap to change or upgrade the security model of the bridge at the community’s discretion in the future. They’ve also delivered: LayerZero built out an omnichain governance module for Uniswap, found here.

Our support in LayerZero’s offering stems from its:

(1) Immutability - Uniswap can deploy LayerZero’s contracts and own them without having a dependency on LayerZero. Other bridge deployments can be changed by the bridging provider, but Uniswap could choose to be the only one with the capability of upgrading its bridge.

(2) Open and permissionless nature - LayerZero is open source, modular, and ownable by the applications that integrate it. Please see LayerZero’s implementation for a Uniswap governance executor open source here. Uniswap can future proof its deployment by choosing the oracle, relayer, validation library, and blockchain confirmation parameters in its deployment.

(3) Creation of extendible immutable validation libraries - LayerZero is building multiple validation libraries and provides the most modular bridging architecture we’ve seen. Uniswap could choose to implement a new validation library (a ZK light client for example) when it becomes battle tested. Importantly, this upgrade could only be done by Uniswap itself. LayerZero enables Uniswap to own and run its own bridge.

To highlight a critical point, LayerZero alone offers the ability for Uniswap to run its own Oracle or Relayer network using the LayerZero architecture, providing the most secure and modular message delivery system because Uniswap itself is participating in its execution. If the Uniswap community sets its oracle, relayer, validation library, and block confirmations in the endpoint settings, there is nothing anyone else can do to change it – it is immutable and only in the hands of the Uniswap community. This embeds flexibility to also take advantage of future cryptographically secure validation layers.

Others have brought up the core concern of security considerations. To date, LayerZero has processed over $5B in transactions with over 700 applications deploying 2,000 contracts without a single hack. Other bridge providers cannot point to this track record. Past performance is not an absolute guarantee of future success, but it is a strong indicator. To @GFXlabs’ first evaluation criteria, “How long has the system been running, and how much value has it been responsible for?” In our opinion, LayerZero has a demonstrated track record of success at scale that is unique amongst bridge providers.

In this vein, cross-chain Uniswap deployments should not compromise the decentralization of the protocol unduly, or introduce unnecessary risk without careful consideration. We do not believe that arbitrarily upgradable contracts owned by the underlying bridging provider or controlled by an external third party are in line with the ethos of community-centric, decentralized governance. LayerZero offers a credible alternative to that reality for the Uniswap community.

While we currently believe LayerZero is the best option, we will evaluate any other proposals in good faith and ultimately vote for what we think is best for Uniswap.

We appreciate everyone’s time and consideration.

[eek637]

We’re supportive of this plan of action (new snapshot soonish, gov vote close behind) for this particular case. Also very much into pursuing both a formal review process for bridge providers and investigating a multi-bridge solution as @AlexSmirnov lays out in a subsequent comment as a separate endeavor following the BNB Chain. I think each of those subsequent actions require some thought around the resources that’ll be required for their implementation and we’d be better served considering them in isolation rather than as a component of another proposal.

[aesthetic]

Hello! Chiming in on behalf of Blockchain at Berkeley:

We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.

Given the ongoing scrutiny and cooperation with the bridge providers, we believe that a temperature check for specific bridges at this stage may not be the most effective approach.

Currently, it is difficult to make a point-to-point comparison between the proposals from the four main contenders, since there is not enough detailed information on the proposals. Providing detailed, finalized proposal summaries from the bridges is essential for the community to decide on the best providers to move forward with.

It is important to note that there are some concerns regarding all the existing bridge providers and their ability to fully meet the needs of Uniswap’s governance message passing. While we recognize that each provider has its own unique strengths and weaknesses, it is essential that a thorough evaluation of all proposals is conducted to ensure that the best solution is chosen for the community. In particular, issues such as decentralization, economic incentives, and transparency of operations should be carefully considered before making a final decision.

Furthermore, we suggest that it may be beneficial to consider an alternative approach, such as outlining specific requirements for the ideal Uniswap bridge and choosing a vendor based on their ability to meet those specifications. This could help to avoid the “lesser of two evils” problem and ensure that the best solution is selected for the community.

[modong]

@aesthetic

We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.

Thank you Blockchain at Berkeley team. As promised, we will be providing a reference implementation very soon for this. The difficulty level of implementing a multi-bridge solution is not really harder than implementing a single-bridge solution.

[devinwalsh]

Hi all, note that the Snapshot poll on which bridge to use for the BSC deployment is live now: Snapshot

[LayerZeroLabs]

We’ve recently had open discussions with many of the delegate groups around the security features and fundamental architecture of LayerZero and its fitness for secure and scalable omnichain governance for the Uniswap protocol. The following are key topics and outcomes from the discussion shared publicly for the community’s awareness:

—LayerZero’s omnichain governance executor (complete open source code here) is designed to enable Uniswap governance to add, remove, or swap validation layer components directly from on-chain votes via GovernorBravo.

What this means: Security of the protocol’s cross-chain governance can scale with the protocol over time. Governance always maintains the ability to propose and vote to change parameters which, if passed, are executed on-chain via GovernorBravo and amended in the smart contracts owned by Uniswap.

—LayerZero created and deployed a gasless oracle for applications to participate easily in their own security

—Major Uniswap delegates and top stakeholders (such as the most strongly incentivized investors of the protocol, L1/L2 Foundations, and major security and infrastructure platforms) can run a gasless oracle as part of the network.

To provide additional context, several of these organizations are already actively involved in the ongoing decentralization of LayerZero’s validation layer.

What this means: We’ve implemented a gasless signing mechanism to allow a group of ad hoc parties to easily manage an ad hoc oracle network between them. The gasless oracle is a brand new feature we had planned to announce in late February; documentation will be completed shortly. The LayerZero Labs team will commit dedicated human capital and technical resources to assist teams to fully run the node; estimated set-up time is less than 2 hours from end-to-end per team.

We propose that Uniswap utilize a gasless oracle of at least 5+ signers. We recommend a consensus grouping of the most respected industry entities and aligned parties with Uniswap (which Uniswap has already done an amazing job attracting via its Delegates) which will provide the most secure and aligned security structure to the protocol itself.

—We propose that at launch, Uniswap chooses to pair a gasless oracle run by a minimum of 5+ significant Uniswap delegates and the LayerZero Labs relayer as their validation layer within the broader LayerZero security model.

In the future, governance may choose to update these hyperparameters via an on-chain governance process enabling robust, flexible, and governance driven security.

We thank the delegate groups who reached out to us for their time and commitment to Uniswap governance and look forward to conversations with more stakeholders over the coming days.

[Leighton]

I’m voting for LayerZero because based on my reading of the thread & professional experience I believe that is the best option.

I would note though, if there was an abstain / wait option I would’ve chosen that. I do not believe this is the type of decision that is well suited for a token vote. I’m a big fan of @devinwalsh’s plan to form a committee to evaluate options in depth and I would follow the recommendations there.

I also question if a bridge is even strictly needed right now. Since its only bridging governance commands presumably this could be added later? I’d prefer that option.

[notdeghost]

Adding my own two cents here, for context we provide security audits to both LayerZero and Wormhole.

The security models are quite fundamentally different, but both bridges - as far as we can tell - care very deeply about security. In my opinion, the primary question voters should evaluate is which security model/assumptions they think is more suitable for Uniswap, as opposed to the implementation risks which are relatively minimal.

[Kydo]

Thank you for posting this updated proposal, LayerZero.

We believe this proposal addresses a lot of the questions we have raised before. And their ability to change Chainlink with a set of Uniswap-aligned oracle validators is very promising.

For total transparency, LayerZero reached out to us and addressed most of our technical concerns.

One thing we believe we undervalued, in our initial assessment, is the immutability of the bridge. Many hacks happen because of simple upgrades. Under LayerZero’s design, the underlying infrastructure (LayerZero protocol) is immutable. The changeable parts, the Oracle (header sync) and Relayer (MIP), can only be changed by Uniswap governance.

Given the immutability and LayerZero’s new proposed Oracle, we would like to signal to the community that we have tentatively moved LayerZero as our preferred bridge provider for BNB.

We would also love to see more documentation provided from LayerZero’s side, especially around the oracle and relayer services.

[GFXlabs]

Hi Everyone,

Several folks have asked for our opinion on the current vote and the abnormal governance process. First, we would like to emphasize that the overall goal here is to deploy UniV3 on BSC in the near future, and we have been pleasantly surprised by the demand for the DEX to deploy on BSC. As for the abnormal governance process, we’re supportive of the Foundation’s move to post the Snapshot so Ilia can finalize the BSC deployment and their proposed working group to conduct a thorough review of each bridge.

GFX Labs has cast our vote for Wormhole in the current snapshot, and while we’ve made our concerns about Celer clear in the forum thread, we haven’t done the same for Layerzero.

Our primary resources for researching Layerzero

• Docs
• Ethereum Endpoint
• Ethereum UltraLightNodev2
• L2 Beat

For context, Layerzero messages are sent from the local Endpoint. Oracles are responsible for moving block headers from the source to the destination. Upon delivery, Relayers can deliver the transaction’s proof to the destination Endpoint. This model, in its current implementation, is a 2-of-2 msig.

Messages are sent to a verifying library. The verifying library (VL) manages oracles and Relayers on behalf of the application. The Ultra Light Node (ULN) is a VL. The Endpoint manages the relationship between the user application (UA) and the VL (the ULN, in practice). The UA selects a VL via the Endpoint. The UA may also configure that VL directly (e.g. by selecting a Relayer in the VL). Relayers submit proofs to the VL (the ULN, in practice), and the VL chooses how to validate these. In the ULN, the owner chooses proof validation libraries and may choose any contract.

Applications are intended to choose their own VL & Relayer since they can configure which library to use in the Endpoint contract. The Endpoint owner sets a default VL. However, the ULN is the only verifying library that exists, so all apps must use it.

We tried to review how the Relayer worked, but according to the docs the Relayer is not open-source at this time, which seems to line up with L2Beat’s concern of the Relayer contract being unverified.

Additionally, the only info we found in the governance section was “info coming soon!” This was not the answer we were expecting since there is an owner on the Ethereum Endpoint and UltraLightNodev2 contracts. The owner appears to be a 2/5 Gnosis Multisig. While the Endpoint isn’t a traditional proxy contract, it does rely upon referenced contracts for core logic and operation. The below owner controllable functions appear to be able to alter the functionality significantly.

onlyOwner functions on the EndPoint contract:

• setSendVersion
• setDefaultSendVersion
• setDefaultReceiveVersion
• renounceOwnership
• transferOwnership

onlyOwner functions on the UltraLightNodeV2 contract:

• setLayerZeroToken
• setTreasury
• addInboundProofLibraryForChain
• setDefaultConfigForChainId
• setDefaultAdapterParamsForChainId
• setRemoteUln
• setChainAddressSize
• renounceOwnership
• transferOwnership

The ULN’s owner can set the oracle, relay, proof systems, and other security parameters. It appears that the owner can entirely bypass the oracle/relay system in their current implementation.

Through this process, we arrived at the conclusion that Layerzero is not ready to be integrated with Uniswap. However, as developers ourselves, do we realize that the development process is fluid and that research is ongoing. Our vote reflects the current state of development and available information.