Community Staking Module

Proposals
208

IDVTC additional params

The original IDVTC forum post and Snapshot vote cover 4 parameters for the proposed IDVTC type. Namely:

  • RewardShare - 3.5% for the first 64 keys, and 2% for the remaining keys.
  • Bond - 1.5 ETH for the first key, and 0.5 ETH for the remaining keys.
  • PriorityQueue - 40 priority seats with priority lower than ICS but above the default one.
  • Strikes - Threshold 2, Lifetime 4 frames.

However, we still need to define more parameters. Below are the proposed parameters.

  • keyRemovalCharge = 0.01 ETH. Same as for ICS.
  • generalDelayedPenaltyAdditionalFine = 0.05 ETH. Same as for ICS.
  • keysLimit = Unlimited. Same as for ICS and Default type.
  • allowedExitDelay = 5 days. Same as for ICS.
  • exitDelayFee = 0.05 ETH. Same as for ICS.
  • maxElWithdrawalRequestFee = 0.1 ETH. Same as for ICS and Default type.
  • avgPerfLeewayBP = 300. Same as for the Default type.
  • attestationsWeight = 54. Same as for the Default type.
  • blocksWeight = 8. Same as for the Default type.
  • syncWeight = 2. Same as for the Default type.

Additionally, it is proposed to change the Strikes params to Threshold 3, Lifetime 6 frames, same as for the Default type. Also, it is proposed to set badPerformancePenalty = 0.258 ETH, same as for the Default type.

The main motivation for changing these parameters is to avoid the situation where, after receiving 1 strike, the rational operator should exit the validators to avoid the badPerformancePenalty. Since 1 strike can result from an MEV relay issue that causes 1 missed block proposal, the 2-strikes threshold puts Node Operators in an uncomfortable position.

The initial reasoning behind choosing a threshold of 2 strikes was to ensure that, in the worst-case scenario (offline till the threshold and slashing after that), the bond is sufficient to cover penalties.

From a protocol security perspective, we can assume that IDVTC Node Operators will not attack the protocol by keeping their validators offline for the full 3 frames, then slashing them right after. Hence, the biggest expected penalty in case of 3 offline months is 0.428 ETH, which is below the bond of 0.5 ETH.

5 Likes
209

Staking Module Share Limit ET Params

As part of the upcoming CSMv3 release, a new EasyTrack (ET) factory UpdateStakingModuleShareLimits.sol will be added. This factory will facilitate management of the stakeShareLimit and priorityExitThreshold parameters for CSM by allowing a dedicated committee (CSMC) to propose minor changes to stakeShareLimit and priorityExitThreshold via ET motions within a predefined limit.

It is proposed to set the following values for the limits in UpdateStakingModuleShareLimits.sol:

  • maxStakeShareLimitIncrease = 500 BP
  • maxStakeShareLimitDecrease = 500 BP
  • maxPriorityExitShareThresholdIncrease = 600 BP
  • maxPriorityExitShareThresholdDecrease = 600 BP

These values ensure that a single ET motion cannot change the module’s stakeShareLimit by more than 0.5% in either direction (increase or decrease). The priorityExitThreshold is typically set to stakeShareLimit * 1.2 to ensure a buffer against protocol TVL fluctuations. Hence, the proposed limits for priorityExitThreshold are 20% wider than those for stakeShareLimit.

4 Likes
210

In light of the upcoming Staking Router v3 (SRv3) and Community Staking Module v3 (CSMv3) releases, a few Easy Track (ET) factories should be updated and created. Below is a short description of each.

New ET factories

ReportWithdrawalsForSlashedValidators.sol

In previous versions of CSM, slashing penalties were calculated automatically as the difference between the slashed validator’s withdrawal balance and 32 ETH. With the introduction of 0x02 validators with variable balances ranging from 32 to 2048 ETH, this approach is no longer applicable. Additionally, the previous approach was unable to account for rewards missed during the slashing period. Hence, an ET factory is introduced to produce motions that deliver precise information on total slashing penalties. Corresponding flow is described in the LIP-33.

This factory will be used for both CSMv3 and CMv2.

SetMerkleGateTree.sol

This factory is a generalized version of the existing CSMSetVettedGateTree.sol. This factory produces motions that update the list of addresses allowed to pass through the gate (create a Node Operator). While the original factory was able to serve a single gate, the updated version allows for a single factory to serve multiple gates in the scope of a single module, and supports both VettedGate.sol for CSM and CuratedGate.sol for CMv2.

This factory will be used for both CSMv3 and CMv2.

SettleGeneralDelayedPenalty.sol

This factory is an updated version of the existing CSMSettleELStealingPenalty.sol. The factory produces motions that settle (confirm) a penalty that was previously reported by the module committee. Settling means that the locked bond (as a result of the report) is burned. The updated version now supports both CSM and CMv2, and the updated interface for the GeneralDelayedPenalty.

This factory will be used for both CSMv3 and CMv2.

UpdateStakingModuleShareLimits.sol

Lido contributors use a staged approach to rollouts and further expansion of the essential parts of the protocol. While the Curated module has always been a core part of the Lido protocol and will be replaced entirely by CMv2, modules like CSM require frequent, gradual changes to stakeShareLimit and priorityExitShareThreshold. This factory is designed to facilitate the process. A detailed description of the factory can be found in the SRv3 spec.

This factory will be used for CSMv3. There are no plans to use this factory for CMv2 at this time.

Updated stakeShareLimit boundary for CSM

With the introduction of a dedicated ET factory to manage stakeShareLimits for CSM, it’s proposed to set the new upper bound for the existing CSM instance’s stakeShareLimit of 15% of the Lido protocol TVL. This limit will not be enforced on-chain. Instead, the CSMC will be responsible for ensuring that the CSM’s stakeShareLimit, as managed via Easy Track, does not exceed the agreed threshold, if approved.

3 Likes
211

image
image1754×1240 151 KB

8 Likes
212

ICS + IDVTC Assessment Rounds 2026 Calendar

Background

CSM v2 debuted Node Operator Types last year, introducing Identified Community Stakers (ICS), a dedicated operator type with benefits that home stakers can apply for.

Since then, four ICS assessment rounds have taken place, with timing adjusted based on demand rather than a fixed calendar.

With CSM continuing to grow (now over 8% of Lido’s stake) and Identified DVT Clusters (IDVTC), which requires cluster members to have ICS, set to arrive this summer, there’s a clear need for a predictable cadence that applicants can plan around.

Assessment cadence

Going forward, ICS and IDVTC assessment rounds will follow a quarterly schedule, broadly consistent with the cadence used so far.

ICS rounds will take place first, followed by IDVTC rounds two weeks later, giving applicants and cluster members a clearer path to plan around both processes.

2026 assessment calendar

The assessment calendar for the rest of 2026 is expected to be:

Round Cutoff date
ICS Round 5 June 8
IDVTC Round 1 June 22
ICS Round 6 September 7
IDVTC Round 2 September 21
ICS Round 7 December 7
IDVTC Round 3 December 21

These dates should be understood as assessment cutoffs. There will be a delay between each cutoff and when applicants will be able to claim as applications are reviewed by the CSM Committee, and enactment requires an Easy Track motion first.

Any changes to the exact dates will be communicated in advance.

5 Likes
213

As we want to explore and integrate different modules, this has been def needed! Thanks for the clarity :slight_smile:

2 Likes
215

Hey, your post is irrelevant to the thread. I will delete it and I think now you can post

216

Hi, I’m evaluating Lido as an ETH staking option and this CSM proposal is one of the most important parts of my research.

From what I understand, the main goal of CSM is to reduce Lido’s centralization risk by allowing more independent and community based node operators to join, instead of relying mostly on the curated operator set.

My question is: after CSM is live and growing, what would be the best metrics to track in order to know whether it is actually improving decentralization?

For example, should users mainly look at the number of independent node operators, the percentage of Lido stake allocated to CSM, validator performance, or something else?

217

The first two metrics you mentioned are the most straightforwarding indication. Also, it is worth noting that CSM is the largest permissionless staking solution in the ecosystem by TVL. Also, the speed (~1.5 yrs) with which CSM achieved this level of allocation within Lido is a strong indicator of the protocol’s efforts toward operator/validator diversification and greater decentralization.

3 Likes
218

In light of the upcoming release of CMv2, Lido contributors have compiled all the parameters and key values to be used.

IPFS - https://ipfs.io/ipfs/bafybeibhlw3e6zy6xkbdmusky5i5v5rwcpxnjqws23jpmszzkp5xwzzppe

Most of the parameters were already posted in this thread or used for the previous releases. Still, we recommend reviewing the file and requesting clarifications, as this set of parameters is planned for use in the CMv2 release.

EDIT: IPFS link updated to include recent params.
Changed

- maxDepositsPerBlock = 150 // Up to 150 32 ETH initial deposits per single deposit TX
- minDepositBlockDistance = 25 // Minimal block distance between deposit TXs
+ maxDepositsPerBlock = 100 // Up to 100 32 ETH initial deposits per single deposit TX
+ minDepositBlockDistance = 75 // Minimal block distance between deposit TXs

...

#### Professional Operator

metaRegistryBondCurveWeight = 50000 // 0.5 of default 100_000
+ keysLimit = 80

to reflect the most recent security considerations from the analytical recearch.

4 Likes
219

Hey everyone,

I was an operator in ether fi’s DVT stakers program, and that was what got me to start validating on Ethereum. Before that, I’d been running a full node and experimenting with other chains, but ether. fi gave me the push to actually participate in Ethereum validation, running it on a DAppNode.

Unfortunately the program is now fully wound down, and I’m looking for a way to keep contributing to the network as an individual operator.

I wanted to raise the idea of recognizing ether. fi DVT Cluster participants in the ICS assessment process, giving us some weight or points based on that prior operator experience. A lot of us are solo home stakers who built real skills running validators, and I think it would be great if that track record counted toward something in CSM.

I’d love to keep validating Ethereum and contributing to the network. Happy to chat or see if the other operators want to express support for this as well.

5 Likes
220

Hey @iamnicki15, thanks for raising this! The very reason CSM and ICS were born was to make it as reasonable as possible to participate in the network, especially for independent stakers.

IMO it makes sense to add any credible source of experienced home stakers in Ethereum to the ICS assesment.

I will have a closer look at this and bring this up to the CSM Committee, I’ll come back with any feedback or decision about this.

3 Likes
221

Snapshot vote started

The LIP-33: CMv2 and CSMv3 Architecture, Key Parameters, Rollout Plan Snapshot has started! Please cast your votes before Mon, 22 Jun 2026 16:00:00 GMT

3 Likes