Unofficial Guidelines for Bridging Solutions - Network Expansion Workgroup

As a member of the Network Expansion Workgroup (NEW), I want to present a set of guidelines aimed at providing clarity for Lido’s community, bridge providers, and various projects in the blockchain space.

It’s important to note that adhering to or deviating from these guidelines will not necessarily guarantee acceptance or rejection of a particular proposal by Lido DAO. However, following these guidelines significantly enhances your chances of garnering support from the community. Ultimately, the final decision rests with the voting activity.

In the realm of bridging solutions, the risks of liquidity fragmentation are real and ever-present. The seamless bridging of a single form of token, recognized and supported by Lido DAO, not only instills confidence in users and protocols but also enhances the overall user experience. This approach allows everyone to build products for L2 users while minimising potential risks. Bridges, while vital to our ecosystem, come with their fair share of risks, as some of the most significant exploits in the past were rooted in bridge-related vulnerabilities.
For those reasons, the NEW is prioritizing and recommending the use of native bridges in case of L2s and networks with open sourced, canonical bridge infrastructure between Ethereum mainnet.
If the native bridge does not exist, is not a public good, or is closed sourced, the NEW will look for a proposal which is based on a third party bridge provider but does not pose vendor lock. It is also worth mentioning that there should be a way to transfer the ownership of the newly minted token asset to the Ethereum mainnet based Lido DAO Aragon contracts and allow for the crosschain vote induced message propagation to the destination network and contract.

To streamline and facilitate the process of bridging Lido protocols’ tokens to other chains, the NEW has compiled an unofficial guideline for potential integrations. This guideline serves as a “reference plan” for integration proposals, encompassing all the necessary checks that our DAO Community is likely to perform and verify before endorsing any specific solution. It is crucial to emphasise that the Lido DAO Governance welcomes input from everyone and is committed to fostering discussions on various potential bridging solutions and directions.

Steps to follow:

  • Prepare the forum post outlining a desired network to expand to & technical plan to get there
    - Target one network per proposal to make the discussion more focused
    - Plan the testnet deployment ahead of the mainnet deployment

  • Prepare / provide audits (as a general rule of thumb, Lido Contributors expect any solution going to mainnet to be audited by a reputable third party)

  • Coordinate on timing and reviews: Lido Contributors are performing security overviews (to the extent possible) across solutions presented; usual questions are:

  1. what upgradability and control scheme, if any, is used by the bridge;
  2. is the bridge native/canonical to the chain;
  3. are the bridging parts and the bridged token audited beforehand, are there any high or critical issues found/present;
  4. are the tokens bridged and/or any token-specific parts upgradable, and if so, by whom;
  5. relation to the core protocol
  6. architecture and invariants robustness
  7. network/rollup specifics (handling/dropping cross-chain messages, failure modes, addresses aliasing, etc)
  8. audit findings
  9. source code verification and audit correspondence
  10. bytecode/init code/constructors/immutables verification
  11. state parameters and their sanity verification
  12. levers and ownership scheme completeness/safety
  13. acceptance tests
  14. guinea-pig deposit/withdrawal tests
  15. deployment scripts assessment (e.g., potential initialization front-running scenarios)
  16. preparing and spinning up monitoring & alerting bots

Regarding the timing of votes, please be aware that they typically occur on a monthly basis. Given the comprehensive nature of these checks, it’s essential to allocate ample time for thorough reviews. To aid in this process, Lido NEW have engaged MixBytes, an organization with a deep understanding of Lido’s codebase.

Lastly, please keep the forum post updated with testnet and mainnet addresses, relevant links, reports, and other critical data points for the DAO’s consideration. The usual timeframe from this point to a snapshot vote is at least one week, allowing the community to engage in discussions and provide valuable feedback.

Please keep in mind that for the asset to be denominated as canonical on a specific network, achieving a quorum on the Snapshot or on-chain vote is essential.


MixBytes is glad to contribute to the Lido NEW initiative by providing security reviews of new integrations. Our dedicated team of 3 security engineers (1 Team lead and 2 security auditors) will provide a second opinion on the integration security compliance using the best practices for code review. The internal checklist that was agreed upon with the Lido tech contributors will be used for each new verification of these integrations.
Disclaimer: The described integrations review methodology is not the common security audit of a protocol’s smart contracts performed by 3rd parties for every new L2, and the MixBytes team doesn’t take responsibility for the quality of the audits performed by 3rd party audit providers.


BNB expansion specific request for proposal is posted here: RFP: wstETH on BNB

1 Like

Hey-hey would also add that for bridging solutions, I would suggest having a preference for end-user bridging payments implemented with the native gas currency/token of the originating bridge side to have a seamless UX.

For L2s, I suppose the end-user bridging payments should have zero fees except for L1 and L2(optional) gas spending only.