The Vote #198 has started! 
The vote will remain open for your “For” or “Against” input until the end of the main phase on January 23 at 11:09 UTC.
For instructions on how to verify the vote items, please follow this guide.
4 Likes
Hello there!
ICS rounds 2 and 3 were completed; the stats for the applications are:
- ICS round 2: 23 approved out of 92 applications
- ICS round 3: 18 approved out of 33 applications
Round 2 data was settled by the Motion #906.
The motion for the ICS round 3 has been started and can be tracked here: Motion #935.
Parameters of the tree to be set:
treeRoot: 0x4bbc2bb2b8db0e6e284de2c5ddc57ffc8deb5f3397f6462646456afeebdf8630
treeCid: bafkreiekobdx27a42ub7m4gcn4d5iu3i3u2iq2cdnceviuznhpotsgpvwa
You can view the full tree on IPFS here:
ICS Tree on IPFS
6 Likes
Dual Governance proposal #8, submitted in Vote #198, has passed and been enacted!
The following on-chain changes have been applied:
- CSM
stakeShareLimithas been set to 7.5% - CSM
priorityExitShareThresholdhas been set to 9%
1 Like
Proposal: Introduce an Identified DVT Cluster type in the Community Staking Module
Summary
This proposal introduces a new Node Operator type in the Community Staking Module (CSM): Identified DVT Cluster (IDVTC). The core idea is to allow clusters of verified, independent community stakers to operate validators together using DVT, with ICS-grade trust assumptions, stronger operational resilience, and incentives aligned with the fact that rewards are split among multiple people.
The proposal adds:
- A new Node Operator type and a corresponding gate into CSM.
- A DVT-specific eligibility composition.
- Off-chain monitoring and a downgrade path if requirements reflected in this proposal are not met
- A parameter set (fees, bond, queues, etc.) for the type.
Background and motivation
The Community Staking Module already enables permissionless participation for anyone who wants to run validators using DVT. Operators can form clusters and run validators collaboratively within CSM today without additional permissions. However, while this model is accessible, it does not yet provide capital efficiency tailored to independent operators who are willing to identify themselves and meet stronger trust assumptions.
The Identified Community Staker (ICS) framework was introduced to address this gap for independent operators. Since its activation in October 2025, more than 200 independent stakers have joined CSM through ICS, demonstrating strong demand from community members who are willing to operate validators under transparent and verifiable conditions.
At the same time, DVT adoption within the Lido protocol has been steadily increasing. As of the end of 2025:
- 100% of the Simple DVT Module (SDVT) validators are operated using DVT.
- Approximately 20% of CSM validators are already running on DVT.
- Around 3.5% of validators in the Curated module use DVT.
In total, this represents roughly ~8% of all validators in the Lido protocol operating with DVT.
These figures show that while DVT has demonstrated clear operational benefits, such as improved resilience and reduced single points of failure, its adoption remains uneven across modules and operator types.
Introducing Identified DVT Clusters (IDVTC) builds on both of these developments. It preserves the permissionless nature of CSM, while creating a more capital-efficient path for independent stakers who are willing to identify themselves and operate validators collaboratively via DVT. This approach combines the trust properties of ICS with the operational resilience of DVT, aligning incentives for small independent operators who share validator rewards within a cluster.
Purpose and goals
Purpose
- Grow the number of independent stakers participating as Lido Node Operators through CSM.
- Accelerate DVT adoption within Lido’s community operator set.
Goals
- Preserve the spirit and safety properties of Identified Community Staker, while unlocking the resilience benefits of DVT.
- Make DVT participation simple, verifiable, and economically attractive (to a practical degree).
- Align economics so that each participant in an Identified DVT cluster has reasonable incentives to run a DVT cluster.
Proposed parameters
The graph above compares the capital multiplier across different CSM node operator types. With the proposed parameters, IDVTC achieve a higher capital multiplier than ICS once the bonded capital exceeds roughly ~2.5 ETH.
This means that operators participating in IDVTC clusters can run more validator stake per unit of bonded capital, making the model more capital-efficient for independent stakers who collaborate through DVT.
This becomes possible by reducing the bond requirement for IDVTC due to significantly lower risks of slashing, downtime, and EL rewards stealing.
DVT incentives for the Community Staking Module are being distributed according to the incentive allocation mechanism, described in this post.
Eligibility and requirements
Cluster composition and proof of independence
- One CSM operator can be a participant in only one IDVTC.
- A DVT cluster must consist of 4 independent participants.
- Each participant must have an approved ICS application (or must be an ICS operator).
- Keys must be generated via DKG with artifacts including:
cluster-lock.jsonfile for Obol clusters.proofs.jsonfile for SSV clusters.
- The cluster formation requires signatures from each member, linking their ICS identity to the cluster.
- The cluster must provide a contact information Lido contributors can use in case of issues with the DKG verification.
- Operators must agree to enrol in monitoring via DVT provider specific tooling (e.g. Obol Grafana metrics, automatic SSV Network metrics).
Obligation to run DVT
- IDVTC operators must run validators using Obol or SSV.
- IDVTC operators must generate the keys via DKG ceremony and provide proof of the output.
- Switching DVT providers is allowed as long as it remains within the approved set and is reported/observable (will require exit-enter procedure).
Downgrade policy
If an IDVTC is detected and reported by the CSM committee as not using DVT (or otherwise failing type requirements):
- The operator’s type is downgraded.
- The operator fee and bond requirements are changed accordingly to a default CSM type, which will likely cause ejection of some of the keys due to them becoming unbonded. CSM Committee can also consider downgrading participants’ ICS type in case such violation is committed.
Replacing a cluster member
Identified DVTCs may replace participants over time (e.g. if someone stops operating), while keeping the cluster within the IDVTC operator type requirements.
If a participant is replaced:
- The new participant must be another ICS-approved participant.
- No participant may be a member of more than one IDVTC at the same time.
- The cluster must submit a new 4-signature cluster statement.
- Monitoring must remain in place for all nodes.
If any of the above requirements are no longer met, the CSM Committee will proceed as described in the Downgrade section by downgrading the operator type, with the fee and bond requirements updated accordingly to the ones corresponding to the default CSM type.
ICS <> IDVTC compatibility
One CSM operator can have only one Node Operator of the ICS type, as well as be a participant in only one IDVTC.
Onboarding flow (UX)
Operators will be able to use a simple UI flow for creating an IDVTC:
- Each participant proves their addresses ownership by signing a standardized message.
- The cluster coordinator creates a cluster and posts four signed messages from all four participants.
- The cluster coordinator provides contact information for the cluster that can be used for coordination with Lido DAO contributors.
- Once the application is ready, the cluster is submitted to CSM Committee assessment, and in case of approval, the cluster address is added to the corresponding CSM gate via Easy Track motion initiated by the CSM Committee.
Managing the bond
Funding, splitting and settling the bond between the participants is entirely up to the cluster.
CSM offers flexibility in how an operator or cluster can configure its Manager and Rewards addresses. For an IDVTC, the configuration choice determines how the cluster will coordinate bond funding, as well as how the cluster will settle rewards between participants over time.
At a high level:
- On-chain: bond is tracked at the operator (cluster) level, not per participant.
- Off-chain: cluster participants must agree how they split contributions, account for top-ups (or adding bond for new keys), and settle when the operator set within the cluster changes or the cluster winds down.
The practical implication is that clusters should pick an address setup that matches their trust assumptions and the level of automation they want for distribution.
IDVTC Type Maintenance
In order to streamline the governance process around the new type, it is proposed that the CSM Committee will be responsible for:
- Adjusting the IDVTC requirements and eligibility criteria
- Creating and executing Easy Tack motions for the IDVTC list to be updated
- Pause or stop application intake and update of the IDVTC list
Tokenholders may at any time vote to rescind or reassign these responsibilities to another group, entity, individual, and may vote to modify, extend, or remove them entirely.
Timelines
It is suggested that the new type be added upon the CSM v3 release, which is expected to arrive in Q2/Q3 2026 together with the CM v2 launch.
12 Likes
Hey Aleksandra! Really glad to see this published. You have full support from Obol.
The part that stands out most to me is what this does for home stakers. Right now you can run a DVT cluster in CSM, but you’re limited to the same requirements as general ICS operators, no additional benefits for the improved security you’re providing. IDVTC changes that. This is DVT being treated as a first-class citizen in CSM.
The reduced bond reflects how much safer it is to use DVT, you get fault tolerance and DKG, and the economics now actually reward that. A reduced bond and increased priority queue make this an obvious win for any identified community staker looking to deploy more keys with better capital efficiency.
What I’m most excited about is what this means for the node operator count on Ethereum. Getting almost 3x the returns compared to solo staking is very attractive. I’m really looking forward to seeing new home stakers come into the ecosystem because of this, we need more independent node operators on the network, and IDVTC provides that carrot.
We’re very supportive of this proposal and we’ll be active through the governance process. Happy to help on the technical and ecosystem side however we can!
7 Likes
Hi,
This looks like a great proposal.
Is this saying a cluster must be exactly four participants, or at least 4?
If it is limited to four, what is the reason for this?
Many Thanks,
5quat.
Hi I am going through the proposal and am looking for clarity on the operator rewards, capital multiplier and Obol / SSV fees.
If I understand there are four cluster participants sharing 3.5% of the overall staking rewards for first 64 keys and 2% of the overall staking rewards for any keys therafter. How are the Obol and SSV network fees handled? Does the capital multiplier graph include the Obol/SSV Incentives which are not guaranteed.
Exactly 4. The reason is that supporting different cluster sizes is hard and self-coordination of large clusters is also hard
The graph does not include DVT fees and incentives due to their volatility
Hey, what you posted is not directly related to CSM itself. Also, I don’t think you understand what CSM is. I would suggest deleting your post in the thread here and please create a new post if you still want to share your proposal.
thx
1 Like
Aleksandra –
Thanks for sharing this idea. I think it advances two important goals for community staking:
1. Lowering the costs of participating, by reducing the bond required for each validator.
2. Encouraging the use of DVT, which increases uptime and resilience for validators
I like the idea of verified community members being able to run DVT nodes for their validators, and for those of their friends. The idea of 4 friends each running a DVT node, and then using those 4 nodes to run their validators is very appealing.
I do have some reservations about how the validator bond is funded and managed. If I’m reading the proposal correctly, the bond is tracked collectively for the entire cluster, and then the participants need to figure out for themselves how to split up the initial pay-in, and how to manage reward payouts. This seems to introduce a lot of uncertainty and requires a high level of trust among the participants.
The simplest solution is that all 4 participants contribute equally to the bond and share equally in the rewards. But in this scenario, what if one or more participants wants to add to their bond later – they can only do so if everyone else contributes equally.
If the participants contribute unequal amounts, the headache grows each time a participant adds or removes bond, as all prior earnings must be paid out, the bond must be paid in or out, and the future bond and earnings splits must be revised.
Because of this complexity, I think this particular structure will only work with a limited number of validators in the cluster, where each participant contributes the same amount, and where the participants do not expect to add or remove funds in the near future. It also works best if the four participants know each other well and have high trust in one another.
-–
A more flexible and simple alternative would be to allow each of the 4 participants to fund their own validators, which would be managed individually and the bond funds would not be commingled. Each participant would have their own rewards payout address, and all their validators would use their payout address. All validators from all 4 participants would be run on the same cluster of 4 Identified Community Operators, and all validators would be generated by a DKG ceremony using those 4 operators.
In order to keep the community-staker-oriented benefits, I would suggest limiting the initial 3.5% node operator reward to the first 16 keys per operator, and reducing it to 2% for the 17th key and beyond. This would be simpler than trying to track 64 keys across 4 operators, and would ensure that all operators get the benefits.
-–
In the future, I might go a step further and suggest that an individual could get these same benefits by using any 3 other verified community DVT node operators, rather than limiting it to the same 4 operators for all their validators.
-–
Overall I like the concept and direction, and I think some tweaks to the structure will make it easier to implement and manage.
-GBeast
Long time no see!
Ethereum keeps evolving, so does Lido. The time has come to reveal the proposal for the next CSM upgrade. Introducing LIP-33. Community Staking Module v3 and Curated Module v2- lido-improvement-proposals/LIPS/lip-33.md at develop · lidofinance/lido-improvement-proposals · GitHub
As the name suggests, CSM is poised to become the foundation for future staking modules in Lido!
The main features of CSM v3 are:
- Support for
0x02validators WC’s (as a separate deployment, current CSM will continue operations with0x01exclusively). - Built-in splitters for Node Operator rewards. A long-awaited feature that makes CSM even more user-friendly, especially for DVT operators.
- Improved and hardened penalty and accounting system that makes Lido protocol even more secure while still maintaining reasonable leeways for the Node Operators.
Community feedback is highly appreciated and welcome!
8 Likes
We looked through and covered it shortly - Website ver. | Twitter ver.
Strongly relate to the architecture, was an awesome suggestion.
Looking forward to the implementation ahead 
… good architecture gets validated in small places first. Just as the Linux kernel started as Linus Torvalds’ personal project before becoming the standard for server infrastructure worldwide, CSM began in the relatively small arena of permissionless staking and has now risen to define the architectural standard for all of Lido. Permissionless environments demand more robust mechanisms by default, because they must be designed for untrusted participants. Bonding, automated penalties, proof-based verification: all of these are natural requirements in such a setting. The fact that code forged in this environment turns out to be a fitting foundation for a permissioned module’s redesign is both intuitive and thought-provoking …
1 Like
CSM’s share of Lido TVL has been steadily increasing since the last change of the stakeShareLimit. Currently sitting at 6.9%, CSM is approaching the limit of 7.5%. Hence, the question pops up: “Should the CSM stake share limit be raised again?”
To answer this question, I suggest considering the following facts:
- CSM is the most decentralized staking module in Lido. Both by the total number of node operators and the maximum stake controlled by the largest operators.
- CSM offers an unpresident protection for stETH holders via its bonding system and automated penalties.
- Despite having slightly lower DAO fee compared to the curated module (~6.09% for CSM as of last CSM Oracle report vs ~6.23% for curated), CSM is expected to see DAO fee increase as more default-type operators get their keys deposited and activated. If we assume all keys from the current CSM queue are active, we can get smth like 6.18-6.2% (see https://dune.com/dgusakov/lido-csm).
Given all that, I believe that raising CSM’s stakeShareLimit from the current 7.5% to 8.5% makes total sense and should allow for the future growth of the permissionless part of the Lido protocol.
Since stakeShareLimit is always changed together with priorityExitShareThreshold, the final set of proposed parameters is:
stakeShareLimit = 850 BPS(8.5%)priorityExitShareThreshold = 1020 BPS(stakeShareLimit * 1.2or 10.2%)
Note: Lido DAO has already approved potential raise of CSM’s stakeShareLimit up to 10% here.
7 Likes
I’m in support of the raising of the share limit to 8.5%. I think it’s a good mix between both increasing the permissionless component of the protocol but also supports that a decent amount of stake flows to the Curated Module now that the protocol is in growth mode again.
3 Likes
Snapshot vote started
Please get your wallets ready to cast a vote 
, the Introduce an Identified DVT Cluster type in the Community Staking Module Snapshot has started! The Snapshots ends on Mon, 13 Apr 2026 16:00:00 GMT.
3 Likes
The on-chain vote #199 is now live and includes the proposal to raise CSM’s stakeShareLimit from the current 7.5% to 8.5% alongside raising priorityExitShareThreshold from 9% to 10.2%.
The vote will be open for your “For” or “Against” input until the end of the main phase: Apr 11, 15:51 UTC.
For instructions on how to verify the vote items, please follow this guide.
2 Likes
Snapshot vote ended
The Introduce an Identified DVT Cluster type in the Community Staking Module Snapshot has reached a quorum and completed successfully!
The results are:
For: 57.7M LDO
Against: 119 LDO
Winning option: For
3 Likes
GM!
ICS round 4 was completed, 12 of 44 total applications were approved.
The motion has been initiated and can be tracked here: Motion #1016.
Parameters for the tree to be set:
treeRoot: 0x80c9f13dbc7b374c34198079de9deda62101b2b89aefa07e474fe0c95a095171
treeCid: bafkreihks67txtnswxd63vqq7pa5m26a34y6pctywfpulhj76wf3m5ofbu
You can view the full tree on IPFS here:
ICS Tree on IPFS
7 Likes
The Dual Governance Proposal #9, submitted through on-chain vote #199, has been executed. CSM’s stakeShareLimit has been set to 8.5%, and priorityExitShareThreshold has been set to 10.2%.
4 Likes