Wormhole x Axelar | Lido Bridge: Implementation for wstETH on BNB Chain

Proposals
1

Introduction

In response to the Lido community’s call for a secure and transparent expansion of wstETH to the BNB chain, Axelar Inc. and Wormhole present a unified proposal that leverages the expertise and technology of Wormhole, Axelar network, and the Lido DAO. This proposal aims to establish a multi-bridge deployment that adheres to Lido’s governance processes, ensures the DAO’s ownership and control, provides vendor flexibility, and addresses network-specific considerations. This proposal is based on a collaborative effort that aligns with the Lido community’s values of decentralization, transparency, and openness.

We’d like to express our thanks to the Lido Network Expansion Workgroup (NEW) for their feedback as we’ve put together this design. Should it receive positive community feedback and DAO approval, Axelar Inc. and the Wormhole Network will jointly deploy the Lido wstETH bridge to BNB Chain.

Problem Background

To bridge wstETH to a new ecosystem, the solution should encompass:

  • Robust Security: Similar to blockchain consensus protocols, cross-chain systems need to prioritize safety and operational continuity.
  • Liveness: It must support transaction completion within a reasonable timeframe.
  • Decentralization: Decentralization is critical for ensuring both safety and liveness.
  • Unified wstETH Representation: A single, Lido DAO-authorized representation of wstETH should exist across the BNB chain and be recognized by all dApps in that ecosystem.
  • Governance by Lido DAO: The governance of new wstETH contracts should be fully controlled by Lido DAO’s Aragon governance contracts on the Ethereum mainnet. This includes the ability to modify messaging network providers to maintain top-tier security standards.

Technical Overview

We propose a multi-bridge approach that combines Wormhole and Axelar network messaging in a standardized way, and provides the Lido DAO flexibility to add more messaging providers in the future.

Below is a high-level diagram of the entire flow:

Wormhole-Axelar
Wormhole-Axelar617×525 11 KB

The main components are:

  • BridgeManager - responsible for locking and minting wstETH, governance, and sending/receiving multi-bridge messages via the Endpoint components
  • Endpoint - responsible for sending and receiving cross-chain messages from a single provider
  • wstETH on BNB - newly deployed ERC20Burnable (or similar) representing wstETH on BNB

When a user transfers wstETH from Ethereum to BNB, the following steps occur:

  1. The user interacts with the BridgeManager contract. This contract locks the user’s wstETH and sends messages to mint wstETH on BNB via each Endpoint contract. In this design, Axelar and Wormhole each implement an Endpoint contract and the Lido DAO can choose to modify or add additional messaging providers.
  2. Each messaging provider will perform its own verification of the message from Ethereum and relay attestations to the corresponding Endpoint contract on BNB. At a high level:
    • Wormhole’s validators (Guardians) identify messages emitted from Ethereum, wait for finality, and produce a signed attestation once a super-majority come to consensus. A Wormhole relayer then delivers this message to the Wormhole Endpoint on BNB.
    • Axelar network is a decentralized Proof-of-Stake based network that leverages a distributed consensus to verify and route messages across chains. Once the message is posted on the source chain, the validators verify it, route it, and a relayer transmits a transaction to the destination chain approving the cross-chain message.
  3. Endpoint contracts on BNB Chain receive and verify their respective messages and then the BridgeManager aggregates these messages and verifies that the appropriate 2-of-2 threshold is met. If all checks pass, the BridgeManager mints wstETH and delivers it to the intended recipient.

When a user transfers wstETH from BNB to Ethereum, similar steps occur with the following exceptions:

  • The BridgeManager on BNB will burn the user’s wstETH, instead of locking. This is because BNB wstETH will be a newly deployed ERC20Burnable (or similar) that can be burned.
  • The BridgeManager on Ethereum will unlock and send wstETH to the recipient, instead of minting. This is because wstETH on Ethereum cannot be minted outside of Lido’s wrapping flow.

This design is flexible and the Lido DAO can choose to add more Endpoint providers or update the multi-bridge threshold, e.g. from 2-of-2 to 2-of-3 or 3-of-3.

Cross-Chain Governance

The Lido DAO can perform cross-chain governance via this multi-bridge design. Other BridgeManagerMessage.type values can be used to communicate governance messages. Lido contributors have full flexibility in determining what kind of governance messages to support and how the payloads for those messages should be defined.

Initial Contract Ownership

Wormhole will deploy the BridgeManager, Endpoint, and wstETH contracts on the BNB network. Following the deployment, ownership of these contracts will be transferred to a multi-sig composed of contributors from the Axelar network decentralized governance module secured by the entire Axelar network, the Wormhole Foundation, and a represented elected by BNB chain officials. This multi-sig arrangement is intended as a temporary measure. Once cross-chain governance has been implemented, thoroughly tested, and audited, the multi-sig will be phased out in favor of the Aragon-based smart contracts controlled by the Lido DAO.

Governance and Ownership:

Lido DAO’s Aragon governance contracts will maintain full control over the wstETH contracts, with the ability to add or remove messaging providers as the technology advances.

Security and Operational Considerations:

Security is paramount, and this proposal joins the security measures of Wormhole and Axelar network together to protect Lido users. Axelar network implements multi-layered security starting with the decentralized protocol, followed by robust engineering, and application-level addons and the Wormhole network incorporates defense-in-depth measures like the Global Accountant and Governor. Both protocols have undergone extensive audits and maintain large public bug bounties to maintain high security and operational standards.

While a multi-bridge approach is subject to the combined uptime of all providers, Wormhole and the Axelar network are both designed with resilience in mind and have encountered no significant downtime in the past year.

Wormhole:

The Axelar network:

Funding and Support:

Axelar, inc. and Wormhole do not seek funding from Lido DAO for engineering expenses related to the multi-bridge implementation. Both bridge providers will independently bear the engineering and auditing costs for this public good.

Timeline and Next Steps:

Wormhole and Axelar Inc. have started implementing the multi-bridge messaging framework and estimate the following timelines:

  • 2023-12-08: Initial implementation code complete and ready for audits
  • 2023-12-22: Audits by internal security researchers complete and feedback addressed
  • 2024-01-12: Audits by external auditing firms complete and feedback addressed
  • 2024-01-15: Testing period starts with Wormhole deploying bridge to BNB
  • 2024-01-29: Axelar network is added to multi-bridge and threshold is updated to 2-of-2

The timeline includes a two-week test period on the BNB chain with Wormhole’s deployment, followed by Axelar network integration.

Call to Action:

In response to the Lido DAO’s RFP, we’d like to invite the community to examine this proposal, offer feedback, and engage in the upcoming governance vote. With your support, we can ensure that wstETH’s expansion to BNB is executed with the highest standards and community governance

About Axelar

Axelar network is the leading interoperability layer for Web3. The network enables blockchain as a new kind of development platform, integrating diverse networks into a seamless “Internet of blockchains.” Axelar is programmable and decentralized, secured by a proof-of-stake token, AXL. Application users access any digital asset or application, with one click. Developers work with a simple API and access an ecosystem of tools and service providers.

Axelar is funded by top-tier investors, including Binance, Coinbase, Dragonfly Capital, Galaxy and Polychain Capital. Major partnerships and integrations include Microsoft, Mastercard, JPM, dYdX and Uniswap. Axelar’s team includes experts in distributed systems/cryptography and MIT/Google/Consensys alumni; the co-founders, Sergey Gorbunov and Georgios Vlachos, were founding team members at Algorand.

About Wormhole

Wormhole is the longest-running generic cross-chain messaging protocol, with the first production message sent in August 2021. Hundreds of projects have leveraged Wormhole to transfer over 35 billion USD of value and over 750 million messages across more than 30 chains. These messages enable sending price oracle data, transferring tokens between chains, building cross-chain DeFi protocols, cross-chain governance, and many other use cases.

Additionally, Wormhole was named the only unconditionally approved protocol by the Uniswap Foundation’s Bridge Assessment Committee — Bridge Assessment Report.

13 Likes
2

First and foremost, I want to say thank you for putting together this proposal. It’s great to witness the collaborative efforts of two reputable bridging providers in the web3 space.

I must say, I like the multibridge approach outlined here. It directly tackles some of the most pressing challenges, such as avoiding vendor lock-in and the over-reliance on a single bridging provider for BNB network.

One aspect that is particularly important is the plan to transfer ownership to Lido DAO once the governance forwarder is ready for production—a crucial move. Given BNB’s status as one of the most established networks, I anticipate a substantial influx of wstETH bridging activity as soon as the chosen bridge becomes operational.

Regarding the threshold, my preference leans towards starting with a 2-of-2 setup. As more providers come into the fold, I think it would be good to gradually reduce the threshold (e.g., 2-of-3, 3-of-4). This approach not only alleviates high gas costs for users but also maintains a robust and reliable infrastructure.

Kudos once again for this well-thought-out proposal!

8 Likes
3

Hey-hey,

Thank you for participating in the RFP call for the wstETH on BNB. I admire seeing a joint response of two well-known, established teams.

As for me, this proposal is well-shaped and neatly crafted to continue discussion and further considerations.

I have some questions here about the proposed solution, sorry if some of them are not applicable:

  • Do you consider charging the bridging fees according to the native gas currency expectations and what are they?
  • Would it be possible to introduce an ability for emergency pauses on behalf of the established Emergency Breaks msigs together with the implementation of the DAO Governance forwarder?
  • Have you regarded previously shipped cross-chain governance architecture developments (e.g., AAVE’s a.DI) for the design presented?
  • Could you shed some light on the token standards the proposed representation would have implemented? (e.g.: ERC-2612/1271 or emerging anticipated ones like xERC-20)
  • Would it be possible to pass additional calldata items together with token bridging requests for future extensions/integrations and UX improvements?

Thank you once again for the very tempting opportunity!

7 Likes
4

Regarding the implementation of the DAO Governance forwarder, since BNB is not an L2 and there is no canonical bridge, it is crucial to have a solution like a.DI GitHub - bgd-labs/aave-delivery-infrastructure: Abstraction layer for cross-chain communication

3 Likes
5

Gm Lido Delegates,

First and foremost, we commend the efforts of Axelar and Wormhole for putting together this proposal that follows a more collaborative approach to the bridging of key assets like wstETH.

Our team at LI.FI, in collaboration with Celer, Kydo, and the Uniswap Bridge committee, has been working on an implementation of a Multi Message Aggregation (MMA).

We want to offer this solution as an alternative to the structure laid out in this proposal, as the capabilities of both solutions are quite similar and the code for MMA has already been audited by Trail of Bits.

MMA implementation: GitHub - MultiMessageAggregation/multibridge: Send Cross-Chain Messages through Multiple Bridges
Audit by Trail of Bits: https://github.com/MultiMessageAggregation/multibridge/blob/main/audits/2023-11-13-ToB.pdf

The MMA framework supports a quorum of 2/2 with Axelar and Wormhole integrated for BNB Chain, with the ability to add further bridges any time in the future.

The original MMA proposal was set out to mainly handle cross-chain governance and had timelocks. However, we’ve added the functionality to handle token transfers as well, combining it with the xERC20 standard.

The combination of MMA and xERC20 allows for rate limits on each individual configuration with daily mint and burn limits. This setup allows for each bridge to mint a limited number of tokens without needing a 2/2 quorum as it saves gas while using the 2/2 quorum for unlimited minting and burning rights.

We envision the xERC20 configuration with MMA to be like this:

  1. Axelar: daily mint/burn limit of $2m
  2. Wormhole: daily mint/burn limit of $2m
  3. MMA: unlimited mint/burn limit

This configuration is designed to be cost-effective for retail users through individual bridges, while the MMA enables arbitrageurs to handle larger volumes for arbitrage purposes.

The code for this implementation is fully open source and can be reviewed here: https://github.com/lifinance/MMAxERC20

This schematic shows that the structural flow of both proposals is almost identical:

unnamed
unnamed1600×881 94.4 KB

We’re happy to engage in constructive discussions with all stakeholders involved in this proposal.

Our goal is to collaboratively find the most secure and efficient path forward for Lido DAO’s cross-chain expansion.

Thank you for considering our proposal.

3 Likes
6

Hey, @Arjun_Chand

Thank you for the prominent suggestion; I see the benefits for bridge users (having flexibility with gas costs) and stakeholders (using the existing audited codebase based on emerging bridging architecture standards).

Please shed some light on the following numbers reasoning:

  • Axelar: daily mint/burn limit of $2m
  • Wormhole: daily mint/burn limit of $2m

Some risk management framework is needed to maintain those limits, so I want to depart from initial considerations and principles. Moreover, it may be worth using not USD nomination but wstETH itself, IDK, to exclude market conditions and turbulence from the equation.

1 Like
7

Thank you @DeFiYaco @TheDZhon and @ujenjt for your thoughtful comments on our proposal! Regarding some of the questions you all raised:

  • Governance & Ownership: Cross-chain governance will be achieved with the proposed design (see the “Cross-Chain Governance” section). We are planning to prioritize the transfer of contract ownership to the Lido DAO as soon as safely possible after deployment. We are aware of, and have been inspired by, other innovative cross-chain architectures such as a.DI.
  • Fees: This solution will not have any bridging fees at the base messaging layer. However, users can opt for their messages to be automatically relayed from ETH to BNB (or vice-versa) by paying up front on the source chain in native gas. Those relaying fees would vary based on the delivery providers that users select.
  • Token Standard: wstETH on BNB would be a standard ERC20Burnable token, which the BridgeManager contract is able to mint and burn. The token can also support standards such as ERC-2612/1271 if the Lido DAO determines that is important.
  • Additional Features: If deemed critical, additional features such as emergency pauses and passing additional calldata can be considered for the initial launch. Importantly, the bridge is upgradeable via governance and new features can be added by the Lido DAO.

Thank you as well @Arjun_Chand for your proposal. We are reviewing the design and will circle back with our comments.

2 Likes
9

Hey @TheDZhon

We came up with the number of $2m by looking at the wstETH locked inside Arbitrum which is 114k wstETH or $260m currently.
We agree with you that the limits should be in terms of wstETH. Heuristically, it would be 1000 wstETH.

The LIFI team would be happy to contribute to a risk framework for the daily limits. This should include:

  1. wstETH volume that is daily bridged to existing L2 chains
  2. TVL of wstETH on various L2s(comparable with BNB Chain)

To also go into @Wormhole-Axelar’s newest reply. Our proposal would make the additional features, like an emergency shutdown and the adding of additional call data possible as well. Especially the emergency shutdown would be an extension to the xERC20 standard though and need a renewed audit to accommodate the security considerations.

1 Like
10

Hi @ujenjt, Ernesto from BGD Labs, the team contributing to Aave who created and maintains a.DI.

For some extra visibility to the Lido community:

  • As you (and @TheDZhon) correctly point out, a.DI is a layer of cross-chain communication based on consensus, used by Aave at the moment in production, for its governance to control all Aave instances: Ethereum, Polygon, Avalanche, Optimism, Arbitrum, Metis, Base, and soon, BNB and other networks upcoming.

  • a.DI comes from a bit different direction than other solutions: as creators of a critical system like Aave (similar in scope to Lido I would say), we firmly believe that the governance should have full control over communication, as we experienced in the past being limited by underlying bridging infrastructure.
    Same as Aave, Lido on any network is not cross-chain Lido, it is Lido, and control over it should be Lido’s as much as possible.

  • To achieve this independence, first, a.DI is abstract to the underlying bridges used: it could use Axelar or Wormhole (which we are already evaluating for a.DI too), Chainlink CCIP, LayerZero, Hyperlane, “canonical bridges” (the 5 previous in usage on Aave), or any other. That means Aave (or Lido in this case) chooses them. Second, consensus is of course configurable, to “price” security vs the cost of bridging. Third, as @TheDZhon points out, it has an ad-hoc Emergency mechanism that allows for governance on Ethereum to signal an “emergency”, for other entities (e.g. a multisig) to take temporary control of the infrastructure in the other networks.

  • a.DI at the moment is highly oriented to critical governance decisions: only whitelisted entities can “bridge” messages (would be Lido governance contracts or any other), and by using multiple underlying bridges cost is higher, but perfectly reasonable given the low frequency.

  • Anybody not conflicting with Aave (so Lido is perfectly fine, being a close partner) can have its own a.DI instance (L.DI :grinning:), that can be adapted to the needs.

5 Likes
11

Hello everyone and the Lido community.

It’s exciting to see the Lido DAO wanting to reach and expand to the BNB ecosystem.

We highly welcome the collaboration of reputable projects and the proposal from Axelar and Wormhole, and would like to complement it to further enhance the security and flexibility for Lido.

We published a proposal recommending the xERC20 standard (an open, bridge agnostic way to manage token contracts on different chains so that token issuers retain the sovereignty of their assets while enabling capital efficient and slippage-free token transfers).

Under this perspective, we support Li. Fi’s initiative to implement this standard with a configuration that whitelists a Multi message aggregation.

2 Likes
12

@Arjun_Chand @Dominik_Hell thank you for sharing your MMAxERC20 proposal and thank you @eboadom for sharing more information on a.DI. Ultimately, we are open to working with whatever the Lido DAO decides. Nevertheless we’d like to share our thoughts on these alternative proposals —

MMA: The architecture is similar to ours and it’s exciting to see how you’ve integrated both Wormhole Automatic Relaying and Axelar Gas Services in your Endpoint contracts.

That said, one fallback of the implementation is that it does not robustly handle failure cases for relaying. Deferring relaying fully to the Endpoint contract — without on-chain checks and interfaces to retrieve price quotes — can quickly lead to relaying failures that would be complicated and confusing for users to resolve. Ensuring relaying is robust and built in a way that properly accommodates different relaying backend systems is a critical part of building a simple and intuitive UX for users to bridge wstETH.

We have carefully crafted this aspect of our design to handle relaying via interfaces that allow the BridgeManager to retrieve delivery quotes from Endpoint contracts that are checked against the user’s fees, so that we minimize delivery failures.

xERC20: We do not think there is any reason to use xERC20 as part of the design. Specifically:

  • Since the BridgeManager contract will already handle managing multiple messaging providers, making the token an xERC20 will unnecessarily complicate the implementation. We believe that the token contract should be a simple ERC20Burnable, which is as out-of-the-box as possible.
  • If the Lido DAO believes rate limiting should be added, it makes the most sense to implement this functionality in the BridgeManager contract, which is already managing multiple messaging providers. Rate limiting at the Token contract level would require unnecessary pass-through logic which is not optimal.
  • The MMAxERC20 design seems to involve using xERC20 on both Ethereum and BNB. However, if xERC20 is used on Ethereum mainnet, it will fragment wstETH liquidity into two tokens — existing wstETH and xERC20 wstETH — which complicates UX for users since they need to deal with 2 representations.

With respect to the proposal to let both Wormhole and Axelar mint individually up to $2m, we recommend against enabling such functionality in the wstETH contract, for the following reasons:

  • It complicates the contract design.
  • We believe the safety of funds is the top priority for wstETH and this approach increases risk. With this approach, funds can be lost if any single messaging protocol breaks, rather than both protocols.
  • The UX/cost benefits of allowing any single provider to mint can be replicated on the application layer, through projects like Squid and Magpie.

a.DI: This is, like MMA, another similar architecture. However, it currently does not integrate either Wormhole or Axelar messaging and it’s also unclear how a.DI cleanly handles relaying.

Please let us know if any of you have further questions on our design. We’re happy to share more in depth details on our technical spec.

1 Like
13

Hello everyone!

In response to the Lido DAO’s exploration of cross-chain solutions for wstETH on BNB Chain, we propose Hashi as a future-proof, inclusive approach that we believe can be a great fit for the wstETH cross-chain stack.

Hashi is a generalized block header and message aggregation framework. It was born at Gnosis to serve similar needs but has since been developed and maintained as a public good by the Cross-chain Alliance, a team that is not affiliated with any bridge and focuses on credible neutrality in the cross-chain space.

We believe that providing a secure, reliable cross-chain communication layer is the most crucial part that needs to be addressed first. Cross-chain tokens, regardless of the standard used, could create systemic risks if based on a foundation that is not sufficiently secure.

Hashi provides a secure, reliable cross-chain communication layer that can be plugged into any cross-chain token standard.

Hashi - General Message Scenario
Hashi - General Message Scenario1920×1080 135 KB

Advantages of Hashi

  1. No Vendor Lock-in: Hashi’s architecture abstracts out the underlying bridge providers, offering a robust and future-proof integration with the preferred set of bridges.

  2. Extensive Bridge Integrations and Future-proofness: Hashi already supports 15+ bridges and ZK light clients including all the ones that have made proposals in the forum so far. This inclusiveness ensures maximum interoperability and proves future compatibility with promising approaches like the ZK light clients one - which also resonates with the light clients based approach of IBC.
    Bridges integrated so far include: Axelar, Wormhole, Chainlink CCIP, LayerZero, Hyperlane, Celer, Sygma, Telepathy ZK light client, DendrETH light client, Electron Labs ZK light client.

  3. Asset Wrapping Standard Agnosticism: Any cross-chain token standard, including xERC20, OFT, and Warp Routes, can be easily plugged in on top of Hashi. This flexibility ensures Lido DAO’s freedom to choose their preferred option while retaining the same security guarantees. Initial efforts done by Safe Junction · GitHub show how such an integration could look like, however our recommendation is to focus on the preferred security foundation first.

  4. Permissionless Framework: Developed as a public good, Hashi is already operational across multiple networks. Its extensibility, both on the bridge and the governance side, is completely permissionless and in the hands of its users.

  5. Configurable Governance: The selection of the underlying bridges and the configuration of the thresholds are under the control of pluggable governance modules. Hashi provides some reference governance implementations, however we are happy to support Lido to design its own governance module if needed.

Hashi has already been audited a few months ago by the G0 Group, and more audits are in the works.

More details on Hashi can be found here: Introduction - Hashi-documentation.

Conclusion

In summary, Hashi is designed to provide a robust, flexible, inclusive and future-proof security solution that we believe to be better aligned with the Lido DAO’s cross-chain wstETH needs.

Dedicating more efforts now to choose a security-first architecture for wstETH will undoubtedly pay back in the future.

We are excited about the potential of collaborating with the Lido community. We are also happy to join efforts with the other proponents to leverage the strengths of each solution and come up with the best possible cross-chain version of wstETH.

Thank you for considering our proposal,

the Cross-chain Alliance

2 Likes
14

I’m excited to see collaborative efforts between two established and reputable bridges. I cannot highlight the importance of security in cross-chain bridges; Wombat, a project using Wormhole as a generic messaging layer, has always trusted Wormhole tech for its security and world-class team backing and continuous improvement of the project. Axelar, comprised of many of my alumni from the University of Waterloo, has an exceptional group of software engineers pushing the boundaries of cross-chain technology. Having these joint security measures of Wormhole and Axelar is not just a first in the industry but also offers a high level of security for Lido users bridging to and from BNB Chain.

The idea and the execution to bring one of the most essential assets in crypto to a chain where there is a vast user base is a no-brainer. However, how you enable it and execute it is another question that I believe the Wormhole and Axelar team nailed, and using a burning model makes a lot more sense if you want to bring an asset cross-chain since wsETH on mainnet cannot be minted outside of Lido’s flow.

As a builder, Wombat has had a great experience working with the Wormhole team, which is professional, responsive, and, most importantly, efficient. As a supporter of Wormhole, it is no secret that I value the contributions and support that the team has partnered with Wombat, but also in supporting a vast array of projects across the crypto ecosystem. Building a cross-chain messaging system that can stand the test of time is not easy. I’m glad they are working on a solution to one of the biggest problems that needs to be solved in crypto- to safety and quick bridge access. Hence, the world is no longer chain-agnostic and joined together as crypto-lovers instead of segregated silos.

I am looking forward to this landmark launch for Lido users and equally excited for builders of Axelar and Wormhole, continuing to create, expand, and grow DeFi – in my opinion, the most crucial lego in crypto to bring crypto to the masses.

15

Dear crypto community,

We agree to the proposed steps concerning cross-chain governance, initial contract ownership, governance and ownership structure, security measures, and funding allocation. This collaborative venture, aiming for a secure and transparent expansion, signifies a crucial step forward for both our entities and the larger crypto community.

Upon thorough review and consideration, Axelar Inc. and Wormhole align themselves with the principles outlined in the proposal, including the adherence to Lido’s governance processes, commitment to transparency, and the establishment of a multi-bridge deployment. The collaborative effort presented, leveraging the expertise and technologies of Axelar Network, Wormhole, and the Lido DAO, mirrors our shared values of decentralization and openness.

Furthermore, Axelar Inc. and Wormhole commit to bearing the engineering and auditing costs associated with this project, demonstrating our dedication to contributing to this public good without seeking funding from the Lido DAO.

17

Hello everyone, thank you for the engaging discussion.
I’m Max from Connext, and I’d like to expand on the trade-offs of the xERC20 standard for future-proofing wstEth, on BNB and beyond.

Note: the goal here is not to push for a specific bridge solution (the xERC20 is designed as bridge agnostic), but to ensure a collaborative approach in this conversation to grow Lido on all ecosystems.

MMA and xERC20 are different solutions to different (but complementary) problems. They are mutually compatible as pointed out by the LiFi team.

960×540 31.1 KB

xERC20 on a single chain gives flexibility for Lido to rate limit the risk of this MMA system, and leaves the door open to experimentation for other MMA systems under development (e.g. Hashi, Hyperlane, LZ, etc.). For example, common MMA frameworks like Hashi already support xERC20.

The xERC20 standard is a simple extension of the ERC20 token standard. It is an out-of-the-box public good solution that is already built, has undergone thorough audits, and has proven its reliability in practical applications.

It is fully compatible with ERC20Burnable tokens, as all that is needed is to wrap wstETH in the lockbox on Ethereum. Here’s a specification for what is involved in supporting: xERC20 (ERC-7281) Bridge Support Specification - HackMD

The true power of xERC20 is however unlocked when xERC20-wstETH is available on multiple chains. By locking L1 tokens into a shared lockbox across all bridges/chains, Lido avoids fragmenting their liquidity across multiple custom MMA solutions or bridges on each chain.

This means that, for example, if Axelar-Wormhole MMA is used for the Ethereum-BNB chain pathway, and Hashi MMA is used for the Ethereum-Gnosis pathway, wstETH bridging from BNB-Gnosis could still be supported by allowlisted bridges without needing additional wstETH liquidity (and, importantly, without needing to bounce through Ethereum).

This is critical for projects like Squid and Magpie (as well as other intent-based bridges: Across, Connext, DLN, …). The costs of these systems are driven by the settlement costs of the underlying token message transport. A fragmented ecosystem where all settlement needs to happen via Ethereum (via different providers and using different token implementations) means worse pricing for wstETH as intent solvers now need to incur L1 gas, integration complexity, and significantly higher liquidity lockups to rebalance funds.

The overhead and complexity of supporting xERC20 in this case is extremely marginal. The Axelar-WH MMA system simply needs to wrap L1 wstETH in a lockbox so that no funds actually remain locked on their contracts.

Realistically, this reduces the risk surface area for wstETH as the class of attack vectors on the Axelar-WH MMA contract now excludes exploits that drain the locked funds on Ethereum.

Yes, an xERC20 version of wstETH will indeed exist on Ethereum, but the xERC20 representation on Ethereum is created (via the lockbox wrap transaction) and burned (by the bridge) in the same transaction, making it completely invisible to the user.

A user will simply be using any of the bridges that are whitelisted (and the apps built on top) and move wstETH from Ethereum to BNB in a seamless way.

The long-term benefits of xERC20 are significant for the Lido DAO.
We should view this not just as an isolated issue but as a recurring challenge.
The question is: How can we scale stETH across thousands of rollups and L1s, without fragmenting liquidity, and focusing on native bridges without being limited to new L1s?

1 Like
18

Hello everyone!

We at Magpie Protocol have been a part of the BNB community since our first launch of our dApp back in our closed alpha in 2022 and are excited to see a proposal for wstETH to come to the network as a member of the BNB chain community. Magpie supports this proposal, and believe that it outlines a robust strategy for enhancing the efficiency of wstETH transfers between Ethereum and BNB through a collaborative effort between Wormhole and the Axelar network. The in-depth breakdown of key components such as BridgeManager and Endpoint offers a transparent view of the technical aspects, but what really stands out is the flexibility granted to the Lido DAO to fine-tune and expand the network, complemented by the incorporation of cross-chain governance, which is a pivotal feature for seamless management. The consideration of contract ownership and the phased transition to Aragon-based smart contracts reflects a thoughtful governance approach and security takes center stage, with both Wormhole and Axelar showcasing robust security measures, audits, and bug bounty programs. This proposal instills confidence in its reliability and safety, underscoring the dedication and thorough work invested by both teams.

Magpie Protocol has seamlessly integrated with Wormhole, leveraging their generic message protocol for disseminating messages across supported chains, to make cross-chain swaps secure and efficient. Prior to our integration, we extensively explored various cross-chain communication protocols currently in use and chose Wormhole for several compelling reasons:

  1. Cost-Effective Message Publishing: CoreBridge eliminates costs when compared to fee-based solutions.
  2. Flexible Data Transmission: Send any data size as byte-type payloads.
  3. Supportive Team: The integration process was smooth, with continuous and excellent technical assistance from Wormhole’s team.
  4. Proven & Decentralized: Wormhole’s battle-tested protocol, supported by 19 Guardian nodes, ensures reliability and decentralization.
  5. Chain Agnostic: Wormhole extends beyond EVM chains, including Solana, making it a versatile and inclusive choice for cross-chain communication.

The Magpie Protocol has nothing but positive things to say about the Wormhole team and their dedication to the DeFi space in order to make it as best it can be. We post this to reflect the rationale behind our choice of Wormhole and to showcase the successful integration experience of Magpie Protocol, emphasizing the protocol’s efficiency, flexibility, and the reliability of its supporting team. We fully believe that support in favor of this proposal would be of great benefit to the overall ecosystem!

1 Like
19

At Magpie we support the collaboration between Wormhole and Axelar, marking an industry-first initiative in bridging technologies focused on expanding wstETH onto the BNB chain. This collaboration not only showcases a commitment to innovation in the blockchain space but also strengthens our longstanding relationship with Wormhole.

20

Thank you, Axelar and Wormhole teams, for sharing this proposal and explaining in detail how it will work from the technical side.

It’s vital to keep up with the market trends as we recently witnessed the interest in demand for wstETH extension to more chains. So, the time has come to implement a solution that will meet all the requirements and cover the pain points.

It is also great to see that teams are ready to bear the engineering and auditing costs independently.

There are several strong teams and proposals, so the competition is high, but it shows the leaders of the markets and their commitment to building and facilitating public goods.

On behalf of Everstake, we are delighted to work with both teams as they have significant expertise and a solid list of achievements. In our opinion, this proposal should be considered as a tool to deploy wstETH to the BNB Chain.

Let’s see what the vote says.

5 Likes
21

I’ve been watching the development of this proposal since the holidays, and I (as an outside observer, so all I bring are words, rather than votes) think this is the most compelling of the options presented to Lido governance. GFX Labs has had the pleasure to work extensively in the cross-chain governance and space, and is familiar to both Wormhole and Axelar from our contributions at Uniswap, where a similar debate occurred last year.

Significantly, this pair of providers are the only two that the exhaustive Uniswap Foundation Bridge Report recommended. Combining them to provide an implementation isolated from the small individual risks of either bridge makes for an even more compelling offer.

Some of the other offers are strong, and I don’t want to diminish them, but getting both Axelar and Wormhole – who can act as an additional security check on each other – for a cost-free implementation and maintenance would be approved faster than you can say Jack Robinson at most DAOs.

3 Likes
22

With voting starting today, we at Axelar and Wormhole are very excited for our proposal to be considered by the Lido DAO. We’d like to share a brief update on the progress of our technical implementation.

Our teams have been hard at work building the multi-bridge token transfer design that we originally proposed. Behind the scenes, we’ve done a tremendous amount of work adding critical features, improving security, and optimizing gas consumption in the smart contracts.

The code is entirely open source and can be viewed in these two repositories —

  1. wstETH-specific implementation, with Axelar and Wormhole Endpoint contracts and a sample wstETHL2Token contract — wormhole-foundation/example-wormhole-axelar-wsteth (github.com)
  2. Implementation of the multi-bridge framework, which includes the EndpointManager contract — wormhole-foundation/example-native-token-transfers (github.com)

Please note that the code is still a work in progress and that it isn’t expected to be bug free yet. We are aiming for the implementation to be fully complete and audited, both by our internal security teams and external firms, by mid-Q2.

Some aspects of the implementation that we’d like to highlight:

  • The Endpoint contracts will be upgradeable via the EndpointManager contract. The EndpointManager is OwnableUpgradeable and the wstETHL2Token contract is Ownable. The OwnableUpgradeable and Ownable functionality should just be viewed as placeholders for now — we plan to work with the Lido DAO to ensure that the contracts properly integrate with the DAO’s preferred governance process.
  • We have added on-chain inbound and outbound rate-limiting as part of the EndpointManager contract. The outbound rate-limit is a single global limit for sending from a chain, while the inbound rate-limits are per-chain limits for receiving from specific chains.
  • We have implemented defense-in-depth security protections such as replay protection, invariant checking, and deterministic storage slots. Replay protection is implemented both by Endpoint contracts (Wormhole & Axelar message replay protection) and the EndpointManager contract (overall message replay protection). We guard against tricky edge cases by checking invariants (see here and here) around configured Endpoint contracts and the threshold attestations for messages to be considered valid. Since the contracts are designed to support upgradeability, we also use deterministic storage slots to protect against error cases if the DAO wishes to upgrade the contracts to newer versions in the future.
  • We use data structures that optimize gas consumption for Endpoint management, replay protection, and encoding/decoding structs.
  • The bridge can be easily integrated into any frontend UI, such as Wormhole Connect and Squid. The design also leverages Wormhole Standard Relaying and Axelar Gas Services so that end users have a one-click seamless experience.

We are very excited about our implementation and the opportunity to support the Lido DAO’s efforts in bringing wstETH to BNB via our joint Wormhole-Axelar bridge. We are also happy to answer any questions contributors may have and dive deeper into the technical aspects of our solution.

We look forward to seeing the outcome of the vote!

3 Likes