Establish the Network Expansion Committee (NEC)

TL;DR

This proposal aims to establish a Network Expansion Committee that will be assigned to formally recognize (w)stETH token bridging endpoints and denominations on new networks as canonical, acting on behalf of Lido DAO.

If the proposal is supported, the informal Network Expansion Workgroup (NEW) will become the Network Expansion Committee (NEC), allowing the Committee to:

• Streamline the process for expanding (w)stETH to new networks without sacrificing the security aspect or transparency
• Inherit the principles presented in the unofficial bridging guide and corresponding previously recognized bridging endpoints and token denominations
• Reuse already used codebase wherever possible + automate deployments

Decision-Making Flow

The NEC makes decisions by unanimous vote of all committee members, followed by an announcement on the forum. Decisions take effect after a 5-day objection period unless community members with a combined LDO of >100k submit objections via Etherscan-signed messages on the forum, in which case the decision is overridden and put to a DAO vote.

Motivation

wstETH got expanded and formally recognized with bridging endpoints by the DAO to 10 networks (Arbitrum and Optimism, Base, zkSync Era, Linea, Mantle, Scroll, BNB, Mode, Zircuit). Lido Multichain was launched as a place where the community can see an updated list of supported networks, statistics, guides, and available integrations. Most of them are Ethereum L2 rollups. These expansions provided significant value for the current and future Lido stakers, which is visible by looking at the Lido Multichain Dune dashboard.

All of these expansions were made possible through work between community members who did the technical lift and the NEW, which provided guidance and best practices, and assisted with the governance process after evaluating the deployment. The NEW has an advisory role and may be responsible for carrying out further actions once the community has made a decision, but it does not have a decision-making role.

Through these 10 expansions, the NEW and other contributors gained a lot of knowledge and made a few observations that led to this proposal:

• The process for expanding Lido staked tokens is a repetitive operational burden both for technical teams and governance voters
• All of the NEW recommended proposals got voted in by the DAO
• Community members recognize the NEW and ask for guidance which is respected
• Arranging network expansion proposals inside regular voting slots results in slow GTM, potentially lowering the short-term value of the expansion itself by missing opportunities

NEC expansion guide per network type

The intent is to make minimal changes to the proven process by following the “if it ain’t broken, don’t fix it” approach.

This means that most of the changes in the process will happen only on the governance aspect, moving the target of the proposal from Lido DAO to the NEC to increase reactivity towards market conditions, user demand and increase the competitiveness of (w)stETH over LST/LRTs.

The NEW has already designed and is currently working on fully automating (w)stETH deployments on the popular OP stack and Arbitrum stack networks. Note: This should not be confused with the default non-upgradeable tokens created by default token bridge instances having no governance rails.

These automated deployments will be encouraged by the NEC as they simplify the deployment and review processes, reduce the potential for human error, while still following the unofficial bridging guide (i.e., dedicated bridge endpoints, upgradeable token, governance forwarder, etc).

For other networks, it is recommended to follow the reference deployments to reduce the workload and avoid the need to do an audit (assuming 0 code changes are needed for the deployment)

• OP stack → automated deployment (reference networks with recognized wstETH: OP Mainnet, Base, Mode, Zircuit)
• Arbitrum stack → automated deployment
• ZKsync stack → follow reference
• Scroll stack → follow reference
• Linea stack → follow reference
• Custom L2 → NEW guide
  • Newly developed or customized code, therefore, requires an audit by a reputable 3rd-party

No matter which flow is taken, the team that worked on the deployment must arrange for a reputable third party to check and vouch for the deployment matching the audited codebase (example).

For networks that do not have a native bridge with Ethereum, the NEC will propose the temporary use of ecosystem-proclaimed native bridges like:

• Wormhole on Solana
• Axelar on Cosmos ecosystem

This does not mean that these deployments are automatically recognized by the NEC. Coordinating these deployments with the NEC in advance is required to ensure flexibility for future changes to multi-bridge solutions and to avoid liquidity fragmentation and technical debt. The NEC will have a right to choose or abstain from choosing the bridge solution for other networks. There will be a NEC-specific form for requesting help with expansions. Later on, NEC may develop a more formalized approach towards non-L2s and networks with ecosystem-proclaimed bridges for further streamlining contingent on demand.

Committee members and vote process

The committee will consist of four members, Lido contributors who can provide expertise on key components for expanding Lido staked tokens to new networks.

DeFiYaco - Protocol Relations thedzhon - Tech Eugene E - Product Nikita P - DAO Ops

NEC decisions require the unanimous support of committee members. Once the decision has been made, it must be announced on the forum by a committee member, along with the reasons for the decision and any supporting material (audits, deployment reviews, and so on).

The prerequisite for committee voting is having a reputable third party to evaluate the onchain deployment matching the audited codebase along with QA tests for the entire user flow.

All NEC decisions will be put on hold for at least 5 days from the time the forum post is published. If no objection is received during this period, the decision will stand. If an objection is received within this period, the NEC decision will be disregarded, and a regular snapshot vote will be held.

To object, anyone can sign an objection message (on Etherscan or any other tool allowing to sign messages on behalf of address holding LDOs) and post the signing address, message, and signature hash as a reply to the forum post. The objection will be considered received if and only if the sum of LDO tokens held at the unique addresses used to sign the objection messages is greater than 100k LDO on the block corresponding to the NEC decision posting.

If the community expresses indecision, the committee will review each case individually and decide whether to change or postpone its decision, taking into account the community's feedback. However, if no objection is received, the expression of indecision alone does not require the NEC to reverse its decision.

DAO vote weight > NEC vote weight: The DAO vote, with a quorum established, can override any NEC decision at any time, including the complete dismantling of the NEC, even if it has already been implemented and released.

A committee member from a particular workstream can be rotated for another contributor from the same workstream if all other committee members agree on that. For example, a Protocol Relations member can be rotated for another Protocol Relations contributor.