0x02 CSM: New Permissionless Module Launch

Summary

This proposal introduces 0x02 CSM, a new permissionless staking module that gives Node Operators a way to run validators with 0x02 withdrawal credentials, supporting an effective balance of up to 2,048 ETH. It complements the existing module, referred to as 0x01 CSM from here on, which continues serving smaller operators unchanged.

As set out in the recent Snapshot vote for LIP-33, 0x01 CSM will be upgraded (subject to DAO approval) to CSMv3 to support the new validator standard, while a dedicated 0x02 module instance will be left for a separate rollout, with its own parameters.

This proposal seeks Lido DAO approval for the 0x02 CSM rollout, its launch parameters, and a 20% maximum combined stake share limit for 0x01 and 0x02 CSM together. Full technical details are available in the 0x02 CSM Landscape forum post.

Motivation

Ethereum's Pectra upgrade (EIP-7251) raised a validator's maximum effective balance from 32 ETH to 2,048 ETH. This enables reward compounding, reduces the number of validator keys required for a given amount of stake, and lowers consensus-layer overhead, an important requirement for future Ethereum upgrades. Hence, supporting 0x02 credential adoption is a priority for Lido contributors.

However, technical limitations make it impractical to support both 0x01 and 0x02 credentials within the same module. Unlike 0x01 validators, which have a fixed balance of 32 ETH, 0x02 validators may range from 32 to 2,048 ETH. This variance across a single module would complicate deposit handling and bond-risk management, particularly because Ethereum currently lacks an on-chain mechanism for capping validator size.

For these reasons, 0x02 CSM is proposed as a separate module: it gives Node Operators a permissionless path to run 0x02 validators through the Lido protocol, while 0x01 CSM continues to serve smaller operators and its existing operator types, such as ICS and IDVTC, without change.

This proposal is made with the following objectives:

• Give Node Operators a permissionless path to run 0x02 validators through the Lido protocol.
• Improve DAO take-rate while offering a capital-efficient solution for Node Operators.

Design

New instance. 0x02 CSM is proposed as a separate module instance that complements 0x01 CSM rather than replacing it. 0x01 CSM will continue serving smaller operators and existing operator profiles unchanged. 0x02 CSM instance is built on the same updated CSM codebase that powers CSMv3 and CMv2.

Stake allocation. Because 0x02 validators require significantly more capital than 0x01 validators, stake will be allocated in two stages. First, an initial deposit queue allocates the first 32 ETH required for each validator key to activate and begin earning rewards without the full 2,048 ETH being funded upfront. Once activated, the validator moves to a capacity-limited top-up queue that progressively brings it toward full balance as protocol inflows allow. A seat in this queue represents one validator actively receiving top-up stake; once a validator reaches its full 2,048 ETH balance, it exits the queue and frees its seat for the next one in line. The exact number of top-up queue seats will be proposed closer to mainnet deployment in ~Q4.

Consolidations. Unlike the CMv1 → CMv2 migration, existing 0x01 CSM operators will not have a consolidation path into 0x02 CSM. Supporting consolidations in this case would require operators to maintain a bond in both modules during the transition and would introduce significant coordination overhead. An operator wishing to migrate to 0x02 CSM will instead need to exit their 0x01 CSM validators and fund new keys in 0x02 CSM, or run in both modules simultaneously.

Economics. While 0x02 CSM increases the nominal bond per key, it improves capital efficiency for Node Operators at scale relative to the default 0x01 CSM operator type. Although the nominal bond requirement is higher in absolute terms — 32 ETH for the first key and 30 ETH for each additional key, compared with 2.4 ETH and 1.3 ETH under 0x01 CSM — this should be assessed in the context of the larger validator capacity enabled by 0x02 CSM. A fully topped-up 0x02 validator can hold up to 2,048 ETH, which is 64 times the 32 ETH validator balance under 0x01 CSM. When normalized per 32 ETH of validator balance, the proposed bond corresponds to 0.5 ETH for the first key and approximately 0.47 ETH for each additional key. This represents a reduction of approximately 4.8x for the first key and 2.8x for each additional key, in bond required per unit of validator balance. With a 2% reward share for the Node Operator and 8% for the DAO, this gives Node Operators a higher capital multiplier than 0x01 CSM: approximately 2.18x for the first key and approximately 2.26x for each additional key, with the Node Operator’s overall capital multiplier approaching 2.26x as more keys are added, compared with up to around 1.76x for the default 0x01 CSM type.

Parameters

The proposed parameters for 0x02 CSM are:

Parameter	Proposed Value
Bond	32 ETH for the first validator key; 30 ETH for each subsequent key
Reward split	2% to the Node Operator; 8% to the DAO
Key removal fee	0.02 ETH
General penalty fee	0.1 ETH
Performance leeway	3%
Strikes	3 strikes / 6 frames lifetime
Bad performance penalty	0.258 ETH per 32 ETH of balance, up to 16.512 ETH for a fully topped-up 2,048 ETH validator
Keys limit	Not set
Performance coefficients	54/64 for attestations, 8/64 for block proposals, 2/64 for sync committee
Exit delay charge	0.1 ETH per key after 4 days

Note. The bond and reward split are proposed specifically for 0x02 CSM. The remaining parameters follow 0x01 CSM's Default type as published at the time of this proposal. These values may be updated in the future.

Operational controls

The CSM Committee would take on the same operational and emergency roles for 0x02 CSM that it holds for 0x01 CSM, specifically:

• Report or cancel penalties for protocol violations through a direct on-chain action.
• Settle confirmed penalties through Easy Track.
• Roll back the top-up queue through a direct on-chain action in case invalid top-up information is delivered.
• Change the bond curve for a specific Node Operator through a direct on-chain action.
• Pause 0x02 CSM in an emergency via CircuitBreaker.

Stake share limit

This proposal sets a 20% maximum combined stake share limit for 0x01 and 0x02 CSM together and proposes assigning responsibility for managing the allocation between the two modules to the CSM Committee. The CSM Committee would change the stake share limit for both modules via Easy Track within the DAO-approved combined cap, following the same mechanism it already uses for 0x01 CSM, as set out in the LIP-33 snapshot.

0x02 CSM's initial stake share limit specifically has not yet been determined since it depends on the state of the Ethereum validator network and Curated Module v2 at the time of release, and is expected to be initially low (approximately 0–2%). This will be revisited and proposed as part of the mainnet release, targeted for Q4.

As operators move from 0x01 CSM to 0x02 CSM over time, 0x02 CSM’s share is expected to grow while 0x01 CSM’s share decreases.

Next steps

If this proposal is approved:

• An on-chain vote will be submitted to activate the 0x02 CSM instance with the approved parameters and grant the proposed roles to the CSM Committee.
• The exact number of top-up queue seats and the initial 0x02 CSM stake share limit will be finalized and brought forward as part of the mainnet release, targeted for Q4.
• The CSM Committee's mandate will be extended to manage the 0x02 CSM stake share limit via Easy Track together with the 0x01 CSM, within the approved 20% cap and under the proposed conditions for scaling 0x02 CSM's share.