[DEPERCATED] CSM v2

This doc is closed!

Pls comment on and refer to https://hackmd.io/@lido/csm-v2-internal

The first version of Communty Staking Module (CSM) has been live on the mainnet since October 2025. To ensure the timely delivery of the updates regarding Pectra hardfork and improvements that have already been discovered, research and development regarding the second version of CSM should be started.

Scope

There are several important features and improvements to be implemented in the new version of CSM:

• EIP-7002 support with respect to the corresponding changes in the LoE protocol;
• Strikes system allowing for ejection of the bad-performing validators;
• Improvements in the CSM Oracle algorithm;
• Transformation of the Early Adoption mechanics into the Entry Gates mechanics;
• Introduce a beneficial reward share for Identified solo stakers;
• Introduce a priority deposit queue for Identified solo stakers;
• Introduce a separate performance threshold for Identified solo stakers;
• Remove separate slashing reporting due to the initial slashing penalty reduction in Pectra;
• Reconsider bond curves concerning the Pectra changes;

Note on EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

With the introduction of the EIP-7251, Ethereum validators might be consolidated into large (2048 ETH) validators or created to be large initially. This allows for a significant decrease in the load on the P2P network due to a reduction in the number of peers. However, with no ability to specify a "custom ceiling" for large validators, stakers can only choose between small (32 ETH) and large (2048 ETH) validators. Regarding overall protocol capital efficiency, it only makes sense to consolidate small validators into large ones or create large validators if the balance of the resulting large validators will be >= 1700 ETH (see research results by Lido contributors). The word "Community" in the name of CSM means that the target audience for the module is community stakers who run around 10-20 validators on average. This means that for most of them, consolidation would be capital-inefficient for the protocol. At the same time, community stakers will not benefit much from the consolidations given the low per-validator bond requirements (1.3 ETH currently and around 0.6 ETH in CSM v2). With that said, and because CSM could not support large validators without corresponding changes in the underlying LoE protocol, it is proposed that the support of the large validators should not be added to CSM v2.

However, support of the large validators from EIP-7251 might be considered again in the future once the real data about average per-operators validator counts will be available and LoE protocol will introduce support of the large validators.

Note on Preconfirmations support

Preconfirmations are a hot topic in the Ethereum space. Research is being conducted on implementing preconfirmations support at the Lido protocol level. Depending on the research outcomes, additional features should be considered for inclusion into CSM v2.

EIP-7002 support

Execution Layer Triggerable Exits (EIP-7002) will allow staking protocols to request exits for the validators with the withdrawal credentials pointing to their contracts. However, this method of exit requesting comes with a fee. Hence, the existing method of requesting exit by signing a corresponding message with the validator private key is still preferable.

There are several cases when CSM might require usage of the EL triggerable exits:

• To trigger exits for validators that were requested to exit by VEBO but were not exited in time;
• To trigger exits for validators demonstrating unacceptable performance for a long period of time;
• To allow CSM Node Operators to trigger exits for their own validators in a case when validators' private keys were lost;

The first case should be resolved within VEBO since CSM does not have information about the validator keys requested by VEBO in case of exit requests for withdrawal coverage or due to targetLimit. However, VEBO should inform CSM (using a "hook" method) about the exits being triggered for delayed validators so that CSM can penalize the Node Operator's bond. This penalty should not be burned but transferred to the Lido DAO treasury to cover the fee paid by VEBO to trigger exit requests.

CSM must directly initiate both second and third cases since the exit should be triggered for a particular key. This means that the LoE implementation of the EIP-7002 should be able to request exit triggering for a particular validator key directly.

In the case of ejection due to strikes, all corresponding penalties should be applied upon ejection. It is worth considering a tip for the method caller to compensate for the gas costs + premium. This tip should be confiscated from the Node Operator's bond.

When it comes to voluntary ejection, the module should not apply any additional penalties, assuming that Node Operators will pay the total price for the ejection themselves.

It is also proposed to allow DAO (via vote or EasyTrack) to explicitly request ejection of the CSM validators.

Summary

The considerations listed above can be summarised as follows:

• VEBO SHOULD manage exits triggering for the validators that were not exited voluntarily after the request;
• The protocol part responsible for the exits triggering SHOULD inform CSM about exits being triggered for the delayed CSM validators (with the information about Node Operator ID);
• LoE protocol SHOULD allow CSM to request exits triggering for the CSM validators directly;
• CSM SHOULD implement voluntaryEjectValidator method to allow Node Operators to request exit triggering for their validators;
• voluntaryEjectValidator method SHOULD be callable by the DAO;
• CSM SHOULD implement a method allowing trigger exits for the validators with a significant amount of strikes;

Bad performance strikes

This topic is too broad for the current document. Please refer to the separate document for details.

Improvements in the CSM Oracle algorithm

Currently, there are several identified improvements to the CSM Performance Oracle:

• Exclusion of the Node Operators from the rewards allocation pool if any of their validators were slashed during the rewards allocation frame;
• Introduction of a more sophisticated performance calculation algorithm that would include block proposals and possibly sync-committee participation. See here;
• Propper handling of the missed frames. If the frame is missed for some reason, the next report should be calculated as two joint reports but not one for the longer frame;

Summary

The considerations listed above can be summarised as follows:

• CSM Performance Oracle SHOULD exclude Node Operators from the rewards allocation pool if any of their validators were slashed during the rewards allocation frame;
• CSM Performance Oracle SHOULD account for the block proposals and sync-committee participation within the performance metric used;
• CSM Performance Oracle SHOULD properly handle missed frames and deliver next report as a sum of two individual reports not one for the longer frame;

Evolution of the Early Adoption Mechanics

The main purpose of the Early Adoption Mechanics is to allow identified solo and community stakers to join CSM during the Early Adoption period, which starts with the module deployment and can not be activated again once it has ended.

It is assumed that the Early Adoption period will have ended by the time of the CSM v2 upgrade. Hence, it seems reasonable to remove this mechanic from the module code.

One counter-argument to the full removal of the Early Adoption mechanic is that the beneficial bond curve is set for the Node Operators created from the address included in the Early Adoption List.

The Early Adoption mechanic is proposed to be transformed into updatable lists of the identified operators. This will allow for multiple updatable lists of the identified operators grouped by different criteria, such as solo stakers, public good operators, small pro-operators, etc.

To encourage these groups of operators to join CSM even after the end of the Early Adoption period, it is proposed to:

• Rename the Early Adoption List to the Identified Stakers List(s);
• Move the participants of the existing Early Adoption List who haven't joined CSM yet to the Identified Solo Stakers List;
• Allow for the update of the Identified Solo Stakers List by the Lido DAO to make it possible to add new solo stakers during CSM operation;
• Allow permissionless participants to claim solo staker benefits should their address be added to the Identified Solo Stakers List after they join CSM;

The Identified Stakers Lists feature will require significant changes to the CSM contracts that can be illustrated in the following picture:

A new permissioned method createNodeOperator is required. Instances of the VettedAddressesRegistry are allowed to create CSM Node Operators executing prior checks. PermissionlessGate is required to keep permissionless entry to CSM.

Each entry contract should be pausable to mitigate any possible list issues. The lists can be updatable via Easy Track to reduce the governance load.

Since entry contracts are attached to CSM using roles, third parties can develop their gate contracts. Gate contracts can be entry gates that assign custom bond curves to the operators or full-featured add-ons with their own accounting and underlining operator structure (say, for DVT). This opens up a vast potential for third-party CSM integrations.

A more general approach called Gates and Extensions is described in a separate document. Implementing this general approach in CSM v2 is proposed. A solution described above can be treated as a particular case of the generalized approach.

Beneficial fee for Identified solo stakers

One option that might allow for sustainable CSM growth is progressive fees. Shortly, CSM can allocate different fees for the first N validators, second M validators, and so on. This will allow for high fees for the first N validators (early joiners) and ensure that the module growth fee structure remains sustainable.

CSM fee on the SR level can not be variable. Hence, it should be set to the highest possible value. CSM should be capable of transferring excess stETH rewards to Lido DAO treasury upon Oracle report. CSM Oracle should manage fee allocation off-chain.

Additional considerations regarding progressive fee are here.

Summary

The considerations listed above can be summarised as follows:

• CSM fee in Staking Router SHOULD be set to the maximal possible fee for the CSM validators;
• CSM SHOULD be capable of transferring excess stETH rewards to Lido DAO treasury upon Oracle report;
• Fee parameters SHOULD be stored on-chain and SHOULD be configurable by the Lido DAO;

Priority deposit queue for Identified solo stakers

"There should always be a way for the solo staker to join CSM and start validating fast" - Max

The main idea of the priority deposit queue for Identified solo stakers is to allow for a feasible opportunity for identified solo stakers to join CSM and start validation in a moderate amount of time when the CSM queue is already filled with permissionless operators. Limiting this benefit to a certain amount of validator keys is crucial to prevent active sibling of the identified solo stakers list.

It is proposed that a separate priority queue be introduced. If the Node Operator is an identified solo staker, the first N keys uploaded by them should be placed in the priority queue processed before the main queue.

Additionally the approach proposed can be extended to multiple priority queues. A more detaled information is presented in the separate document.

Summary

The considerations listed above can be summarised as follows:

• CSM SHOULD implement the priority deposit queue for the identified solo stakers;
• Only the first N keys uploaded by the identified solo staker SHOULD be placed in the priority queue;
• Priority queue SHOULD be processed before the main queue;

Separate performance threshold for Identified solo stakers

As CSM grows bigger, Lido DAO might consider raising the performance threshold utilized by the CSM Performance Oracle. This will result in more strict performance conditions for the identified solo stakers.

It is proposed to introduce a separate performance threshold for the identified solo stakers so that the existing value of the performance threshold can be kept for the identified solo stakers. In contrast, the performance threshold for the permissionless operators might be increased.

Summary

The considerations listed above can be summarised as follows:

• CSM SHOULD implement a separate performance threshold for the identified solo stakers;

Parameters registry

To allow for the three features described above and their extension to the other Identified Stakers Lists a separate registry contract is required. The contract is described in detail in the separate document.

This approach will allow for the addition of additional benefits and parameters in future should the CSParametersRegistry be upgradeable.

Removal of the separate slashing reporting

The initial slashing penalty will be reduced with EIP-7251 from 1 ETH to 1/64 ETH for the 32 ETH validators. Given the associated gas costs, reporting the initial slashing will become useless after Pectra.

More details on the solution space here.

Summary

The considerations listed above can be summarised as follows:

• Permissionless method for slashing reporting SHOULD be removed from the CSM and CSVerifier;

Links

• CSM Strikes system
• Updated CSM Performance Oracle algorithm
• CSM Gates and Extensions
• Progressive fee considerations
• Priority queues in CSM v2
• Parameters registry
• Lido SR, Modules & NO Types