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