RFP: wstETH on BNB

Hey Everyone,

Exciting times ahead! Following LayerZero’s proposal to bring wstETH to BNB, ProRel and NEW contributors are gearing up to make it happen. Here’s a more laid-back breakdown of what’s cooking:

To keep things structured, I’m laying out the suggested plan for the BNB expansion process.

:date: Timeline: Proposals posted to the forum will be considered until December 5th (2 weeks from now). It doesn’t mean the NEW won’t consider proposals after, but for these, we can’t guarantee bandwidth for the review.

Throughout December and the first half of January, we’re keeping the door open for community feedback. :speaking_head:

Now, for BNB, the plan is to go with a 2-step governance process:

:one: Temperature Check Vote (January): Running a poll-based vote with a shortlist of proposals that received positive feedback in December and January. This will help identify the most supported team to kick off development (if not already started).

  • The vote is planned to be a temp-check, exact rules to be discussed elsewhere;

  • The testnet deployment is nice to have, but not required :warning: ;

  • Audits aren’t required strictly but highly desired;

:two: Formal Acceptance (February/March): The outcome is DAO’s recognition of a single wstETH denomination on BNB to be called canonical.

  • Requires the testnet and mainnet deployment;

  • Up-to-date audits by the reputable company (or multiple);

  • Review and verification by the NEW and assigned external security research team (organized by the NEW);

  • The exact Snapshot proposal structure for the “Formal Acceptance” is to be defined after the conclusion of the “Temperature Check Vote”.

The voted in approach for BNB might be suggested for expansions to other non-L2 networks.

For Ethereum L2 network expansions, the NEW still prefers the usage of native bridges. The process for formal acceptance does not change (requires a formal acceptance snapshot proposal → 1 step)

Remember, these timelines aren’t set in stone and will adjust based on how things play out depending on the proposal quantity, complexity, audit slots, and other factors. So, stay tuned, get ready to share your thoughts, and let’s make wstETH on BNB a reality together!




Snapshot vote started

We’re starting the TempCheck: choosing a team to develop wstETH bridge on BNB Snapshot, active till Wed, 24 Jan 2024 16:00:00 GMT . Please don’t forget to cast your vote!


With the Snapshot vote live, the NEW summed up some advantages and considerations for different voting options.


All of the proposals meet baseline expectations and requirements (e.g. avoiding vendor lock-in and minimizing centralization risks).

The following list of advantages and considerations is opinionated, highlights various aspects, and constitutes/attempts to proclaim neither the best nor the worst possible options.


Proposal link:



  • Recently proposed LayerZero V2 addressing centralization concerns about Oracles and Relayers appeared quite recently for in-depth analysis and production trail
  • The Pre-Crime module is proprietary and might introduce additional exposure to censorship risks
  • Mentioned zk technology is green or hasn’t developed yet (e.g. zkOracle by the =nil; Foundation)
  • OFT impl and Endpoints introduce a dependency on the LZ code licensed with LZBL-1.2 (not an open-source license)

Wormhole x Axelar

Proposal link:


  • Experience with Lido-related bridging projects (bETH, Neutron, Solana, cross-chain liquidity hops, etc.)

  • Both providers were recommended by the Uniswap Bridge Assessment Committee (UBAC)

  • Decent Bug Bounty programs by Wormhole and Axelar

  • Open-source Apache 2 license

  • Abstracts away endpoints making it possible to onboard new bridge providers through adapters, starting with two bridge providers

  • Commitment to the Lido DAO governance plug-ins and forwarding

  • Collaboration between the two bridge providers, rather than competition


  • Newly developed and to-be-audited interface contracts
  • Doesn’t follow any of the proposed cross-chain token standards (e.g. xERC-20)
  • The governance forwarding implementation isn’t presented

Chainlink CCIP

Proposal link:


  • Re-using battle-tested DON for the validation layer having the strongest DeFi integration case
  • Experience with Lido-related bridging projects (exchange rate feeds and price feeds)
  • Clearly defined architecture and roadmap
  • A member of BNB Chain DeFi League
  • Trusted by Circle’s CCTP for USDC cross-chain transfers


  • Limited exposure to 3rd parties research — reports haven’t been published yet, e.g. hasn’t been assessed yet by the UBAC

  • Dependency on the BSL License in the code and legal disclaimers

  • BugBounty terms are not usual ‘Unlike other bug bounty programs on Immunefi, all bug report submissions, including associated vulnerabilities, become the exclusive property of Chainlink Labs‘

  • Unusual fees model with LINK token, surcharge for other assets, and subject to change

Hyperlane & HadronLabs

Proposal link:


  • Compatibility with the upcoming multibridge wstETH on Neutron design
  • Experience with Lido on X projects
  • Bridge aggregation focused approach



Really appreciate the work to sum up the various proposals, I think it’s invaluable!


Thank you, @DeFiYaco and the Lido NEW team for this thoughtful write-up!

A brief correction:

  • the zk technology available today within LayerZero is the most mature in the market; LayerZero is the only messaging protocol which can support multiple zkp verification options.

  • Polyhedra, the original authors of the zkBridge white paper, launched their zkLightClient within LayerZero nearly 1 year ago

  • Pre-Crime is 100% opt-in by the application developer (in this case Lido DAO)

  • LayerZero architecture promotes collaboration across validation methodologies such as third-party bridges and native bridges at no-cost of security or new code

  • LayerZero V2 Whitepaper can be read here

We’re excited to engage with community members as they diligence our proposal.

We are grateful to the NEW for their summary of proposals and outlining the advantages and considerations of each, including Chainlink CCIP. In response to some of the considerations, we’d like to clarify those points to help voters make an informed decision.

It should be noted that the UBAC’s assessment of various cross-chain providers did not include Chainlink CCIP as the protocol was not yet live at that time. Additionally, it is important to keep in mind that the report’s focus was specifically on cross-chain governance messaging, which has different requirements and implications compared to cross-chain token transfers, such as this use case of wstETH. That said, we are eager to collaborate with the UBAC in any future re-evaluations as they had originally outlined.

Chainlink CCIP is built to serve as the global standard for cross-chain communication. Ensuring the security of CCIP deployments and the sustainability of the protocol’s economics is crucial to CCIP’s longevity. To support these goals, portions of the CCIP codebase have been initially licensed under a Business Source License (BSL), which will automatically roll into an MIT license after four years. This licensing model is in line with the approach taken by other leading Web3 infrastructure protocols and applications. The source code for CCIP is publicly viewable on GitHub, with on-chain contracts verified across each relevant blockchain explorer. The inclusion of a legal disclaimer in our proposal is a standard business practice.

Since the inception of our bug bounty programs on HackerOne and Immunefi, over $500K in total has been paid across 75+ resolved reports to more than 50 independent researchers. In addition, we have participated in five crowdsourced audits on Code4rena, with participation by over 500 researchers and a total combined prize pool of $700K+.

Participating in audit programs and incentivizing top security professionals are among the strategies used to enhance the security and reliability of Chainlink services, and to uphold Chainlink’s strong reputation for these qualities.

Chainlink CCIP’s fee model is aligned with industry standards, where users pay a low bps-based fee for cross-chain token transfers in native gas tokens (BNB and WBNB in this case) or alternatively in LINK, to cover destination gas fees and provide an economic incentive to nodes. CCIP’s billing model was built to reduce payment friction for users and allow the protocol to quickly scale to new chains. While other cross-chain providers may not inform users that their fees are subject to change, we feel it’s fair to be transparent on this point, given the dynamic nature of the cross-chain ecosystem.

Thanks again to the NEW for their overview and we’re happy to continue the conversation with the community.

Snapshot vote ended

For TempCheck: choosing a team to develop wstETH bridge on BNB, we have a different definition of quorum and winner, as explained in the proposal:

  • A quorum of 50M in total across all options is reached.
  • The leading option must exceed the second candidate by a margin of 20% of votes participated in the vote.

That’s why the current state is:

  • 55.4V voted, quorum reached

The results are:
Wormhole & Axelar Multibridge: 45M
Chainlink CCIP: 7.8M
LayerZero: 2.6M LDO
Hyperlane: 541 LDO

And the winning option is Wormhole & Axelar Multibridge!


a.DI setup for Lido DAO governance forwarding from the Ethereum mainnet DAO Agent to the CrossChainExecutor on the BSC mainnet has been deployed and MixBytes() audit for this setup has been finalized and published in the audits repository.

1 Like