(Proposal for Community Feedback)
This post outlines a proposal for community and DAO feedback on the high-level design of the Curated Module v2 (CMv2), the next iteration of Lido Core’s main staking module.
TL;DR
As Lido’s Curated Module (CM) continues to secure the vast majority of stETH stake, its next evolution – Curated Module v2 (CMv2) – is being proposed for feedback and DAO approval. CMv2 aims to ensure that Lido Core remains competitive, sustainable, and aligned with Ethereum’s decentralization goals.
The module’s design introduces bond-based security, flexible operator classification, improved incentive alignment, and lower governance friction. It reuses components of the Community Staking Module (CSMv2) to ensure efficiency, while introducing mechanisms that bring Lido closer to a staking marketplace model.
This proposal seeks approval for development, testing, and preparations for further implementation of CMv2.
1. Background and Context
As outlined in the broader post Contributor Thoughts on the Future of Lido Core, Ethereum staking has entered a new era. Professional Node Operators now compete globally, offering low fees, robust infrastructure, and risk coverage. At the same time, new staking designs – from restaking protocols to permissionless pools – are reshaping expectations for efficiency and accountability.
The Lido protocol has evolved in response through its modular architecture, composed of:
-
the Curated Module (CM) – the core, trusted-operator layer;
-
the Community Staking Module (CSM) – for smaller or permissionless operators;
-
and the Simple DVT Module (SDVTM) – advancing Distributed Validator Technology adoption.
Among these, the Curated Module v1 (CMv1) remains the foundation of Lido Core, securing around 92% of the total stETH supply. However, this success also brings responsibility: the module must adapt to maintain competitiveness and continue to embody Lido’s values of decentralization, resilience, and Ethereum alignment.
In addition to the existing module architecture, Lido V3 introduces stVaults – a new, modular staking primitive that allows users and integrators to create their own validator setups while optionally accessing stETH liquidity. Importantly, stVaults do not replace Lido Core – they depend on it. CMv2 therefore remains a foundational part of the Lido protocol even in the V3 architecture: stVaults expand the ways users can stake, but the safety, performance, and decentralization guarantees come from Lido Core in general, and CM in particular.
2. Problem Statement
CMv1 has proven resilient and performant. Yet, its current structure – designed in an earlier staking environment – faces limitations:
-
Static economics. CMv1 enforces a fixed 10% protocol fee split (5% for Node Operators, 5% for the DAO). As external operator costs drop and competitors offer flexible rates or additional coverage, this fixed fee places CMv1 at the upper edge of market cost. In addition, Node Operator fees are set at the module level, a technical limitation that does not allow for different Node Operators within the module to have differing fees.
-
Rigid stake allocation. Stake distribution is not dynamic. It doesn’t account for operator performance, contribution to decentralization, or risk profile – all key differentiators in a maturing validator market.
-
Limited accountability mechanisms. Operator trust is currently mostly reputation-based (i.e. professional operators are expected to perform well, and compensate stakers and the protocol if something goes wrong, and this has worked well up until now). While the reputation-based system has worked well for over five years, it could be improved through the addition of tangible coverage from the side of Node Operators in case of potential losses or slashing events.
-
Governance and operational friction. The current module design requires on-chain votes even for simple administrative changes (e.g., address updates), increasing operational overhead and delaying responses to urgent matters.
-
0x02 readiness and Pectra alignment. Ethereum’s Pectra upgrade introduces a new class of validators with 0x02 withdrawal credentials, tied to EIP-7251. For validators that opt into 0x02, the maximum effective balance increases from 32 ETH to 2048 ETH. For a liquid staking protocol, 0x02 support is not a cosmetic upgrade. The protocol’s routing, accounting, and risk models must understand validators whose balances can move between 32 and 2048 ETH, support top-ups to existing validators instead of only spinning up new ones, and eventually integrate partial withdrawals that can return only a portion of a validator’s balance without a full exit. CMv1 was designed around a world of 32 ETH validators and can only partially adapt to this new model.
These challenges collectively limit adaptability. CMv2 therefore proposes a modernization of incentives and risk mechanisms, building toward a flexible, data-informed, and self-regulating Curated set.
3. Objectives and Guiding Principles
The Curated Module v2 is designed around four guiding principles: sustainability, competitiveness, alignment, and autonomy.
It is proposed that CMv2 aims to:
-
Introduce measurable accountability. Incorporate bonding and penalty frameworks to align operator behavior with staker interests in a more formal way.
-
Differentiate operator types. Reflect the diversity of Node Operators – from public-good teams to large commercial entities – with tailored incentives and expectations.
-
Streamline governance. Reduce operational overhead by allowing self-managed administrative changes, with DAO oversight preserved for critical interventions or overrides of pending actions.
-
Reuse and unify infrastructure. Build CMv2 on the CSMv2 codebase, ensuring efficient maintenance and future compatibility with shared tooling and upgrades.
-
Make the module adaptable to the market. Implement a flexible stake distribution mechanism that reflects performance, cost, and contribution metrics.
4. Delivery Phases
To ensure smooth adoption and avoid operational disruption, the new version of the Curated Module rollout is suggested to proceed in two major releases:
-
Phase 1 | (Q1–Q2 2026): Introduction of core structural upgrades – consolidations, bonding, operator types.
-
Phase 2 | (Q4 2026): Direct deposits, flexible stake distribution mechanism, custom fees, strike system.
5. Path towards streamlining governance
It is proposed that a Curated Module Committee (“CMC”) be established to streamline the governance and operational processes of the Curated Module. The committee’s primary role would be to maintain and administer the module on behalf of the DAO, handling routine operational and technical matters that do not require full on-chain votes, while leaving full control with the DAO through the use of optimistic governance.
In practice, the CMC is expected to operate primarily via Easy Track motions with built-in challenge periods, so that routine actions remain transparent to the DAO and can be vetoed if needed, while day-to-day operational changes do not require full governance votes.
Among its key responsibilities would be:
-
Assessing and onboarding Node Operators during open application rounds;
-
Assigning appropriate Node Operator types;
-
Reporting penalties or incidents related to Node Operator performance or compliance;
-
Overseeing operational integrity and coordinating with other protocol components as needed.
The detailed scope of responsibilities, as well as the committee’s composition, mandate, and accountability mechanisms, will be outlined and submitted to the DAO for approval in a separate proposal.
6. Features Overview | Phase 1
6.1 Node Operator Bond
In CMv1, reputation is the primary guarantee of alignment and reliability. It has been effective, but as the ecosystem matures, reputation alone is insufficient to provide measurable coverage for operational risks.
It is proposed that CMv2 introduce a bonding mechanism to complement, not replace, reputation.
Each Node Operator would provide a bond – denominated in ETH, stETH, or wstETH – to cover operational risks such as slashing, execution layer (EL) reward violations, or significant validators downtime. Bonds will be held as stETH to ensure capital efficiency for operators’ bonded positions.
Importantly, bonds will be associated with operators, not individual validators. This design reduces administrative overhead and mitigates cases where a single validator event could exceed per-validator bond coverage.
This approach mirrors emerging best practices in permissioned staking frameworks while maintaining a lower bond requirement than fully permissionless models, recognizing that Curated Operators have undergone rigorous DAO-vetted onboarding.
Bond sizing, risk calibration, and parameters will be explored in a dedicated follow-up analysis.
6.2 Penalty Framework
To ensure fair enforcement, CMv2 proposes a clear, transparent penalty process governed by DAO oversight mechanisms (e.g., Easy Track motions with challenge periods).
Bond deductions may occur for:
-
Validator slashing: After slashing finalization, the Curated Module Committee reports the penalty amount via Easy Track. The Node Operator’s bond is burned to compensate for losses and missed rewards.
-
EL rewards violations: If an investigation shows that rewards were diverted from Lido’s Execution Layer Rewards Vault, the equivalent amount plus a fixed fine for committing a violation is locked from the operator’s bond. Operators can return funds before penalties are finalized.
-
Operational failures: Other penalization factors may include extended and/or serious downtime, delayed exits, and other violations of protocol rules or expectations.
The inclusion of challenge periods preserves decentralization of oversight while ensuring rapid responses to confirmed misbehavior.
6.3 Support for 0x02 Validators
CMv2 is proposed as the Curated Module’s 0x02-native evolution: it assumes high-balance validators from the start, recalibrates bond and penalty parameters for up to 2048 ETH per validator, and aligns the Curated set with the Lido’s Roadmap to Pectra.
To align with Ethereum protocol changes that aim at reducing the network congestion, CMv2 will support only 0x02 validators. It requires adjusting all penalty amounts under the assumption of a maximum 2048 ETH balance per validator, ensuring compatibility with new validator specifications.
During Phase 1, validators in CMv1 would be migrated to 2048 ETH balance validators in CMv2 via the use of consolidations.
6.4 Node Operator Types
The mechanics of Node Operator types offer a way to categorize Node Operators based on shared properties, characteristics, or unique behaviors. This approach allows for the formation of distinct types, enabling more precise management, targeted incentives, and risk-mitigation mechanisms within the Curated Module.
Node Operators may differ across several dimensions, including but not limited to:
-
Reward structures
-
The processes through which they are onboarded
-
Their risk profiles
-
The underlying technologies they utilize
-
Other relevant operational or technical factors
By segmenting Node Operators in this manner, it becomes possible to optimize performance, enhance protocol security, and ensure deeper alignment with the Ethereum ecosystem.
Sub-operators
Operators may operate multiple sub-operators of different types under a single entity. This flexibility allows the system to more accurately represent the diversity of infrastructure and operational strategies within a single organization, while maintaining clear governance and risk boundaries.
For instance, an operator could hold two types simultaneously – Professional Trusted Operator and Decentralization Operator – if part of their infrastructure is located in underrepresented geographic regions, while the rest of their setup follows the default professional operator configuration. Another example would be an operator who runs a portion of their keys under a DVT setup, qualifying that part as an Intra-Operator DVT Cluster, while the remainder remains under the Professional Trusted Operator type.
Creation of new sub-operators is a permissioned function that is governed by the Curated Module Committee via Easy Track, ensuring transparent management of hybrid setups while supporting operational flexibility.
Types
Based on the current participants of the Curated set and prospective ones, it is proposed to introduce the following list of Node Operator types:
-
Professional Operator – an entity that joined after the CMv2 release (newcomers) and has not yet established a strong record of performance and reliability within the Lido Protocol. It is assumed that new entrants will initially fall into this category after onboarding to CMv2. This type is meant to serve as a “trial” stage in their validation journey within the Curated Module of the protocol. For this type of operator, the lack of an established trust component is balanced by higher bond requirements. A defined set of criteria will allow a Professional Operator to graduate to the Professional Trusted Operator category after the trial phase.
-
Professional Trusted Operator – a for-profit entity that was onboarded to CMv1 and does not fall into any other operator type. This category represents the default type for professional operators who have consistently demonstrated strong performance and reliability, building their reputation as Lido Node Operators over time. It includes both existing CMv1 Operators migrating to CMv2, as well as new Operators who have successfully completed the Professional Operator trial stage. The parameters for this type are considered default and form the operational baseline for Curated Module participants.
-
Public Good Operator – an entity developing, or substantially supporting in a financial manner, an Ethereum Execution or Consensus Layer client, or contributing to the broader public infrastructure of the ecosystem. This type is expected to have an increased reward share, reflecting Lido’s mission to support Ethereum public goods.
-
Decentralization Operator – an entity maintaining its infrastructure in underrepresented geographic regions in terms of Ethereum decentralization, or running unique client and infrastructure combinations. These operators play a key role in geographical and client diversity and may be granted greater performance tolerance to accommodate such setups.
-
Extra Effort Operator – an entity that demonstrates strong alignment with the Lido Protocol through additional contributions — for example, bringing stake via stETH vaults, participating in early testing of new technologies, or operating Lido Oracle infrastructure. This type may be incentivized through an increased rewards share.
-
Multi-Operator DVT Cluster – a distributed validator cluster composed of multiple verified participants that are independent entities. This type may be incentivized for running distributed validator (DV) technologies through increased rewards and decreased bond requirements, given their significantly different risk profile compared to single-entity setups.
-
Intra-Operator DVT Cluster – a distributed validator cluster composed of validators belonging to the same entity. This type may be incentivized for running DV technologies with slightly increased rewards, acknowledging their improved resilience but lower decentralization factor compared to multi-operator clusters.
Proposed Operator Types
Note: As values for the parameters that can be influenced by NO type will only be finalized once work on the module has been mostly finalized and implementation has begun, the below serve as suggested values in relation to the default baseline.
This taxonomy enables the DAO to reward contributions that further decentralization and ecosystem resilience, while managing risks with appropriate bond levels and performance guardrails.
Node Operator types in CMv2 are intended to replace the legacy tiers used in CMv1. These types are scoped specifically to the Curated Module: the tiers and configuration options used for stVaults remain a separate abstraction layer built on top of Lido Core and are not meant to mirror or map one-to-one to CMv2 operator types.
6.5 Rewards Splitter
Building on the proposal for Intra-Operator DVT Guidelines, CMv2 introduces the Rewards Splitter — a mechanism that allows Node Operators to distribute rewards to multiple recipients.
This feature simplifies integrations with DVT infrastructure providers (e.g., Obol, SSV) and enables optional contributions to public goods such as the Protocol Guild.
Only the operator reward portion (see “Rewards Distribution” in Section 8 below for details), not bond rebase rewards, will be subject to splitting. Operators can configure recipient addresses autonomously, reflecting their operational partnerships or contribution preferences.
6.6 Node Operator Address Management
It is proposed that CMv2 allow Node Operators to self-manage their manager and reward addresses directly, reducing governance friction and response latency.
Currently, these changes require full on-chain DAO votes. Under CMv2, such updates would be permissioned to the operator, while the DAO retains the right to override via vote or via an emergency committee in cases of serious security incidents.
This shift significantly reduces administrative overhead while maintaining security and oversight.
6.7 Additional Operator Properties
CMv2 also adds the ability for operators to set their name and description fields. Both can be edited by the operator or the Curated Module Committee, enabling more human-readable, transparent metadata in interfaces and on-chain registries.
7. Features Overview | Phase 2
While the immediate goal is to implement 0x02 support, operator bond, and operator types, it is important to view it as a stepping stone toward the envisioned end-state of the Curated set.
Phase 2 of CM v2 aims to establish a Validator Market (“ValMart”), where stake flows dynamically among operators based on transparent parameters such as fees, performance, and ecosystem contribution. To enable the ValMart functionality, it is required to implement the following features:
7.1 Custom Fee Curves
Node Operators could set nonlinear fee curves, allowing flexible pricing per tranches of ETH staked. This reflects real-world cost structures, enabling fairer competition and efficient stake distribution.
The system would then allocate stake dynamically, balancing DAO-defined decentralization parameters with operator-offered fee levels.
7.2 Strike System
CMv2 Phase 2 envisions a strike-based accountability system, tracking cumulative misbehavior across categories like poor performance, delayed exits, or policy violations.Strikes act as a long-term disincentive, progressively reducing an operator’s stake allocation weight rather than relying solely on immediate penalties, where a sufficient number of strikes over a certain timeframe can also result in ejection from the Curated Module set.
7.3 Additional Bond Reserve
Operators may opt to contribute additional stETH bond voluntarily, boosting their weight in stake allocation. This creates a direct incentive for operators to further secure the assets that are staked via their infrastructure, increasing alignment with stakers.
7.4 LDO Lock and Delegation
Operators could lock LDO tokens and delegate them (or vote themselves) to weigh in on DAO decisions. Active governance engagement would improve their stake allocation weight, encouraging alignment between validator operators and Lido governance.
7.5 Validator Marketetplace (ValMart) Algorithm
Stake distribution in CMv2 after Phase 2 release will be determined by a weighting model considering multiple parameters:
-
Operator fee curve;
-
Node Operator type;
-
Strike count;
-
Additional stETH bond;
-
LDO locked.
Together, these parameters create a dynamic, self-regulating marketplace for validator slots, balancing decentralization, competition, and protocol risk limits.
A key design constraint will ensure maximum stake caps per operator, thereby preserving decentralization.
7.6 Direct Deposits
Certain allowlisted integrations (e.g., DeFi protocols, or institutional products) could deposit directly into a chosen Node Operator’s pool, minting stETH 1:1 without an intermediate vault. This supports B2B integrations and new staking use cases while keeping protocol control. Potential use cases are for protocols that want to specifically deposit to validators using technology like DVT, pre-confirmation sidecars, etc. This mechanism would be limited in capacity on a per Node Operator level, and complementary in nature to stVaults.
8. Operator Lifecycle in CMv2
The CMv2 operator lifecycle is designed for efficiency and clarity:
Onboarding
-
The onboarding process begins with a public announcement that the Curated Module onboarding window is open. During this period, interested Node Operators can submit their applications to join the Curated set.
-
Applications are assessed by the Curated Module Committee.
-
The onboarding of new Node Operators is then initiated via Easy Track motion from the Curated Module Committee.
-
Each approved operator is assigned a Node Operator type based on its profile and contribution characteristics.
-
Once allowlisted, the Node Operator sets its manager and reward addresses, name, and description to complete initial onboarding steps, followed by coordination with Lido DAO Contributors to become active within the Curated Module.
Key Uploading
- Each uploaded key requires a corresponding bond contribution, added to the operator’s bond balance and staked as stETH.
Stake Allocation
-
Phase 1: Allocation follows the MinFirstAllocation algorithm, as in CMv1, but allows custom weights per operator type. This empowers the DAO to prioritize certain operator types (e.g., decentralization operators or client teams) for larger stake allocations.
-
Phase 2: Allocation follows the MinFirstAllocation algorithm, with weights for Node Operators being determined by multiple parameters:
-
Operator fee curve;
-
Node Operator type;
-
Strike count;
-
Additional stETH bond;
-
LDO locked.
-
Rewards Distribution
Node Operators in CMv2 receive two types of rewards:
-
Node Operator rewards: a share of rewards from staker locked stake amount, calculated per active key and distributed in fixed-length frames (7-14 days, configurable), after which they can be claimed by Node Operators.
-
Bond rebase: staking rewards generated from the bonded tokens ((w)stETH) – distributed daily
Rewards Claiming
-
Node Operators claim rewards at their discretion, providing flexibility for accounting, taxation, or fiscal management.
-
Operators can assign a separate claiming address restricted to pulling rewards, minimizing the need to access high-security manager addresses frequently; such an address can be used to create an automated bot that claims rewards whenever there is a balance to claim.
9. Migration from CMv1 to CMv2
Since CMv2 is not just an upgrade of the existing module but a new deployment of smart contracts and supporting tooling, a stake migration process will be required.
The migration will take place through consolidations, ensuring that:
-
Each Node Operator who decides to migrate receives a relative amount of stake equivalent to their allocation in CMv1;
-
The Lido Protocol remains ready to receive stake and deposit validator keys in either CMv1 or CMv2 throughout the migration period;
-
The migration is performed in a way that makes economic sense, with efforts made to minimize costs even though they are expected to be material.
A detailed migration plan from CMv1 to CMv2 will be prepared and shared with Node Operators and the community beforehand for feedback.
10. Conclusion
The Curated Module v2 proposal represents a significant step toward a more flexible, data-driven, and accountable Lido Core.
By combining reputation-based trust with economic alignment, differentiated operator types, and parameter-based stake distribution mechanism, CMv2 strengthens the foundation of Lido’s staking ecosystem.
This proposal seeks community and DAO feedback and approval on the high-level design of CMv2.
). At this time, it’s really hard to constructively argue about the individual mechanics because there are just not enough details known to me. I hope we will soon see some more in-depth descriptions posted here. Once this happens, I’ll happily see if any of my concerns are still open or if I take issues with some.
