Hey guys, just want to shout out Lido and LayerZero for bringing wstETH to the Avalanche community. Our users and protocols will greatly benefit from having access to ETH staking yield and I can’t wait to see it adopted within more protocols.
Hey, I think it’s nice that people get the opportunity to stake from other L1 but I’m strongly against using it for L2s like Scroll.
The point of L2s is that they have a secure L1 <> L2 bridge, if people start using mint/burn bridges then what is the what’s the point? And I get the point of unified liquidity but imo it’s not worth it.
And what if some people want to hold the “native” wstETH (from the rollup bridge), we are going to have two tokens, or even more as L0 competitors come to market?
This is a great initiative to drive adoption of LSTs on different chains and L2s.
There are already protocols on those L2s that want to provide more value to LSDfi, and have already started doing it, despite a robust way to bridge these tokens. e.g. Cog Finance just launched on Scroll, which support different LSTs in isolated lending and borrowing. It also uses my xF33d contract to send the exchange rate from other chains (in this case from Arbitrum → Scroll) via LayerZero to Scroll, as a safe alternative for non-chainlink evm network.
Given we have this, it would enable those protocols to grow, further growing LSDfi and give more usage to the LST itself.
It will also benefit a lot of cross chain swap and bridge protocols, as they could give their users a better rate now, when wstETH is bridged. So, more people would want to bridge it.
The cost of arbitrage would also decrease, as people could seamlessly move across various L2s with fraction of cost. No need to go via mainnet
It is a much needed for the Lido DAO to catch upto new age LSTs which already have it.
Thank you for posting this proposal.
As a member of network expansion workgroup (NEW) I am happy to see the community and projects supporting wstETH expansion to more networks.
Clearly, wstETH is already deployed on BNB, Avalanche and Scroll, but until Lido DAO formally accepts these denominations (by the signaling Snapshot vote), the community should not consider this proposal final.
The next batch of Snapshot proposals is going live tomorrow. Unfortunately, this proposal came on a way too short notice for the NEW to properly review and provide proper feedback.
Thus, I recommend to leave the discussion open on the forum to allow for all the relevant parties and interested members of the community to properly research, review and provide opinion.
I agree with @arixoneth’s opinion on Scroll deployment. My opinion is that as long as there is an open source bridge infrastructure that does not take any additional fees and serves as a public good, wstETH should be by default minted with the native bridge. Native bridge’s security is coupled with the L2s security, so signaling support for the specific L2 inherently signals the support for its native bridge. Using any other bridge provider without a strong case for it just adds more risk.
I will come back to this proposal with my thoughts around BNB and Avalanche.
Since this proposal is quite large in scope and importance and seems to be a bit contentious (especially around which networks the bridge and wstETH token-equivalent should be “accepted”, i.e. whether it should include certain L2s in lieu of a native/canonical bridge) I agree that that we should continue discussion for at least another week before a relevant snapshot goes to vote.
It’s truly invigorating to see community-driven initiatives fostering such rich dialogue.
I’m reaching out as a contributor to the Lido on Ethereum core protocol and a member of the network expansion workgroup (NEW), hoping to share some insights and perhaps broaden our discussion before moving towards a formal decision-making process.
The integration of wstETH across various ecosystems is a natural progression in Ethereum’s scaling journey. It’s quite common assumption that assets minted on L2 rollups typically align with the rollup’s security model. This is particularly significant, given the considerable efforts by foundations and DAOs to ensure a canonical representation of wstETH via native rollup bridges (as seen in the previously ratified proposals for Optimism, Abitrum, Polygon, and more recent, unapproved yet proposals for Base and zkSync).
While acknowledging that token bridging is inherently permissionless and open, there’s a concern that multiple token representations could fragment liquidity and degrade the user experience for token holders and rollup users. In this context, I lean towards supporting a native bridge solution specifically for Scroll.
A thorough security assessment of the proposed solution, including architecture analysis, impact evaluation on the core protocol, and a review of deployment artifacts and governance mechanisms, has been conducted or scheduled neither by Lido DAO contributors nor independent security experts on the particular request. Highlighting this is crucial, especially when considering the potential for an endorsement proposal.
The mentioned native L2 bridge solutions for wstETH employ a ‘lock-and-mint’ architecture, offer the advantage of not exposing the protocol’s Total Value Locked (TVL) and its associated staker risks beyond L1, unless users explicitly opt for it. Alternative approaches like ‘burn-and-mint’ could necessitate additional operational complexities, such as transfer rate limitations and caps and their precise uninterruptable management (a concern raised in the ERC-7281: Sovereign Bridged Tokens discussion).
The current proposal suggests the simultaneous endorsement of three networks. I have reservations about this approach and believe a more measured, pilot-based strategy might be more prudent, especially when considering each network’s unique attributes and needs.
With these considerations in mind, I propose the following:
- Extend the discussion period by at least another week before any snapshot is taken, possibly revising the scope. This might include not just omitting Scroll but perhaps concentrating the efforts on a single network, such as Avalanche, to begin with.
- Maybe it is worth initiating a separate, informal poll or discussion to gauge better the Lido DAO community’s sentiment towards favoring native bridges.
Hi all, I have some concerns with this proposal.
1. I’m confused: “wstETH is now an OFT” is being marketed like it’s official, but the LidoDAO hasn’t voted yet??
There appears to have been a coordinated marketing effort between Avalanche, BNB, and LayerZero with a series of twitter posts and slick videos implying that LidoDAO has already officially accepted the OFT standard. How is this possible when this is just a proposal?
Given the serious security concerns (discussed below), I think it’s dangerous to market this as a done deal without a proper discussion in these forums. The DAO shouldn’t feel pressured to support a proposal based on a marketing campaign.
2. The OFT standard is a “mint-and-burn” standard, which means there is some risk of an exploit leading to the unauthorized, and potentially unlimited minting of wstETH.
As the proposal states, token “balances are directly modified via messages transmitted from the source to the destination chain”. This means that if this messaging layer is ever corrupted, there is the possibility of an unlimited mint of wstETH. LayerZero appropriately allows Lido to select the bridging security method used, however with any method chosen there is still some risk. Given how critically important stETH is to Ethereum as a whole, I think this risk—however small—needs to be properly discussed within this community.
To spell out the absolutely worst-case scenario, imagine that the messaging layer for this OFT standard is corrupted and unlimited wstETH are minted. Confusion and concern about this exploit could easily cause heavy selling and withdrawals on Ethereum itself, leading stETH to depeg. This would be very bad and very scary. Before this standard is adopted by the DAO, I believe these concerns should be fully and properly debated.
3. There are other “mint-and-burn” standards that could be considered.
If LidoDAO does decide that the risks of a mint-and-burn bridge are worth the benefits, there are other alternatives to LayerZero’s OFT standard that may be worth exploring. Specifically there is a standard called xERC20 that may be worth considering. I am not an expert on the details of this standard, but I believe that it does allow for the use of the chain’s native messaging bridge when it exists (something that the OFT standard does not). For example, since Scroll has a canonical/trust-minimized messaging bridge between itself and Ethereum, the xERC20 standard would be able to use this trust-minimized bridge for mint-and-burn messages. This may address some of the concerns raised regarding Scroll security in other posts above.
Perhaps the DAO should issue an RFP requesting proposals to bring wstETH to Avalanche/BNB/Scroll and invite a proper debate on the pros and cons between various approaches before picking a solution?
Thank you for the proposal. Would note that in general timeframe of 7 days or more is considered a good window for the feedback (can look it up on “How Lido DAO governance works” page here: The Lido Decentralised Autonomic Organisation Governance). Given there’s quite a lot of feedback and questions raising already, it feels prudent to discuss the proposal even deeper / for longer time before looking to send it to the vote, let alone endorsing it on other public forums
I echo @hal2001 's comments.
Irrespective of which was the DAO votes, I think we should be consider solutions such as xERC20 that help mitigate problems that can arise with any single bridge instance, by allowing the DAO to simply block access to a malicious bridge.
From a technical and risk perspective, I recommend using a canonical bridge for all rollups and zk rollups, like Scroll. For chains like Avalanche, BNB, and Neutron, it would be good fit to use an xERC20-like approach or bridge agnostic integration similar to what Neutron has done to prevent liquidity fragmentation. Neutron’s approach allows you to easily add more bridges in the future, enhancing the safety of bridging. You can find more details in the technical spec here.
I am honestly a bit speechless by what I’m witnessing here. All of the involved parties are burning quite a bit of goodwill in my eyes through what must be described as sketchy sales tactics.
By unilaterally deploying a bridge and marketing it in an official-seeming way, it feels like you are trying to pressure the DAO into accepting your proposal to avoid liquidity fragmentation and bad UX for users. Driving users to it through marketing makes accepting an alternate bridge proposal more painful. These actions put the DAO, Lido stakers, and participating chains in a difficult position.
LayerZero’s solution might be the best one, but it should be evaluated
- at the DAO’s pace and timeline
- according to agreed-upon specifications
- alongside other vendors’ proposals
- and with ample time to evaluate their security
I don’t think this proposal should go to Snapshot in its current form, and if it does, I will vote against it and recommend others do the same. Again, it might be the case that LayerZero’s bridge is the optimal one, especially for other L1s where trustless bridges are impossible. But this is not the way to run this process, and we should first do a public retro on what happened and then run it back properly.
Hi, first time here, I’m just a user and stakeholder of Lido. I am really concerned about what Layer 0 has done with their announcement.
Announcing something that wasn’t even voted on as if it was already a reality is disrespectful to the DAO, and a clear gesture of unseriousness.
Layer Zero is a super centralized option that exposes Ethereum’s main protocol to an unprecedented catastrophe.
A hack in the verification layer (not trustless, it is verified by an “oracle” totally unrelated to the transaction) would imply that infinite wsteth will be minted.
As several people here have said, xERC20 would be a viable solution since daily minting limits can be set per Bridge and it will allow us to choose between several solutions simultaneously.
It also allows us to “disconnect” a Bridge provider in case of emergency.
Finally, I think that choosing Layer Zero as Bridge Provider is a mistake, Lido means decentralization for Ethereum… it does not make sense to expose it to risks typical of centralized protocols such as Multichain.
Folks, I didn’t quite realize that LayerZero has fully launched this into production, despite there being no official approval from Lido.
Right now on stargate.exchange if you go to bridge wstETH from Ethereum to Avax/BNB/Scroll, you are bridging into LZ’s proprietary OFT standard. This looks completely official. There is no “beta” or “wrapped” or “demo” language used at all.
Normal users have no idea that they will NOT be receiving an official Lido wstETH token.
Moreover, the security concerns here have not been discussed at all. I believe the message oracle being used by LayerZero is Google’s oracle, which is completely centralized and not censorship resistant.
I personally feel that it is completely inappropriate to deploy this into production before the LidoDAO voted on or approved anything. My view is that LayerZero should take this down until a DAO vote happens.
This is already ridiculous and proves me right about my previous comment.
By implementing Layer Zero, Lido would have no control over what happens with wstETH.
As you rightly said, there are options, such as xERC20 which would be a token deployed and controlled by the DAO.
We’ve been closely observing the ongoing discussions regarding the implementation of LayerZero’s OFT standard, particularly its application to wstETH.
First and foremost, it’s important to recognize the potential advantages of adopting a token standard like OFT or xERC20 for wstETH. Such a standard could potentially improve the rates and execution efficiency for bridging wstETH across different chains. This could be beneficial for aggregators, including ourselves, and the broader ecosystem.
However, we have some reservations regarding the manner in which the current proposal has been presented and marketed as an official statement, some of which were rightly voiced out by hal2001 in his comment.
Furthermore, building on our expertise of working deeply with bridging solutions and previous partnerships with DAOs, we suggest the Lido DAO consider the following recommendations:
- Using the Native Bridge for Scroll Deployment
Using the native bridge for an L2 does not introduce any new trust assumptions as it only relies on the open source, core bridge infrastructure of the chain.
This approach aligns with the recommendations made by the Uniswap Bridge Committee to the Uniswap DAO for their cross-chain governance messaging needs. Consequently, opting for a third-party bridge where a secure, battle tested native bridge exists may not be the most compelling choice.
- Adoption of a Multi-Bridge, Agnostic Token Standard like xERC20
While mint-and-burn token standards offer notable benefits in terms of pricing and user experience, they also carry significant risks when linked with an underlying messaging bridge. Given the crucial role of Lido and wstETH in the DeFi ecosystem, it’s prudent to mitigate these risks by distributing minting rights across various bridging solutions.
To this end, we propose that the DAO considers xERC20 as a potential solution.
“xERC20 allows tokens to be minted and burned across chains by multiple bridges (canonical or 3rd-party), while giving token issuers the ability to granularly control their security preferences for each bridge using rate limits.”
A recent example is Beefy’s launch of their $BIFI token as an xERC20, using LayerZero, Axelar, and Chainlink’s CCIP for messaging, coupled with mint/burn rate limits of 2.5k per day per bridge, reducing the dependency on any single bridge provider.
Conclusion and Call to Action
In conclusion, we urge the DAO to thoroughly examine the advantages and drawbacks of the various solutions under consideration. It is vital not to hasten the decision-making process regarding the deployment of wstETH across chains.
We support hal2001’s proposal for issuing an RFP (Request for Proposal) to explore options for bringing wstETH to different chains, and we advocate for an extensive, informed debate within the community. Such a measured and collective approach will undoubtedly contribute to the most beneficial outcome for the DAO and the wider ecosystem.
Thank you for considering our perspectives.
The parallels between this situation and Lido’s 33% attack on Ethereum are unmistakable.
Seems to me that Lido folks are now getting a taste for what it feels like when a large, profit motivated party uses their marketing and execution prowess to irresponsibly endanger a permissionless protocol.
You can’t complain about what Layer Zero is doing to Lido and then turn around and do the same sort of thing to Ethereum.
I mean, you can, but it’s hypocritical and lacks integrity.
LayerZero and Stargate today are tightly coupled, which is fine - we understand the need for liquidity when marketing a bridge. However, from a network architecture perspective, liquidity should be completely decoupled from the transportation mechanism. In other words, the coupling of liquidity with the underlying transport mechanism is not an ideal setup for the benefit of the wider network. Liquidity fragmentation is a real issue in the ecosystem, and unifying liquidity should be a top priority for blue-chip projects like Lido.
The existing methods of bridging tokens via liquidity pools are not scalable, and I support “mint and burn.” Though this is not without grave concerns. The mint and burn mechanism grants the transportation layer (LayerZero) an overwhelming amount of power, as the security is now solely in their hands. Some controls can be put in place, such as limits on the amount minted per time period and other decentralized manual approval mechanisms. However, I hold the opinion that giving that power to one single project is too much power to hold.
A better solution is to adopt an OFT (or similar) standard across all networks but mandate the integration of more than one transportation layer to allow for minting. For example, combining the security of LayerZero and Axelar to jointly approve mints (high limit) would be more secure. After all, it’s unlikely both bridges are compromised at the same time. I understand BIFI token is using xERC20 however wstETH’s marketcap would make this a target for exploits. One drawback of such a design would be the relatively higher cost since more than one confirmation is needed - but there are things we can do to optimize this.
If users prefer a more secure bridging mechanism, then they can use the native bridge between L1 and L2 for that. Though users would still want to bridge from L2s to other alt L1s or L2s, in that case, requiring users to go back to L1 and then bridge away is not an efficient route currently as L1 has higher gas requirements. At the same time, if a fast bridge like LayerZero is used from L1s to other chains, then there would still be security implications and liquidity fragmentation. Overall, IMO OFT is the right direction, and I anticipate most users will not care for the added security and would prefer convenience. When adopting OFT (or similar) standards, I highly recommend we consider decoupling liquidity (projects adopting OFT) from the underlying transportation mechanism.
Hi all - I’m usually in my Rocket Pool corner, but wanted to come over to support Lido DAO here.
This situation sucks. It’s bad for users, bad for Lido, and will be bad for Layer Zero. Not sure why we’re here.
Possible paths all suck:
- Lido decide to use Layer Zero
- We get visible “proof” that you can use someone’s name to leverage even the biggest defi protocol to do what you want
- Importantly – there is no way to determine if Lido actually opt in because it’s the best choice or to try to avoid confusion etc
- Lido decide not to use Layer Zero and use a different bridge
- Liquidity fragmentation, confusion, etc.
- The stargate example is a good one. Will they switch? Will wstETH from stargate in October be different than wstETH from stargate in March? Will wstETH from stargate be counter to the one supported by Lido DAO? Will they continue to use Lido DAO’s branding and naming??
- Note that this issue will be replicated for every protocol that uses the current iteration of wstETH.
- Lido decide not to expand to a chain that has a Layer Zero token
- Users will be misled by branding, naming and phrasing like “NATIVE wstETH CAN NOW BE TRANSFERRED”. This was an active choice – compare with axlrETH, for example
- These paths can be followed differently per chain, which may make for even more confusion
No real advice (and not really my place). Hope you guys find the best path possible.
Gm Lido community! A lot of folks have forwarded this thread to me so figured I should leave some thoughts.
It sounds as though a more in-depth discussion of the tradeoffs/specifics of EIP-7281 (xERC20) could be helpful, but this isn’t the best place/time for it (disclaimer: I’m the author of the EIP).
Instead, I’d like to focus on some key higher-level points that I think Lido should take into consideration while thinking through the overarching strategy for chain expansion.
- Any vendor-locked-in approach to bridging (particularly one without security limits of some sort) creates a systemic risk for wstETH. By extension, this creates a systemic risk for Ethereum itself.
- The most secure mechanisms for crosschain message verification, such as shared sequencers for L2-L2 or an m-of-n marketplace of zk light clients (e.g. Hashi, MMA) for L1-L1, are still under development and will take time to reach implementation maturity and economic viability.
- Despite the above, there is clear and salient market demand for wstETH to exist on more chains. This market need is what is driving LZ to yolo-deploy their own wstETH implementation today. Following on @valdorff’s comment, projects deploying fragmented and competing wstETH representations are a lose-lose scenario that will continue to occur in cases where Lido doesn’t explicitly own or enshrine a given wstETH representation as “canonical”.
Lido needs a way to (securely) meet the needs of the present while maintaining the optionality to support better interoperability mechanisms as they become available in the future. Realistically, this looks like an open interface where Lido can decouple the deployment of wstETH to new ecosystems (and subsequent cost-efficient bridging) from the security of the system as a whole.
Thank you to the DAO for the thoughtful engagement here. We are happy to see the robust dialogue and encourage dedication of ample time and resources to broader discussion within the DAO around wstETH on L2s.
We respect and acknowledge the DAO’s immediate desire to use canonical bridges for L2s. Further, we strongly agree with the DAO that if the protocol or users are indifferent to the benefits of horizontal composability then the best way to move assets onto L2s is through native bridges.
When we constructed the initiative to deploy wstETH with horizontal composability, each network was included only upon the explicit desire and opt-in of their respective core teams. Based on the current feedback, we recognize the preferences of the DAO regarding native bridges and L2s and have, in coordination with Scroll, requested that the Stargate Foundation removes the bridging of wstETH into Scroll.
Per the original forum post above, we request that the Lido DAO claim ownership of the contracts on BNB and Avalanche; the Lido DAO has entire control over the native token once ownership is accepted, including minting limits and additional security configurations. Once accepted, LayerZero Labs maintains no ability to mint or burn tokens, by design. The implementation follows the specifications which were utilized in the expansion of wstETH to Neutron, as advised by the Lido core team.
We have been engaging with the Lido Core team, community members, and independent security teams for several months now on this specific permissionless deployment and made adjustments to the approach based on their feedback. We hope there is further engagement by Lido contributors to discuss the technical specification further and to cover any concerns or inaccuracies present in the forum. As always, we are eager to support the growth of cross-chain LSTs at-large in alignment with protocol builders.
Note: The original post has been updated to reflect the changes made based on robust engagement with the DAO.