This proposal presents 0x02 CSM to the DAO and broader community as a new module for Community Stakers who want to run validators with 0x02 credentials.
TL;DR
0x02 CSM is proposed as a new permissionless module in the Lido protocol. It is part of a protocol-wide effort to support the widespread adoption of 0x02 credentials.
If approved, it will complement the currently active CSM (referred to as “0x01 CSM” from here on) by giving Node Operators the option to run validators through either 0x01 or 0x02 CSM, with the latter allowing for validators with a maximum effective balance of 2,048 ETH.
0x02 CSM will not have the node operator types that 0x01 CSM has (like ICS and IDVTC), but will offer a stronger capital multiplier for operators and improved protocol economics.
This document explains the new module, its parameters, and how it will coexist with 0x01 CSM.
1. Background
Today’s CSM is built around 0x01 credentials, where each validator can only have a maximum effective balance of 32 ETH. The Pectra hard fork introduced 0x02 credentials last year, raising a validator’s maximum effective balance up to 2,048 ETH. This enables reward compounding, reduces the number of keys needed for the same amount of stake, and lowers consensus-layer overhead—an important requirement for future Ethereum features like faster finality.
Contributing to 0x02 credential adoption is a priority for Lido contributors; stVaults are 0x02-native, and the Curated Module v2 will use them exclusively. Now it’s CSM’s turn to offer a clear path for independent operators to permissionlessly participate in the Lido operator set with 0x02 credentials.
It’s also important to keep CSM accessible, but technical limitations make it difficult to support both 0x01 and 0x02 credentials in a single module, or to achieve the granularity needed to cap 0x02 validators at different balances in a single module and therefore across a range of bonds.
Under these two modules, 0x01 CSM would continue serving smaller operators and the existing types such as ICS or IDVTC, while 0x02 CSM would let operators run higher-balance 0x02 validators.
2. Objectives
This proposal is made with the following objectives:
- Give Node Operators a permissionless path to run 0x02 validators through the Lido protocol.
- Improve DAO economics while offering competitive economics for Node Operators.
- Expand Lido support for 0x02 credentials by adding 0x02 CSM as a complementary module, while preserving access for operators via the different operator profiles of 0x01 CSM.
3. Understanding 0x02 CSM
At a high level, 0x02 CSM is for Node Operators who want to run validators with 0x02 withdrawal credentials in a permissionless way. As with 0x01 CSM, Node Operators are expected to provide a bond for each validator key they upload.
The key difference is that each 0x02 key can represent up to 2,048 ETH. Unlike in 0x01 CSM—where a validator is either pending deposit or fully deposited with 32 ETH—0x02 CSM validators are first seeded with 32 ETH and can later be topped up toward the 2,048 ETH maximum effective balance. As a result, an active 0x02 CSM validator may not always run at full MAX_EB.
The module will be deployed using the updated CSM codebase, the same version that will power the Curated Module v2 and 0x01 CSM. This makes 0x02 CSM part of the broader evolution of Lido staking modules while preserving CSM’s specific operator model and open access.
The rest of this section explains how the module is expected to work in practice, from stake allocation and parameters to module limits and governance responsibilities.
Stake allocation
In 0x01 CSM, each key only needs 32 ETH. But because 0x02 validators are significantly larger, stake allocation in 0x02 CSM is split between an initial deposit queue and a top-up queue.
The initial deposit queue is where uploaded keys wait for their first 32 ETH deposit. This seeds the validator, allowing it to begin the activation process without waiting for the full 2,048 ETH balance.
Once active, the top-up queue is where validators will continue receiving stake toward 2,048 ETH. It follows the order set in the initial deposit queue, but to balance initial-deposit and top-up dynamics, only a limited number of validators can be in the top-up queue at the same time.
The exact number of seats in the top-up queue will be proposed closer to launch. To illustrate the mechanism, the diagram below uses 16 seats as an example:
In this example, the top-up queue has all seats occupied, with Validator A at the front of the queue receiving all incoming stake until it reaches 2,048 ETH. Once full, it leaves the queue and frees a seat.
At that moment, Key P, which was waiting in the initial deposit queue, can receive its 32 ETH deposit and, once active, enter the top-up queue in the newly available seat.
This design lets validators start operating as early as possible with the minimum 32 ETH deposit, while giving them a dedicated path toward the full 2,048 ETH balance, subject to module capacity and protocol inflows.
Bond structure and parameters
Pectra changed the risk profile of validators by reducing the initial slashing penalty. At the same time, not all risks scale proportionally with validator balance. As described in the CSM risk assessment, risks such as slashings and EL rewards rerouting need to be considered separately when designing bond parameters.
This makes it possible to consider a parameter structure with a meaningfully lower bond per 32 ETH of validator balance and a better take rate for the DAO, while maintaining a competitive capital multiplier for Node Operators.
With that in mind, the proposed parameter set is:
| Parameter | Proposed value |
|---|---|
| Bond | 32 ETH first key, 30 ETH subsequent keys |
| Rewards Rate | 2% NO, 8% DAO |
| Capital multiplier | up to ~2.26x |
| Key removal fee | 0.02 ETH |
| Performance leeway | 3% |
| General penalty fee | 0.1 ETH |
| Strikes | 3 strikes / 6 frames lifetime |
| Bad performance penalty | 0.258 ETH per 32 ETH, up to 16.512 ETH for a full 2,048 ETH validator |
| Exit delay penalty | 0.1 ETH per key after 4 days |
For a fully topped-up 2,048 ETH validator, the proposed bond is equivalent to 0.5 ETH of bond per 32 ETH of balance for the first key, and approximately 0.47 ETH of bond per 32 ETH for subsequent keys, a ~3x improvement over 0x01 CSM.
In combination with the 2% rewards rate, Node Operators get an initial capital multiplier of approximately 2.18x, which can increase up to 2.26x as more keys are added.
These figures describe the common full-balance scenario. Actual capital efficiency and rewards depend on each validator’s current effective balance, module capacity, and protocol inflows.
The rest of the proposed parameters are aligned with the Default type in 0x01 CSM, scaled where necessary for the x64 balance of 0x02 validators.
Combined CSM stake share limit
LIP-33 introduced changes that allow module stake share limits to be adjusted more gradually via EasyTrack motions, within predefined bounds. This allows CSM capacity to be adjusted over time without requiring a full governance vote for each change.
This proposal sets a 20% maximum combined capacity for 0x01 CSM and 0x02 CSM. The CSM Committee could then manage the balance between the two modules as the conditions to scale 0x02 CSM (described at the end of this proposal) are met.
The exact stake share limit for 0x02 CSM, along with a more detailed framework for these adjustments, will be shared closer to mainnet deployment.
Governance
0x02 CSM includes some functions that require frequent use or a quick response, such as:
- Reporting or canceling penalties associated with protocol violations like EL stealing via
REPORT_GENERAL_DELAYED_PENALTY_ROLEandMANAGE_GENERAL_PENALTIES_AND_CHARGES_ROLE - Settling confirmed General Delayed Penalties through EasyTrack via
SETTLE_GENERAL_DELAYED_PENALTY_ROLE - Rolling back the top-up queue in case of invalid top-up information being delivered by the Depositor Bot via
REWIND_TOP_UP_QUEUE_ROLE - Change the bond curve for a particular Node Operator via
SET_BOND_CURVE_ROLE - Pausing CSM in case of emergency via CircuitBreaker
It is proposed that the CSM Committee take on these roles for 0x02 CSM as it does for 0x01 CSM, since the users, functions, and expected responsibilities remain largely the same.
4. What this means for CSM
Introducing 0x02 CSM would expand CSM from a single permissionless module into a set of modules spanning both 0x01 and 0x02 credentials.
The main change is that CSM would no longer be limited to 32 ETH validators. In the near term, 0x01 CSM would remain the lower-bond path for node operators, while 0x02 CSM would give operators with more available capital a way to run fewer, higher-balance validators with better capital efficiency.
If included in a future Ethereum upgrade, EIP-8148 could enable more flexible 0x02 validator balances, expanding the bond options in CSM and eliminating the need for two modules.
The sections below outline how 0x02 CSM fits into the broader CSM experience and how existing 0x01 CSM operators should think about moving to 0x02 CSM.
The unified CSM experience
From the operator’s point of view, 0x02 CSM will be treated similarly to a Node Operator type such as ICS or IDVTC, even if under the hood it is a separate module.
Users will be able to manage validators in 0x02 CSM together with their existing 0x01 CSM setup through the same interface.
Putting it together, this is what the CSM landscape would look like after adding 0x02:
| 0x01 Default | 0x01 ICS | 0x01 IDVTC | 0x02 CSM | |
|---|---|---|---|---|
| Entry | Permissionless | Permissionless / verified | Verified DVT cluster | Permissionless |
| Target operator | Home stakers / Small-to-medium independent operators | Home stakers / verified community operators | Verified DVT clusters of Independent Community Stakers | More capitalized independent operators |
| Limitations on who can use this mode | None (open even to professionals) | Must be a verified Independent Community Staker as per the ICS requirements (cannot be a professional node operator) | Must be a cluster of independent participants each with ICS | None (open even to professionals) |
| Validator balance | 32 ETH | 32 ETH | 32 ETH | Up to 2,048 ETH |
| Bond, first key | 2.4 ETH | 1.5 ETH | 1.5 ETH | 32 ETH |
| Bond, subsequent keys | 1.3 ETH | 1.3 ETH | 0.5 ETH | 30 ETH |
| Node Operator reward | 3.5% | 6% for the first 16 keys, 3.5% for subsequent keys | 3.5% for the first 64 keys, 2% for subsequent keys | 2% |
| DAO fee | 6.5% | 4% | 6.5% for the first 64 keys, 8% for subsequent keys | 8% |
| Capital multiplier | up to ~1.76x | up to ~2.36x | Up to 3x | up to ~2.26x |
| Withdrawal credential type | 0x01 | 0x01 | 0x01 | 0x02 |
Consolidations
Unlike in the Curated Module, existing 0x01 CSM operators should not expect support for consolidations to migrate directly into 0x02 CSM.
Using consolidations for 0x01-to-0x02 CSM migrations would require operators to maintain bond in both modules during the transition. It would also introduce significant coordination overhead, making this approach difficult to support in a permissionless module like CSM.
This means an existing 0x01 CSM operator would need to either operate in both modules or exit their 0x01 CSM validators and fund keys in 0x02 CSM.
5. Proposed timeline
0x02 CSM should be understood as a first step toward supporting 0x02 credentials in CSM.
It is also important to recognize that 0x02 CSM would be introduced during a broader transition toward 0x02 credentials, alongside improvements across Lido staking modules.
For that reason, the stake share limit of 0x02 CSM should be raised only once the following conditions are met:
- Curated Module v2 operators have enough seeded and active keys to support the consolidation of stake from v1 to v2, plus sufficient capacity for a reasonable amount of net protocol inflows.
- The Ethereum validator queue and Lido protocol inflows support a reasonable experience for new operators and potential 0x01-to-0x02 CSM migrators.
- The Glamsterdam hardfork is either activated on Ethereum or delayed long enough to avoid requiring an immediate module upgrade shortly after release.
6. Summary of proposal
To summarize, this proposal is to:
- Deploy an instance of CSM v3 configured to support 0x02 credentials.
- Set a 20% maximum stake share for 0x01 and 0x02 CSM combined.
- Launch the module with the proposed parameter set, including:
- A 32 ETH bond for the first key, and a 30 ETH bond for subsequent keys.
- A 2% / 8% fee split between the operator and the DAO.
- The exact number of seats in the top-up queue to be proposed closer to mainnet deployment.
- Assign the relevant operational and emergency roles to the CSM Committee.
