Lido CSM v3: From Permissionless Module to Protocol Foundation

Key Takeaways

• Lido's Community Staking Module (CSM) has spent the past 1.5 years since its 2024 launch proving that permissionless staking can work at scale. CSM currently accounts for roughly 7.5% of Lido's total stake, meaningfully contributing to the decentralization of Ethereum's validator set.

• CSM v3, proposed through LIP-33, introduces native support for the 0x02 validators at the heart of Ethereum's Pectra upgrade. It adopts a dual-instance architecture, deploying a new instance separate from the existing one. This allows permissionless participation to grow beyond 15% while keeping the total validator count at or below current levels.

• The CSM v3 codebase also serves as the foundation for Curated Module v2 (CM v2), which manages approximately 90% of Lido's total stake. A module that began as a permissionless experiment has come to define the architecture of the entire protocol, marking a notable turning point in Lido's approach to module design.

1. Lido and Community Staking

Source: Lido

As discussed in a previous article on CM v2, Lido's staking infrastructure is organized under a higher-level structure called the Staking Router. Each module manages its own independent validator set, and new deposits are automatically distributed according to each module's remaining capacity and share limits.

Three modules are currently in operation. The Curated Module is a permissioned module open only to professional node operators who have passed the DAO's vetting process. The Simple DVT Module uses distributed validator technology to run cluster-based setups. And CSM is a permissionless module where anyone can participate by posting a bond.

CSM accounts for only about 7.5% of Lido's total stake, a relatively small share. Yet I believe CSM is the module that will shape Lido's future. The reasons for this will become clear in the second half of this article.

2. How CSM Got Here

2.1 Why CSM Was Created

CSM was Lido's technical answer to longstanding criticism about centralization. In Lido's early days, the Curated Module was the only option, and joining it required passing the DAO's review process. While restricting participation to professional staking organizations offered operational stability, it sat uncomfortably alongside Ethereum's core commitment to decentralization.

CSM addressed this tension through a bonding mechanism. Instead of DAO vetting, node operators post a bond in ETH, stETH, or wstETH, and anyone who does so can run validators. The bond serves as collateral to cover losses in the event of slashing or extended downtime. It is a system that relies on economic alignment rather than trust, an approach consistent with blockchain's foundational principles.

CSM grew quickly after its 2024 mainnet deployment. By Q3 2025, it had already hit its share cap (then 3%), and subsequent upgrades through v2 expanded the cap to 5% and then to 7.5%. As of March 2026, over 550 independent operators are participating in CSM, meaningfully increasing the diversity of Lido's validator set.

2.2 Pectra and the Need for a New Version

CSM v2 introduced important improvements: the Identified Community Staker (ICS) framework, differentiated parameters by operator type, and a priority queue for deposits. But just as v2 was settling in, a change at the Ethereum base layer set the stage for CSM's next evolution.

That change was Ethereum's Pectra upgrade, activated on mainnet in May 2025. Through EIP-7251, Pectra raised the maximum effective balance per validator from 32 ETH to 2,048 ETH. The key to this change is a new withdrawal credential type called 0x02. Validators with 0x02 credentials can stake between 32 and 2,048 ETH, and their rewards auto-compound until the balance reaches 2,048 ETH. Under the old 0x01 system, any balance above 32 ETH was automatically swept out, meaning operators had to create new validators each time they wanted to compound their rewards. CSM v2 was built on the assumption that each validator held exactly 32 ETH. Once that assumption no longer held, a new version became unavoidable.

3. What Changes in CSM v3

LIP-33, recently posted to Lido's governance forum, is the proposal born from this context. It introduces both CSM v3 and Curated Module v2 (CM v2) as a single package. Since CM v2 has been covered in a previous article, this piece focuses on CSM v3.

3.1 Native Support for 0x02 Validators

The most significant change in CSM v3 is native support for 0x02 validators. Rather than simply adding compatibility with 0x02, the entire module has been designed around how 0x02 validators actually work.

Deposits for 0x02 validators happen in two phases. First, an initial 32 ETH deposit is made and a validator index is assigned. Then, top-ups bring the balance up to a maximum of 2,048 ETH. CSM v3 handles this two-phase flow at the protocol level. The order of initial deposits is recorded and then used to determine the sequence for top-up allocations. Top-up limits are verified through consensus layer proofs, preventing double-processing of deposits that have not yet been reflected on the consensus layer.

3.2 Dual-Instance Architecture

Supporting 0x02 does not mean the existing 0x01 validators can simply be replaced overnight. Rather than supporting both types within a single module, CSM v3 separates them into distinct instances. The existing CSM instance is upgraded to v3 but continues to support only 0x01 validators. A new, separate CSM v3 instance is deployed for 0x02 validators.

Why this approach?

The accounting models for 0x01 and 0x02 validators are fundamentally different. 0x01 is unit-based (1 validator = 32 ETH), while 0x02 is balance-based (anywhere from 32 to 2,048 ETH). Running both accounting models within a single instance would significantly increase complexity and widen the scope of security audits. Lido's solution is to keep each instance focused on a single credential type, preserving simplicity and safety.

Existing CSM operators who want to migrate to 0x02 must exit their validators from the current instance and create new ones in the 0x02 instance. To encourage this transition, the 0x02 instance will introduce a special operator type for existing ICS operators, offering deposit-priority boosts and better economic terms. LIP-33 estimates that roughly 80% of existing 0x01 validators will migrate to 0x02 within a few years, potentially even months. If that happens, the number of permissionless validators would drop by approximately 90%, while the total permissionless stake would stay the same or even grow.

Paradoxically, this reduction in validator count is what makes expanding permissionless participation possible. LIP-33 projects that the permissionless share can grow from the current 7.5% to 15% or more. Previously, each validator could only be assigned 32 ETH, so increasing the permissionless share meant adding proportionally more validators, placing additional load on the network. Under 0x02, a single validator can handle up to 2,048 ETH, so the same amount of stake can be covered with far fewer validators. This creates room to grow permissionless participation, and it aligns with Ethereum's broader direction of reducing network congestion through validator consolidation.

3.3 Overhauling the Penalty and Reward System

As the participation structure expands, the incentive system supporting it needs to keep pace. CSM v3 redesigns both the penalty and reward frameworks to accommodate the variable balances of 0x02 validators.

3.3.1 Changes to Penalty Calculation

Under the old system, penalty calculations were straightforward because every validator held a fixed 32 ETH. Now, penalties must be computed relative to the actual withdrawal balance. Both delayed-exit penalties and poor-performance penalties are adjusted in proportion to the validator's real balance. CSM v3 also separates the withdrawal reporting flows for slashed and non-slashed validators. For slashed validators, the slashing must first be proven, after which the exact penalty amount and withdrawal balance are reported through a dedicated Easy Track motion.

3.3.2 Structuring Exit-Related Penalties

CSM has operated a penalty framework for validator exits since v2. When the Validator Exit Bus Oracle (VEBO) requests a specific validator to exit, the node operator must comply within a timeframe set for their operator type. Validators that exceed this window are flagged as "stuck." Exit-related penalties fall into three categories:

• Delayed Exit Penalty: A charge for failing to exit on time.

• Bad Performance Ejection Penalty: Applied when a validator is forcibly ejected due to accumulated strikes.

• Triggerable Exit (TE) Fee: The cost incurred when a forced exit is executed via EIP-7002.

What changes in CSM v3 is how these penalties are calculated and applied. All exit-related penalties are now adjusted in proportion to the validator's actual withdrawal balance, reflecting the variable balances of 0x02 validators. These penalties are managed within the newly introduced ExitPenalties.sol contract and are not deducted immediately when recorded. Instead, they are applied in a batch when the validator actually withdraws. During the withdrawal reporting process, the system checks whether the validator has any delayed-exit or poor-performance records and, if so, deducts the recorded penalties and TE fees from the bond.

3.3.3 Improvements to Reward Distribution and Claiming

CSM v3 overhauls the reward distribution and claiming process alongside the penalty framework. The existing reward flow in CSM works as follows:

1. Each time Ethereum's AccountingOracle reports, the StakingRouter mints rewards allocated to CSM and transfers them to FeeDistributor.sol.

2. The CSM Performance Oracle computes a reward distribution Merkle tree based on each operator's consensus layer performance, and once oracle members reach consensus, the tree root is submitted to FeeDistributor.sol.

3. Operators submit a Merkle proof to claim their rewards.

CSM v3 introduces three practical improvements to this process.

First, a new pullFeeRewards method allows operators to route rewards directly into their bond instead of withdrawing them to an external address. This is particularly useful for automatically replenishing a bond that has been reduced by slashing or penalties.

Second, operators can now specify a custom address when claiming rewards, adding flexibility to reward management.

Third, a built-in fee-splitting feature (FeeSplits) has been introduced. This enables automatic distribution of a portion of staking rewards to infrastructure providers like Obol or SSV, with support for up to 10 fee-split recipients. The feature can also be used for voluntary donations to public goods funding services such as Protocol Guild. Combined, these improvements allow infrastructure provider fees, public goods contributions, and bond replenishment to all be handled within a single transaction flow.

3.4 Additional Technical Improvements

Beyond the changes discussed above, LIP-33 includes several further technical improvements.

• General Delayed Penalty Mechanism: Through CSM v2, the off-chain penalty framework was limited to execution layer reward theft. CSM v3 extends this into a more general-purpose framework. When an off-chain violation is reported, the bond is locked, followed by a dispute period and confirmation through an Easy Track vote. A new bond debt record mechanism has also been added: if the bond is insufficient to cover a penalty, a debt record is created and automatically deducted when the bond is later replenished.

• Parameters Registry: The operator-type parameter management introduced in CSM v2 now includes more granular role-based access controls (RBAC), allowing management permissions to be separated by parameter group. The voluntary validator ejection mechanism has also been optimized, streamlining the exit process through EIP-7002.

4. CSM as Lido's Operating System

LIP-33's scope includes not only CSM v3 but also CM v2. And CM v2 is built on the CSM v3 codebase.

This is the aspect of the proposal I find most noteworthy.

The Curated Module manages roughly 90% of Lido's total stake, making it the protocol's core module. CSM, by contrast, handles about 7.5%, a comparatively small share. Yet the smaller module's code became the foundation for the larger module's redesign. This runs counter to what you might expect.

The reason this reversal was possible is that CSM was the first module in Lido to validate key concepts of modern staking module design in production: bonding mechanisms, automated performance management, and differentiated operator types. The Curated Module, meanwhile, had remained largely unchanged since the Lido v2 release. Its reputation-only accountability model (no bonds), its accounting built around fixed 32-ETH validators, and its rigid fee structure applying the same rate to every operator were all carried over from an earlier era. While CSM spent 1.5 years testing and proving bonding, performance-based penalties, and type-differentiated parameters in a permissionless environment, the Curated Module stood still.

When the time came to redesign the Curated Module, it turned out to be more practical to take the architecture already proven in CSM and extend it, rather than building from scratch. In technical terms, CM v2's core contract, CuratedModule.sol, inherits from BaseModule.sol, which contains all the logic shared with CSM, and adds curated-module-specific features on top. Most supporting contracts are deployed as independent instances of the same code used in CSM v3.

CM v2 does introduce its own unique capabilities. A Meta Registry allows a single operator to run multiple sub-operators of different types. A greedy weighted allocation algorithm replaces the FIFO queue for stake distribution. And the groundwork is laid for a future Validation Market. But all of these sit on top of the codebase that CSM built.

This reminds me of an old lesson from software engineering: 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.

5. Security Considerations

LIP-33 also acknowledges that introducing 0x02 validators brings new security considerations, and discusses possible attack scenarios along with their mitigations. This section briefly covers each scenario presented in the proposal.

5.1 Exploiting the Timing Mismatch Between Top-ups and Withdrawals

If a top-up is sent to a validator but has not yet been reflected on the consensus layer when the validator exits, the top-up amount may later be applied on the CL and withdrawn separately. In that case, the withdrawal could be mistaken for a normal validator withdrawal, causing the node operator's bond to be unfairly penalized. Conversely, if the validator should have been penalized but the top-up amount offsets the shortfall, it is the protocol that takes the loss.

Lido minimizes this risk through a parameter called MIN_WITHDRAWAL_RATIO. For CSM v3's 0x02 instance, this value is set at 1%, corresponding to roughly six months of continuous offline time. CSM's performance strike system ensures automatic ejection after approximately three months of sustained poor performance, so a validator remaining offline for six months or longer is highly unlikely. Operators are also advised to run their own prover bots to report validator withdrawals in a timely manner.

5.2 Premature Dequeueing from the Top-up Queue

In CSM v3, top-ups for 0x02 validators work as follows: the Depositor Bot calculates each validator's top-up limit based on consensus layer proofs and passes this information to the module via the Staking Router.

The risk is that a bug in the Depositor Bot could cause it to over-report pending deposits for a given validator. If this happens, CSM would conclude that the validator has already been fully deposited to 2,048 ETH and remove it from the top-up queue prematurely. The result is a validator that falls short of its intended balance with no path back into the top-up queue.

LIP-33 considers this scenario unlikely but has prepared a mitigation mechanism. The CSMC (CSM Committee) holds the authority to roll back the top-up queue's head pointer to the position of a key that was not fully topped up. After the rollback, the corrected Depositor Bot delivers accurate information, and keys that have already been fully deposited are automatically skipped because their CL-proof-derived top-up limits come back as zero.

5.3 GateSeal: The Last Line of Defense

CSM v3 retains the existing GateSeal mechanism as a last line of defense against zero-day vulnerabilities. GateSeal is a one-time emergency pause contract used across the Lido protocol, allowing a designated security committee to immediately pause critical contracts when a severe vulnerability is discovered. Once triggered, a GateSeal is consumed and cannot be reused; resuming operations requires a separate authorization. This design prevents the emergency mechanism from being abused while still enabling immediate response in a genuine crisis, without waiting for a governance vote.

6. Closing Thoughts

I see the CSM v3 upgrade proposal as carrying significance on two levels.

The first is its meaning for the Ethereum ecosystem at large. For Pectra's 0x02 validators to deliver on their promise of improved network efficiency, staking protocols need to actually adopt them. Lido is the largest staking protocol, accounting for roughly 23% of all Ethereum staking, and through CSM v3 and CM v2, it is rolling out 0x02 across both its permissionless and curated modules. This will serve as a catalyst for raising 0x02 adoption across Ethereum as a whole.

The second is the architectural evolution within the Lido protocol itself. CSM started as a permissionless experiment, but the codebase it proved over 1.5 years of operation is now becoming the foundation for all of Lido's architecture. This is more than code reuse. It signals a shift in Lido's design philosophy: validate in a permissionless environment first, then apply the proven mechanisms to permissioned contexts as well.

The last point I want to highlight is that CSM's evolution offers a compelling perspective on the cost of decentralization. Permissionless participation requires more sophisticated mechanisms: bonding, automated penalties, proof-based verification. These add complexity to design and operations. But the CSM story shows that this added complexity ultimately feeds back into the robustness of the entire protocol. Decentralization is not merely a cost. It is also an investment.