LIP-33: CMv2 and CSMv3 Architecture, Key Parameters, Rollout Plan

Summary

This proposal introduces upgraded versions of the Community Staking Module and Curated Module — CSMv3 and CMv2 — with support for 0x02 validator withdrawal credentials introduced in the Pectra hard fork. More details can be found in LIP-33.

This proposal seeks Lido DAO approval for the CSMv3 and CMv2 architecture, rollout and migration process, Easy Track governance model, and key parameters, including a proposed 15% TVL upper bound for the CSM stake share limit.

Motivation

The CSM has proven to be a scalable and reliable staking module that supports permissionless participation, while the CM has played a key role in maintaining the quality and stability of the validator set. However, the current versions of both modules do not support 0x02 validator withdrawal credentials, introduced in the Pectra hard fork and essential for Ethereum’s scalability and future upgrades. Additionally, the existing CMv1 has remained largely unchanged since Lido v2 and lacks efficient mechanisms for stake redistribution and flexibility in operator management. As a result, it has become increasingly misaligned with the Lido protocol’s evolving needs.

The proposed upgrades — CSMv3 and CMv2 — address these limitations and provide a foundation for future protocol evolution. A detailed motivation is available in the dedicated section of LIP-33.

As CMv2 and CSMv3 share a substantial portion of their codebase and are expected to be maintained by the same group of Lido protocol contributors, this proposal submits both modules for DAO consideration as part of a single vote.

Design overview

Community Staking Module v3 (CSMv3) is a technical upgrade to CSM that introduces improvements in scalability, efficiency, and operator management. The key change is native support for 0x02 validator withdrawal credentials that enable the operation of validators with effective balances up to 2048 ETH. Additional enhancements include built-in reward distribution splitting across multiple addresses, semi-automated penalty handling, and more granular role-based access controls for managing Node Operator type parameters.

Curated Module v2 (CMv2) represents the next stage in the evolution of the CM. Built on the CSM codebase, CMv2 exclusively supports 0x02 validator withdrawal credentials and inherits some key concepts from CSMv3, such as validator bonding, semi-automated penalties, and improved Node Operators UX (on-chain self-service updates for NO metadata and addresses, on-demand reward claiming, a configurable reward claim initiator address, etc.). In addition, CMv2 introduces several fundamental features, such as Node Operators Meta Registry, weighted stake allocation, and a foundation for the upcoming Validator Marketplace (ValMart).

The full specification is available in LIP-33. The full set of proposed module parameters is published on IPFS.

The CMv2 and CSMv3 codebase is currently undergoing security audits jointly with the Staking Router v3 audits. Final audit reports will be published on the Research forum prior to the mainnet on-chain vote.

Easy Track factories

To support day-to-day operations, it’s proposed to use Easy Track factories to enable Node Operators, the CSM Committee (CSMC), and the Curated Module Committee (CMC) to execute routine actions without specific DAO pre-approval, namely:

• Support stake migration from CMv1 to CMv2 by linking operators into consolidation pairs, with requests initiated by Node Operators and executed via the validator consolidations.
• Ensure proper stake allocation between sub Node Operators by creating and updating operator groups in CMv2 with motions initiated by CMC.
• Ensure accurate penalty accounting across both modules by reporting slashing and confirmed general penalties, with motions initiated by the relevant committee for each module.
• Enable module participation by updating allowlists of eligible participants — for any operator in CMv2 and Identified Community Staker (ICS) / Identified Distributed Validator Technology Cluster (IDVTC) operators in CSM — with motions initiated by the relevant committee for each module.
• Flexibly manage permissionless share of the Lido protocol by updating key CSM parameters (stake share limit and priority exit threshold) within built-in safeguards that cap the maximum value change delta allowed in a single Easy Track motion, with motions initiated by the CSMC.

Transition and supporting updates

CSM migration plan

The transition to CSMv3 will be implemented through a phased approach, separating support for 0x01 and 0x02 validators to ensure continuity of operations and gradual adoption of the new validator standard:

• The existing CSM instance will be upgraded to CSMv3 and will continue supporting 0x01 validators only.
• A dedicated CSMv3 instance supporting 0x02 validators will be proposed with a separate discussion and voting for the module rollout, parameters, and limits.

New operators willing to run 0x02 validators will be able to use the dedicated 0x02 CSMv3 instance. Existing operators will be encouraged to migrate to 0x02 validators over time. This migration will require exiting validators from the current instance and redeploying them in the new CSMv3 instance. To support this transition, a dedicated Node Operator type is expected to be introduced for the 0x02 CSMv3 instance, offering improved conditions (e.g., deposit priority) to incentivize migration, subject to a separate DAO vote.

CM migration plan

The transition from CMv1 to CMv2 will be carried out through a migration process, coordinated by CMC and designed to gradually move stake to the new module:

• A new CMv2 instance will be rolled out as the new Curated Module.
• Stake from CMv1 will be migrated to CMv2 via validator consolidations as part of a coordinated transition process.
• An on-chain vote will be proposed to sunset CMv1 by setting its stake share limit to 0%.
• Upon completion of the transition to CMv2, the previously approved interim CMv1 fee framework will no longer remain in effect.

Parameter changes for CMv1

Under the proposed migration plan, the NOs will leave a portion of their keys (~500 keys each) in CMv1 while migrating the rest to CMv2. If some NOs migrated all their keys to CMv2 while others remained in CMv1 until later, earlier-migrated operators could end up in a more favorable position. By leaving a portion of the keys in CMv1, withdrawal demand can continue to be fulfilled proportionally across all operators until CMv1 is fully emptied.

To keep the fee structure consistent across both modules, it's proposed to reduce the Public Good Operator fee, formerly referred to as the Client Teams fee, in CMv1 from 4.5% to 4%, effective September 1 (the approximate expected start of the active migration process for the first migrators). This aligns with the 4% effective fee the Public Good Operator type will have in CMv2. Other fees in CMv1 will remain unchanged during the migration period. More details on the Research forum.

Future CSM stakeShareLimit increase

Subject to approval of this proposal, the introduction of an Easy Track factory for managing the CSM stakeShareLimit would allow the CSMC to raise the limit via Easy Track motions without a predefined upper bound set on-chain, with each change limited by built-in safeguards that cap the maximum value-change delta per motion. It’s proposed to increase the previously approved CSM stakeShareLimit upper bound from the current 10% of the Lido protocol TVL to 15%, with the CSMC responsible for ensuring that this upper bound, as managed via Easy Track, is not exceeded.

SNOP updates

As part of the transition to CMv2, the existing Standard Node Operator Protocols (SNOPs), namely Validator Exits and Block Proposals, are proposed for update from v3 to v4. Across both documents, the proposed changes expand the scope to Node Operators participating through the new module, reflect the introduction of 0x02 validators and high-balance consolidations under Pectra, add CMC procedures, and align the consequence frameworks with CMv2’s bonding and penalty structure.

The updated SNOPs are expected to come into effect as part of the CMv2 rollout.

• SNOP — Validator Exits: current version (v3), proposed version (v4), side-by-side comparison
• SNOP — Block Proposals: current version (v3), proposed version (v4), side-by-side comparison

Next steps

If this proposal is approved:

• An on-chain vote will be submitted to upgrade the existing CSM instance to CSMv3, activate CMv2 with the approved parameters, and add the proposed factories to Easy Track.
• The transition from CMv1 to CMv2 will be executed through a coordinated process, with the final migration step consisting of a proposed on-chain vote to set the CMv1 stake share limit to 0%, effectively disabling further stake allocation to CMv1.
• The CMC and CSMC mandates will be extended to support ongoing module operations through the proposed Easy Track factories, including CSMC oversight and management of the CSM stake share limit within the approved 15% Lido protocol TVL upper bound.
• A separate discussion and vote will be initiated for the rollout of the dedicated CSMv3 instance supporting 0x02 validators.
• The Standard Node Operator Protocols for Validator Exits and Block Proposals will be updated to their proposed revised versions.
• Upon completion of the transition to CMv2, the previously approved interim CMv1 fee framework will no longer remain in effect.

The proposal is dependent on SRv3 (LIP-35), which introduces the underlying infrastructure required for the proposed module upgrades. As such, both proposals are intended to be adopted and implemented in a coordinated manner. If the proposals are not both approved in the same voting cycle, the rollout process for both upgrades will need to be reassessed.