There were many posts about CSM v2 in this thread recently. Topics of CSM Evolution, CSM Rewards Structure, CSM v2 Architecture, Community Stakers Identification Framework, and Major CSM Parameters were covered.
This post attempts to collect the updates from these topics into one place, and give an insight into release and future maintenance.
CSM v2 Release Summary
As a Lido DAO contributor and tech lead of the CSM project, I propose the following plan for the CSM v2 mainnet release:
Step 1. Work with the relevant contributors on the Triggerable Withdrawals implementation (the TW scope and LIP are expected to be published soon) and prepare a joint CSM v2 + Triggerable Withdrawals release.
Step 2. Release CSM v2 + TW on Hoodi testnet at the very beginning of July 2025.
Step 3. Start an on-chain vote to activate a temporary key removal “grace period” (key removal from the queue with no charge) for CSM as mentioned in the recent post.
Step 4. Perform extensive testing of CSM v2 and TW functionality on Hoodi testnet.
Step 5. Propose a Snapshot vote regarding CSM v2 release covering CSM parameter values, CSM stakeShareLimit increase to 5% upon CSM v2 release, and to 10% later in 2025/early 2026 (motivation is provided below), and Community Stakers Identification Framework with the exact sources and weights for each source (proposed sources and weights will be published later in this thread).
Step 6. Finalize security audits of CSM v2 and TW release scopes, and publish the results of the audits in GitHub - lidofinance/audits and on Lido Research Forum.
Step 7. Start an on-chain vote for CSM v2 + TW release in the second half of August 2025.
I encourage the community to investigate the proposed release plan and share their questions/voice support!
CSM stakeShareLimit increase plans
Lido DAO has recently approved a stakeShareLimit increase for CSM from 2% to 3%. As mentioned in one of the posts above, this proposed change is expected to be included in the scheduled on-chain vote for July 2025.
CSM v2 brings several key improvements to the module’s reliability, security, and efficiency, namely:
- An improved Performance Oracle will allow CSM v2 to increase performance tracking precision and enable making rewards distribution more attuned to validator performance.
- The Bad Performance Strikes system will prevent systematically bad-performing validators from significantly dragging down module and protocol performance, as validators not meeting the performance thresholds will be ejected from CSM using EIP-7002.
- With EIP-7002 implemented at the Lido protocol and CSM levels, the risk of “stranded” (e.g. due to lost keys) or stake being held by a potentially malicious operator is fully mitigated.
- An updated reward structure aligns CSM v2 with other Lido protocol modules from the view of operator economics. As a hypothetical example: if we take the current key distribution in CSM (June 24, 2025), assume all EA participants convert to ICS, and all depositable keys get stake allocation, the Lido DAO reward share via CSM will be about 5.62% (2970 keys with 6% Node Operator reward share, and 5506 keys with 3.5% Node Operator reward share).
Taken together, these factors make scaling CSM to a double-digit percentage of the protocol a viable and sustainable possibility.
Also, several things have happened since the initial risk analysis for CSM:
- The initial slashing penalty was reduced (due to EIP-7251) from 1 ETH to 1/128 ETH for 32-ETH validators, increasing the safety coverage of the bonds provided by CSM operators.
- CSM v1 demonstrates a performance of 97.31% effectiveness (according to rated.network), just 0.05% below the network average effectiveness over the last 30 days (as of June 24, 2025).
Given these considerations, the CSM stakeShareLimit is proposed to be increased to 5% upon CSM v2 release. Then, following stake distribution and performance analysis, it will again be considered for an increase to 10% around the end of 2025/early 2026. This share increase is expected to significantly increase Node Operator diversity and further push Lido along the decentralization curve, all while maintaining a robust underlying validator set for both Lido and Ethereum.
ICS Stuff
Now let’s talk about Identified Community Stakers (ICS). To start with, here is a short summary of our current thinking on ICS rollout:
- Prior to CSM v2 mainnet release, an analysis of currently active CSM EA Node Operators (as of July 4, 2025) will be performed by Lido contributors to propose an initial ICS list (see “Conversion of EA Node Operators to ICS Node Operators” section below)
- Prior to CSM v2 release on mainnet, an application process for ICS list inclusion will be opened on the CSM UI (see “New ICS Node Operators” section below). The process will be open to any existing or prospective CSM Node Operators. These applications will not be processed by the Day 1 of CSM v2 mainnet, so eligible applicants will be added to the ICS list later.
- On Day 1 of CSM v2 mainnet, all addresses included in the initial ICS list will be able to claim the ICS Node Operator type.
- After some time since the CSM v2 mainnet release (probably around a month or so), the first update to the ICS list will be proposed by the CSM Committee based on the applications considered.
- After each update to the ICS list, newly added addresses will be eligible to either create a Node Operator with the ICS type or claim the ICS Node Operator type for the existing CSM Node Operator.
Conversion of EA Node Operators to ICS Node Operators
With the introduction of the Identified Community Staker (ICS) Node Operator type and the Identification framework, a reasonable question arises: “Would current Early Adoption (EA) Node Operators be converted into ICS automatically in CSM v2?”
To consider this question, the following observations should be accounted for:
- The initial EA list was compiled using different sources of information, not fully matching the proposed sources for the Community Stakers Identification Framework
- The original Sybil analysis performed for the initial EA list was roughly done, and there are detected cases when several EA Node Operators are controlled by a single person/entity
- Several professional operators were included in the initial EA list and joined CSM
Given that, I propose the following approach to the conversion of EA Node Operators to ICS Node Operators:
- Lido contributors from the CSM and NOM workstreams will perform a detailed analysis of the current CSM EA Node Operators as of July 4, 2025
- For all EA Node Operators for which the analysis indicates a sufficient likelihood that these operators are controlled by a single person/entity, only the first one will be proposed for the addition to the initial ICS list in CSM v2
- Any EA Node Operators controlled by professional entities will not be included in the initial ICS list in CSM v2
- Any EA Node Operators using third-party services like “Validators as a Service” (Allnodes, Stakely, Launchnodes, etc.) or solely SSV delegated operators, or other types of validator operation outsourcing will not be included in the initial ICS list in CSM v2
- EA Node Operators with any validator with performance below the performance threshold for both the most recent and previous Performance Oracle reports (i.e. May and June) will not be included in the initial ICS list in CSM v2 (Note: performance frames are 28 days and don’t line up exactly with calendar months)
- EA Node Operators with zero active and zero depositable keys (inactive) will not be considered for inclusion in the initial ICS list in CSM v2
- Following the filtering methodology described above, the resulting operators will be proposed to be included in the initial ICS list in CSM v2; appeals where an NO may believe that they’ve been incorrectly excluded can be made to the Community Staking Module Committee for possible inclusion in subsequent updates to the ICS list. An appeal should be submitted using CSM Support category on the Lido research forum and follow the template supplied below (“Appendix 1. Initial ICS list inclusion appeal template”). Any Node Operator not included in the initial list can apply for inclusion using the normal path (see “New ICS Node Operators”).
All CSM EA Node Operators will retain their beneficial bond curve ([1.5 ETH, 1.3 ETH, …]) and will automatically be assigned a “Legacy EA” Node Operator type. This type will share all parameters with the “Permissionless” Node Operator type, with the exception of the bond curve, which will be [1.5 ETH, 1.3 ETH, …].
The migration process to the ICS Node Operator type will not be automatic. EA Node Operators eligible for the ICS Node Operator type will be added to the initial ICS list in CSM v2. After the CSM v2 release, all members of the initial ICS list will be able to claim their new ICS Node Operator type using the CSM UI or via direct interactions with CSM smart-contracts, namely a dedicated instance of VettedGate.sol, which will be listed on the Lido docs before the release.
Since the ICS List will be made out of addresses and not Node Operator IDs, the following addresses of the eligible Node Operators will be included in the initial ICS list:
- For Node Operators with
extendedManagerPermissions=false, therewardAddresswill be included - For Node Operators with
extendedManagerPermissions=true, themanagerAddresswill be included
I encourage the community to investigate the proposed conversion plan and share their questions/voice support!
New ICS Node Operators
An application process for the ICS list will be opened sometime before the CSM v2 mainnet release (in a month or so). The applications will be submitted using CSM UI. As soon as Lido contributors and CSM Committee members review the application, users will be able to see the status of their application.
Addresses from the approved applications will be incrementally added to the ICS list. Since the ICS list is stored on-chain in a dedicated instance of VettedGate.sol, it can not be updated in real time. Actual updates are proposed to be made using Easy Track motions. CSM Committee members will periodically post an updated version of the ICS list on the Lido research forum and in IPFS, and will propose the on-chain update of the list via a dedicated Easy Track motion to allow Lido DAO to object to the change should something go wrong with the updated version of the list.
After the ICS list update, all addresses added to the list will be eligible to claim the ICS Node Operator type using the CSM UI, alternative UIs that integrate this functionality, or via direct interactions with CSM smart-contracts.
To enable the described process, a new Easy Track factory that will allow the CSM Committee to update the ICS list is proposed.
ICS FAQs
Here are some frequently asked questions that can help CSM Node Operators navigate the complex topic of Identified Community Stakers.
-
Q: I’m an EA CSM Node Operator. Would I be eligible for the ICS Node Operator type automatically?
A: Some EA Node Operators will be eligible for the ICS Node Operator type from Day 1 of CSM v2. Refer to the section “Conversion of EA Node Operators to ICS Node Operators” to learn more about the proposed eligibility criteria. -
Q: I own an address from the initial EA list, but haven’t joined CSM yet. Would I be automatically eligible for the ICS Node Operator type?
A: No. The initial ICS list will be formed out of EA Node Operators that have already joined CSM and meet the above-mentioned criteria (see Conversion of EA Node Operators to ICS Node Operators). Subsequent updates of the ICS list will be performed based on applications from users. So you will have to submit an application to indicate your intent to join the ICS list. See the section “New ICS Node Operators” for more details. -
Q: I’m a regular (non-EA) CSM Node Operator. How and when can I become eligible for the ICS Node Operator type?
A: Non-EA CSM Node Operators will be able to apply for inclusion in the ICS list sometime before CSM v2 mainnet release. If the CSM Committee approves the application, an address from the application will be included in the next iteration of the ICS list update (sometime after CSM v2 mainnet release). Once the ICS list is updated, the addresses included will become eligible to claim the ICS Node Operator type. See section “New ICS Node Operators” for more details. -
Q: I’m not a CSM Node Operator yet. How and when can I become eligible for the ICS Node Operator type?
A: The Application process for new Node Operators is described in the “New ICS Node Operator” section above.
Appendix 1. Initial ICS list inclusion appeal template
Title: CSM NO #XXX initial ICS list inclusion appeal
Body: I’m the owner of CSM NO #XXX <link to the verified signature on etherscan from manager or reward address>, and I want to appeal the decision to not include my address in the initial ICS list for CSM v2. I confirm that:
- CSM NO #XXX is the only Node Operator owned/controlled/managed by me as a person/entity and I do not own/control/manage other NOs in CSM.
- I run all software myself (CL+EL nodes, and validator client), and I am not using “Validators as a Service” (Allnodes, Stakely, Launchnodes, a friend/relative etc.) for the operation of these validators.
- As a person/entity, I do not act as a professional Node Operator in Ethereum or other ecosystem staking.
(Note: it’s fine if you work for a professional node operator, just that this NO is managed and run as an individual and not in a professional capacity). - CSM NO #XXX has non-zero active and/or depositable validator keys in CSM as of July 4, 2025.
- CSM NO #XXX does not have validators with performance below the performance threshold in the Performance Oracle reports for both May and June.