LayerZero: Implementation for wstETH on BNB Chain and Ownership Acceptance by Lido DAO

Proposals
1

Introduction

We’re excited to see and engage with the open RFP for wstETH on BNB. Discussion, knowledge-gathering, and feedback cycles around Lido’s cross-chain expansion has been robust and encouraging to all of us building in the interoperability space.

LayerZero Labs submits this proposal to seek the Lido DAO’s formal recognition of this deployed wstETH token on BNB Chain as canonical. Should this proposal receive positive community feedback and DAO approval, LayerZero Labs will transfer ownership of the wstETH contracts to the Lido DAO and support Lido technical contributors with the configurations recommended below.

This proposal is written in accordance with the Network Expansion Workgroup’s (NEW) unofficial guidelines for bridging solutions. Our implementation and engagement with the DAO would not be possible without the ongoing feedback and encouragement from members of Lido NEW.

Overview

Formally recognizing a bridged wstETH token on BNB Chain opens up enormous growth opportunities for Lido by simplifying both user experience and developer experience and increasing DeFi composability across multiple chains.

Per community feedback and the unofficial guidelines for bridging solutions, the ideal wstETH on BNB implementation achieves the following:

  • Enables the Lido DAO to easily add or remove bridges and other validators (ex. zkLightClient, zkOracle, DON)
  • Minimizes liveness concerns by using a variety of validation mechanisms
  • Leverages battle-tested code to handle the substantial influx of wstETH into BNB without exposing Lido to an exploit or new surface attack vectors
  • Endows the Lido DAO with full ownership and control of the contracts
  • Gas efficient and gas-abstracted for end-users; it should be inexpensive and simple to bridge

Technical Implementation

Primary Components:

wstETH contracts - utilizes the Omnichain Fungible Token (OFT) open-source reference implementation contracts. The OFT Standard is an extension of the ERC20 Standard and is built on LayerZero protocol through a mint and burn mechanism. OFTs can be sent/received across any blockchain LayerZero supports while maintaining unified liquidity – though projects maintain rights to pick and choose which blockchains those are.

This standard implementation has been live and in production for 18 months, securing over $4.5 billion in transfer volume across 45+ chains. In addition, the OFT Standard has been extensively audited multiple times with no critical issues found.

Endpoint - immutable smart contract libraries deployed on each supported chain that can never be upgraded by the deployer, LayerZero Labs.

Endpoint libraries are append-only and accommodate new technologies without forced upgrades on applications. Developers enjoy a unified interface on all chains.

1600×539 27.8 KB

Oracle Configuration – contract owners always maintain the ability to configure the x/n validation layer. Note: expanding x/n increases overall gas cost. For the wstETH on BNB implementation, we recommend configuring the contracts to select at least the:

(1) zkLightClient and

(2) one of the aforementioned bridges, per the preference of the DAO

Explanation for Oracle Configuration:

The LayerZero protocol is specifically solving the transportation layer, not the validation layer.

LayerZero protocol features a single immutable endpoint smart contract on each chain. From there, LayerZero protocol has an append-only registry for libraries, which allows OApps to configure a relayer/oracle pairing, along with other security parameters, while the Ultra Light Node (ULN) acts as an on-chain validation contract within the Message Library (MsgLib). Each message sent through LayerZero protocol is nonce-order enforced. Messages are confirmed by an oracle and a relayer, who are assumed to be independent, and executed via a relayer.

Within this architecture, LayerZero protocol simply acts as a conduit for teams like the Lido DAO to build applications, choose a security setup, and then begin transmitting messages.

The emphasis here is that the LayerZero protocol does not seek to solve the unique and opinionated problem of validation methodology. Rather, LayerZero’s open and permissionless validation layer (aka the Oracle entity) is designed to support any set of methodologies. In fact, the validation methodologies of third party bridges such as Axelar, Wormhole, and CCIP could be leveraged directly within the LayerZero protocol.

The wstETH contracts enable contract owners to configure security parameters of x/n validators as an Oracle, thereby creating a meta-Oracle of sorts. Therefore, the Lido DAO can require multiple validation methodologies to sign off on each message going between chains. Within LayerZero’s current setup, this means requiring signatures from some combination of entities among Oracles (validation methodologies) like Chainlink DON, Polyhedra’s zkLightClient, Google Cloud Oracle and future validators like optimistic oracles and zkOracles. Other validation techniques – like third party bridges – can also be used in the Oracle as well.

In light of this proposal, LayerZero Labs recommends that the Lido DAO configure its Oracle to require two entities – Polyhedra’s zkLightClient and a bridge of its own choice.

However, if Lido DAO wanted to, it could go so far as to point to multiple 3rd party bridges as validation mechanisms, thereby essentially achieving messaging aggregation inside the LayerZero protocol framework. This would allow the Lido DAO to leverage the (1) middle-chain security model of one protocol, (2) the guardian validator set of another, and (3) full Ethereum consensus via a zkLightClient, all while preventing a centralized dependency on the liveness of one of the aggregated protocols for the integrity of the token transfer.

Furthermore, if the Lido DAO wished to include a (4) delegated service provider (e.g. P2P, Nethermind, etc) the DAO could vote to extend the x/n to include it at any time. This further backstops the Lido DAO from malicious behaviour arising from corrupted validation mechanisms. A quick showcase of this configuration is shown below:

1582×878 181 KB

To summarize briefly, the validation layer within the LayerZero framework empowers contract owners (e.g. Lido DAO) to expand and define their level of decentralization without writing any additional code. The above configuration example would result in wstETH which uses the full security of two independent bridges, zero-knowledge proofs, and a backstop of a community-run validator.

Transaction Lifecycle

User transfers wstETH from Ethereum to BNB:

  1. User pays for gas upfront in ETH.
  2. The user interacts with the wstETH proxyOFT contract on Ethereum, which sends a message to the wstETH contract on BNB.
  3. The user’s native stETH tokens lock in the wstETH ProxyOFT contract on Ethereum owned by the Lido DAO.
  4. The message is sent to the Endpoint and is passed to the contract-configured ULN, which emits an event containing the message.
  5. Upon the emission of the event containing the message, the Lido DAO validators and Relayer (both entities listening for the event) will trigger the fetching of the corresponding block hash and transaction proof respectively.
  6. After the block confirmations specified within the wstETH contracts have passed, the selected validators will deliver the block header to the destination chain’s contract-configured ULN.
  7. After the block header is submitted by the selected validators, the ULN will emit a notification stating it received the block header.
  8. The contract-selected Relayer will be listening for the event and upon seeing it will submit the corresponding transaction proof.
  9. Upon receiving the transaction proof from the Relayer, the ULN verifies that the transaction proof matches the block hash provided by the validators.
  10. If they match, the message is delivered to the LayerZero Endpoint. From there, the Endpoint tells the wstETH contract on BNB Chain to mint and deliver wstETH to the end user.
  11. If they do not match, the message will be deemed invalid and the transaction will revert; only one single honest party is needed for a malicious message to revert.

User transfers wstETH from BNB to Ethereum:

Same as the above steps, except users pay upfront in the native gas token of the source chain and the wstETH token is burned on BNB and the locked stETH tokens are released on Ethereum.

Why is this implementation best suited for the Lido DAO’s needs?

  • LayerZero remains the only interoperability protocol at-scale (85M+ messages delivered) to never experience an exploit.

    • LayerZero has secured $30B+ in lifetime volume.
    • LayerZero has consistently operated with the principle that security is the highest priority. Last year, we launched crypto’s largest bug bounty - a $15 million bounty in collaboration with ImmuneFi - and commissioned $3m+ of security audits.

  • All applications utilizing the LayerZero protocol have the option to be protected by Pre-Crime. Pre-Crime is a proprietary security module that simulates incoming transactions against an application-defined rule set, ensuring that invariants are checked before the delivery of each message. LayerZero Labs created Pre-Crime in response to the common security failures of major cross-chain protocols.

    • Using Pre-Crime, the Lido DAO can customize the specific set of checks to run prior to message transmission. If any rules within the set fail, the transaction will be blocked at the source. This adds a layer of additional security – a live risk management and monitoring system – without introducing any additional latency.

1456×780 48.3 KB

Conclusion

While we applaud the thoughtful discourse, we believe that this proposed implementation is the best solution for wstETH. LayerZero protocol is built to be a transport layer and is inherently validation mechanism agnostic, which seems to be a trait much prioritized by the industry writ large. With this bridged token implementation and the architecture of the Endpoint, the Lido DAO will have complete control over wstETH and governance without being locked in to a single validation type.

To speak briefly on the Axelar and Wormhole proposal, LayerZero would like to emphasize that moving wstETH across chains under the Wormhole-Axlear architecture relies on powerful BridgeManager contracts written just for this purpose. Rather than using newly written, unaudited (or briefly audited) BridgeManager contracts – which effectively function as Endpoints– the LayerZero proposal puts forth an implementation which uses Endpoints that have secured $30B+ value over nearly 2 years across LayerZero protocol.

Additionally, with LayerZero, contract owners (e.g. Lido DAO) can swap or change the x/n configuration at any time with light engineering lift. In other words, the DAO maintains the flexibility to remove validation methodologies such as bridge providers, in addition to adding them per governance vote. This comes in stark contrast to the Wormhole-Axelar proposal, which effectively locks the Lido DAO into a 2/2 multi-sig between the bridges. If either bridge experiences liveness issues or is hacked, this could cause major disruptions for wstETH. Finally, the implementation proposed by Wormhole-Axelar uses code has never been live and in-production.

Regarding the Multi Message Aggregation (MMA) implementation, we recognize this exciting collaborative effort by Li.Fi, Kydo, Celer to be a thoughtful response to governance-specific use cases. MMA prioritizes governance, which limits user experience and functionality. Adding more features may require new audits, potentially weakening the original design and introducing additional risk to Lido.

Commitment to BNB Chain

LayerZero Labs believes commitment to BNB Chain is important to mention in this conversation – as any Endpoint must be maintained long-term, updated to match anything that occurs on BNB Chain, etc.

With that in mind, LayerZero protocol has been live on BNB Chain since mainnet launch in April 2022. While BNB Chain does not have a native bridge, LayerZero is proud to be the interoperability provider for the top 3 native protocols: Radiant, PancakeSwap, and Venus. Additionally, LayerZero protocol supports dApps like Stargate Finance, the most adopted bridge for users on BNB Chain (DefiLlama).

Timeline:

  • As of December 5, 3+ audits have been completed for the underlying token contracts.
  • January → Commission additional audits of the wstETH bridged token implementation after recommended configurations are made
    • We intend to work with MixBytes and ChainSecurity on these audits
  • February → Pending DAO vote and NEW preferences, transfer contract ownership to the DAO

Appendix

1 Like
2

LayerZero V2 Update

Since this discussion was opened, LayerZero V2 was announced.

In brief, V2 shifts the message verification model from application-selected Oracles and Relayers to modular Security Stacks and the message execution model from Relayers to permissionless Executors.

  • Modular Security Stacks: Any entity capable of verifying cross-chain messages may permissionlessly participate in LayerZero as a Decentralized Verifier Network (DVN), including native bridges, third-party bridges, oracles, etc. Applications building on LayerZero may select a combination of DVNs to attest to the validity of a cross-chain message before it is executed on the destination chain. An application’s selection of DVNs is called its Security Stack.

  • Permissionless Executors: The Executor is a permissionless role that ensures the smooth execution of a message on the destination chain by handling gas for the end-user. Applications can choose a specific Executor, build and run their own executor, or operate without an Executor (end-users can manually invoke lzReceive on LayerZero Scan); V2 eliminates any issue of liveness dependency.

Additionally, V2 introduces improved handling, message throughput, programmability, and other contract-specific improvements. As mentioned in the original announcment, V2 will be live in late January. Below is a diagram of V2.

1600×870 160 KB

As with V1, LayerZero protocol remains the only immutable, permissionless, and censorship resistant messaging protocol. The design principles that inform the architecture of V2 are these exact ideals. LayerZero is un-opinionated about monolithic validation methodologies and can accommodate third-party and middle chain style bridges (i.e. Wormhole, Axelar, CCIP) should a developer choose to include them in their Security Stack.

More information on V2 can be found here: Medium Post, Whitepaper, Documentation, and Launch Video.

Recommended Security Stack for wstETH:

V2 introduces the ability for developers to set an x / y / n threshold for their Security Stack, empowering applications to combine DVNs however they like. For instance, a “1 of 3 of 5” combination of DVNs would include one required DVN and two arbitrary DVNs out of a total of five that must verify a message for cross-chain execution.

There are currently 14+ client-diverse Decentralized Verifier Network (DVN) options for LayerZero V2; third-party bridges, native bridges, oracles, and zkLightClients are supported as DVN options for LayerZero. This diverse group of verification methods allows Lido to take a future-proofed security posture, essential for maintaining the integrity and reliability of cross-chain wstETH transactions in perpetuity.

We recommend the following Security Stack configuration for wstETH based on its specific use case and security needs:

1. Polyhedra zkLightClient (achieves full Ethereum consensus)
2. Nethermind DVN

Should governance vote to include one or multiple monolithic security, third party bridge for additional verification, +

3a) Third-party bridge per DAO preference (i.e. Axelar, CCIP, Wormhole)

*3b) Alternatively StableLab or P2P DVN

Additional Security Measures

  • Rate Limits: Additional security measures are ready out-of-the-box for LayerZero integrations. For example, rate limits can be implemented per pathway and adjusted with minimal engineering overhead per governance vote. $QI, the governance token of QiDao, and Angle’s $agEUR are prime examples of rate limit implementations using OFT.
  • Pre-Crime: Pre-Crime is a proprietary security module that tests message validity against a set of defined rules or “invariants” by the application owner. Pre-Crime prevents hacks before they happen and has been live since Q2 2022.
  • =nil; zkOracle: In the near future, the =nil; Foundation will offer a zkOracle as a DVN that leverages their zk Proof Marketplace. We recommend exploration of this new technology for all V2-based applications.

Implementation Overview

Should the Lido DAO approve this proposed implementation, Lido achieves the following for wstETH:

  • DAO Control: Lido always maintains full ownership of wstETH contracts.
  • Modular Security: Leverages zero-knowledge proofs, native bridges, and decentralized verification methodologies. See above for recommended configuration.
  • Unified Liquidity: Unified wstETH supply across all networks without dependency on external liquidity.
  • Unified Semantics: OFTs are universal, meaning that wstETH may extend to new networks that LayerZero supports without any contract upgrades and limited engineering overhead. LayerZero currently supports 50+ chains.
  • Battle-tested Code: OFT implementation has been adopted by more 75+ DeFi protocols. Notable integrations include $CAKE, $MIM, $agEUR, $JOE, $BTC.b, and $STG.
  • Control Over Fee Structure: Zero additional fees for OFT transfers, with an option for Lido to implement its own fee structure.

LayerZero is intentionally designed to be an immutable protocol that has no ability to custody assets or alter the security settings or chain support of integrated contracts. The protocol can never take custody of wstETH, make security decisions that would alter how wstETH transfers are verified, or disable support for a chain that wstETH is enabled on. The non-custodial nature ensures that wstETH remains under Lido’s control, eliminating counterparty risks that are prevalent in other cross-chain solutions.

Technical documentation for OFT can be found here.

Conclusion

The implementation of wstETH on BNB Chain via LayerZero V2 represents a significant step forward in unifying Lido’s cross-chain expansion strategy. The enhanced security, efficiency, and flexibility offered by V2 strongly aligns with Lido’s goals of simplifying user experience, increasing DeFi composability, and maintaining robust security standards. LayerZero Labs is committed to supporting the Lido DAO in this endeavor, ensuring the successful deployment and long-term success of wstETH on BNB Chain.

4

Hi everyone,

We just wanted to provide an update with our change of vote regarding this TEMP CHECK. Firstly, It’s great to see so many strong players provide bridging solutions for wstETH to BNB.

Initially (pre-L0 V2 update), Wormhole x Axelar’s implementation provides a compelling offer due to two sets of different validators, and in general, it was good to see this type of collaboration between bridge providers. However, there are key points that add concerns like: Vendor lock-in (what if gas costs or the message delivery speed eventually make it difficult to use the bridge?) and newly built code specifically for this case (how long will it take other bridges to launch their endpoints that specifically fit this BridgeManager?).

With LayerZero’s updated proposal we have reconsidered our vote given the attractiveness of their V2 update - the opportunity to choose across various DLNs (incl. Axelar, CCIP, or Wormhole), reduced and more flexible gas costs depending on chosen DVNs, no security incidents for v1 and existing audits for v2. In each case, we believe this provides a better UX for the DAO and users of the bridge.

1 Like
5

Thank you Wintermute team for sharing your thoughts, it’s great to see the community uniting to support Lido DAO.

For everyone’s visibility, the key considerations have been addressed in the Wormhole x Axelar post from last night: Wormhole x Axelar | Lido Bridge: Implementation for wstETH on BNB Chain - #24 by Wormhole-Axelar

Happy to answer any further questions.