Curated Module v2

Curated Module Overview

📝 Summary

The Curated Module v2 (CMv2) is the proposed successor to the existing Curated Module. It is a permissioned module designed to accommodate a broad set of professional Node Operators under a standardized framework that introduces bond requirements, operator classification, and streamlined governance processes. CMv2 reuses components developed for CSMv2 and adapts them for a permissioned setting, while maintaining compatibility with ongoing changes in Ethereum validator operations (e.g., 0x02 validators, consolidations).

CMv2 is planned to be rolled out in phases:

Phase 1 (Q3 2026)

Operator types
Bonds
Consolidations from CMv1

Phase 2 (Q4 2026)

Direct deposits
ValMart based allocation at the Staking Router level
Expanded use of additional metrics like custom fees, strikes, additional bond and LDO lock as inputs to allocation

CMv2 is intended to support a large portion of stake routed through the Staking Router and to replace CMv1 through a structured migration process once the phased rollout is complete.

🔭 Vision

Curated Module v2 is intended to be the long-term, permissioned staking module of Lido Core, replacing CMv1 while remaining the primary destination for stake allocated to curated Node Operators via the Staking Router. It is designed as a 0x02-native module that supports higher effective balances up to 2048 ETH (EIP-7251) and migration of existing CMv1 validators via consolidations, and it reuses the CSMv2 codebase where appropriate.

Compared to CMv1, CMv2 introduces operator-level bonds, formal Node Operator types, and a penalty framework for bond-backed accountability. A strike-based accountability system is expected to be considered in Phase 2.

Stake allocation and economics are expected to evolve in phases. In the first phase, the Min-First style allocation similar to CMv1 is used, but with configurable weights per Node Operator type. In the second phase, CMv2 is expected to have ValMart, a validator-market mechanism that routes stake across node operators based on cost, penalties, decentralization inputs, risks and Lido governance participation.

🏷️ Characteristics

Operator Onboarding: Permissioned & performed in waves as required, coordinated by the Curated Module Committee (CMC) via Easy Track motions.
Bond Requirement: Yes — proposed Phase 1 bond requirements vary by Node Operator type. Most types use an 11 ETH first-key bond, 0.1 ETH for the next 17 keys, and 0.7 ETH for each subsequent key. Professional Operators use a more conservative 11 ETH first-key bond and 1 ETH for each subsequent key.
Rewards Share: Tiered

90% Stakers
10% Protocol fee, with operator compensation structured by Node Operator type (Phase 1) and custom fees (Phase 2), within DAO-approved constraints.

Distributed Validator Technology (DVT): Supported
Stake Share Limit: No explicit module-level stake share limit; per-operator stake caps and allocation weights are used to maintain decentralization.
Validator Type Support: 0x02 validators, including support for higher effective balances under EIP-7251, with CMv1 0x01 validators migrated via consolidations from CMv1

📜 Status

🟢

Curated Module v2 (Phase 1) is expected to be launched on mainnet in Q3 2026

🟢

Curated Module v2 (Phase 1) is live on Hoodi

🤝 Node Operators

Curated Module v2 consists of professional Node Operators and client teams who run and maintain validators on behalf of stakers. Operators are permissioned and are onboarded in waves. Each CMv2 operator can run one or more sub-operators and is assigned an operator type and has to post an associated bond as part of onboarding.

🛠️ Expectations

Node Operators must meet the general expectations of operating as a part of the Lido protocol
Node Operators must keep their nodes running and not get slashed
Node Operators are expected to follow the SNOPs (Standard Node Operator Protocol):

Exits SNOP

📌

Shortly, Node Operators must exit validators from the CL upon a protocol request (e.g., via VEBO) in a timely manner to avoid restrictive measures and escalation.

Rewards SNOP

📌

Shortly: - feeRecipient must be set to the Lido EL Rewards Vault (testnet, mainnet) - MEV-boost usage is mandatory, although min-bid may be utilized - Only relays from the vetted lists may be used (Hoodi allowlist, mainnet allowlist)

⚖️ Consequences of Non-conformance

If an operator does not follow the SNOPs or CMv2 rules, consequences may include:

Operational escalation

Issues may be raised publicly and tracked with the community and relevant committees/workstreams.
The CMC may recommend or initiate measures to pause or reduce new stake allocation to the operator while issues are investigated.

Bond-based penalties (See more below)

For confirmed incidents such as slashing, EL rewards rerouting, or serious operational failures (e.g., extended downtime, delayed exits), the CMC may propose bond deductions via Easy Track, subject to a challenge period and tokenholder oversight.
A strike-based accountability system (to be introduced in Phase 2) will track repeated misbehaviour (e.g., poor performance, delayed exits, policy violations) and may reduce allocation weight over time and support decisions to offboard the operator if issues persist.

Offboarding

In severe or unresolved cases, the DAO may decide to prioritize exits of the operator’s validators and/or remove the operator from the Curated Module.
these actions are expected to be guided by the penalty framework, any strike record (if introduced), and the relevant SNOPs.

🤝 Onboarding, Lifecycle & Business Continuity

Onboarding to CMv2 begins with a public announcement that an onboarding window is open. Interested operators can then submit applications describing their team, infrastructure, track record and expected operator type.

Applications are assessed by the Curated Module Committee, with input from NOM contributors where needed. The CMC may submit an onboarding proposal to Snapshot, and official onboarding requires DAO approval before execution on-chain via Easy Track. LDO holders can challenge the motion during the objection period. If the DAO approves the onboarding proposal, the CMC can execute onboarding to CMv2 via Easy Track.

Once allow-listed to a certain node operator type, the operator creates a node operator by setting its manager and rewards addresses and configuring name and description metadata. Then, the CMC needs to add this operator to a new operator group that will represent the operator’s entity in the curated set.

Each uploaded validator key requires bond to be uploaded which is added to the operator’s bond balance and staked as stETH.

After keys and bond are in place, stake can be allocated to the operator following CMv2 allocation rules. From that point, the operator is responsible for maintaining validator performance, complying with SNOPs and module rules, and coordinating with contributors on upgrades and migrations.

If an operator needs to wind down or cannot continue operations, it is expected to notify the community via the Research Forum. The operator should coordinate with the CMC and NOM contributors on exits and migration of stake, and must follow the Validator Exits SNOP and exit ordering rules during that process.

💹 Economics

🗃️ Bond

☝

In this document, the term 'bond' has the following meaning: Bond - a security collateral that Node Operators must submit before uploading validator keys into CMv2. This collateral covers possible losses caused by inappropriate actions on the Node Operator's side. Once the validator exits from the Beacon chain and all losses that occurred are covered, the collateral can be claimed or reused to upload new validator keys.

In CMv2, each operator can run one or more sub-operators, and each sub-operator posts an economic bond denominated in ETH, stETH, or wstETH and held as stETH. Bonding is structured as an initial bond plus an incremental bond per additional 0x02 validator. The bond is associated with the sub-operator rather than individual validators. This allows coverage to be applied across incidents while reducing operational overhead and avoiding cases where per-validator bond coverage could be exceeded.

For Phase 1, the proposed bond curve for most Node Operator types is 11 ETH for the first key, 0.1 ETH for the next 17 keys, and 0.7 ETH for each subsequent key. This preserves a high first-key bond for security and slashing coverage while avoiding unnecessary capital inefficiency under the sub-node-operator model. Professional Operators use a more conservative curve of 11 ETH for the first key and 1 ETH for each subsequent key, reflecting their onboarding, probationary, or downgraded status.

For Phase 2, allocation weighting may incorporate voluntary additional stETH bond (bond posted above the minimum) as one of several inputs into an operator’s allocation weight.

🎁 Rewards

In Curated Module v2, staking rewards remain staker-first: the majority of net rewards are expected to continue flowing to stakers via stETH rebases (90%), while the protocol fee (10%) is reserved to compensate Curated Module Node Operators (NOs) and the Lido DAO treasury.

From the Node Operator perspective, CMv2 introduces two explicit reward streams:

Node Operator rewards, paid out of staking rewards associated with the stake they operate and calculated per active key in fixed-length frames, and
Bond rebase rewards, the staking returns accruing on the stETH held as bond and applied daily.

🥅 Penalties

Bond usage is governed by a formal penalty framework. CMv2 adapts the CSM-style bond deduction model for a permissioned operator set and 0x02 validators. Some penalties are automated or balance-based, while others follow a delayed-penalty process with a challenge period. General delayed penalties may be reported by the CMC for confirmed protocol-rule violations, while validator balance shortfalls, delayed exits, and forced-ejection fee reimbursement follow their own reporting and settlement logic.

There are four main CMv2 penalty categories:

General delayed penalty Penalty amount = amount reported + fixed stealing fine

Used for confirmed protocol-rule violations such as EL rewards misdirection, extended underperformance, out-of-order exits, or other penalizable incidents. This penalty follows a delayed-penalty process with a challenge period. The Curated Module Committee may propose the penalty, and the bond deduction becomes effective only after the relevant challenge / settlement process.

Validator balance shortfall after exit and withdrawal Penalty amount = maxObservedValidatorBalance - exitBalance

Applied when a validator exits and its withdrawal balance is lower than the maximum observed validator balance.

The operator has not exited validators in time Penalty amount = exitDelayPenalty Applied when an operator does not process a protocol-requested validator exit within the required validator exit processing window. The proposed required validator exit processing window is 4 days across all operator types. If the operator does not exit the validator in time after a protocol exit request, the delay can be reported. The actual penalty is applied when the validator withdrawal is reported. Proposed exit delay penalties are 0.64 ETH for Professional Operators and 0.32 ETH for other operator types.
Force ejection via EIP-7002 was triggered for the validator Penalty amount = min(actual TW fee paid, maxWithdrawalRequestFee) Applied when a protocol-triggered validator exit via EIP-7002 is required and the ejection was not initiated by the Node Operator. This reimburses the protocol for the Triggerable Withdrawals fee paid to force the validator exit, capped by the DAO-configured maximum withdrawal request fee. This does not apply when the validator exit is initiated by the Node Operator as expected.

For Phase 2, CMv2 aims to introduce a strike-based accountability system, tracking cumulative misbehaviour 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. A sufficient number of strikes over a certain timeframe can also result in ejection from the Curated Module set.

⚙️ Mechanisms

🔀 Stake Distribution

In Phase 1, the Min-First style allocation similar to CMv1 is used, but with configurable weights per Node Operator type. This allows the DAO to systematically favor, for example, decentralization-focused operators or client teams when routing additional stake, while still respecting the “fewest active validators first” rule.

In Phase 2, stake allocation is planned to move toward a “Validator Marketplace” (ValMart) model where allocation weights for each operator will be computed from multiple inputs, including operator’s fee, type, accumulated strike count, any voluntary additional stETH bond, and the amount of LDO locked and delegated by the operator. A per-operator maximum stake cap is preserved as a hard constraint, so the marketplace logic operates within decentralization limits rather than overriding them.

👥 Node Operator Types & Groups

CMv2 introduces Node Operator types to classify operators under a standardized framework so that incentives, constraints, and allocation rules can be applied consistently across different operator profiles. Types are expected to affect Phase 1 configuration such as rewards share, bond requirements, exit-delay fees, penalty fees, and allocation weights.

Operators may run one or more sub-operators, and sub-operators may be assigned different types to reflect distinct operational setups under a single legal or operational entity. This allows, for example, one operator to separate a standard professional setup from a DVT-based setup or another setup with different economic parameters.

The following operator types have been currently proposed for CMv2:

Professional Operator (new entrants / trial stage)
Professional Trusted Operator (baseline for established operators, incl. CMv1 migration and “graduated” Professional Operators)
Public Good Operator (e.g., EL/CL client teams / public infrastructure)
Decentralization Operator (e.g., underrepresented geographies / diversity-focused setups)
Extra Effort Operator (additional protocol value / alignment contributions)
Intra-Operator DVT Cluster (dedicated DVT-based categories)

In Phase 1, operator type is the main primitive used to standardize CMv2 economics and allocation behavior. The proposed type-level parameters are listed in “Proposed CMv2 Parameters by Node Operator Type” below. In Phase 2, operator type is expected to become one input into a broader allocation model, alongside fees, strikes, additional bond, LDO locked or delegated, and other DAO-approved variables.

Type assignment and reassessment are expected to follow a structured assessment process. Professional Operator acts as the initial or restricted state, Professional Trusted Operator acts as the baseline trusted state, and special types such as Public Good, Extra Effort, Decentralization, and DVT-based categories require additional assessment. Reassessments are expected to happen twice a year so that operator classifications can evolve as operator characteristics change.

More details on assessment can be found in the Node Operator Type Assessment Framework.

Parameters by Node Operator Type

For Phase 1 of Curated Module v2, the following Node Operator type parameters have been proposed. These parameters are intended to define the initial fee, bond, exit-delay, penalty, and allocation-weight settings for each CMv2 operator type. Any of these parameters can be changed via a full DAO vote.

Parameter	Professional Operator	Professional Trusted Operator	Public Good Operator	Decentralization Operator	Extra Effort Operator	Intra-Operator DVT Cluster
Fee	2.5%	3.5%	4.0%	4.0%	4.0%	3.5%
Bond	11 ETH for the first key; 1 ETH for each subsequent key	11 ETH for the first key; 0.1 ETH for the next 17 keys; 0.7 ETH flat for each subsequent key	11 ETH for the first key; 0.1 ETH for the next 17 keys; 0.7 ETH flat for each subsequent key	11 ETH for the first key; 0.1 ETH for the next 17 keys; 0.7 ETH flat for each subsequent key	11 ETH for the first key; 0.1 ETH for the next 17 keys; 0.7 ETH flat for each subsequent key	11 ETH for the first key; 0.1 ETH for the next 17 keys; 0.7 ETH flat for each subsequent key
Required Validator Exit Processing Window	4 days	4 days	4 days	4 days	4 days	4 days
Exit Delay Fee, for 0x02 key	0.64 ETH	0.32 ETH	0.32 ETH	0.32 ETH	0.32 ETH	0.32 ETH
Penalty Fee	0.1 ETH	0.05 ETH	0.05 ETH	0.05 ETH	0.05 ETH	0.05 ETH
ValMart Weight	0.5	1	1	1	1	1

Node Operator Groups

CMv2 supports Node Operator Groups to represent a single operator’s setup as a set of sub-node operators and, optionally, related external operators. A Node Operator Group contains a list of sub-node operator records. Each record references a CMv2 nodeOperatorId and a share value in basis points. Shares are used to distribute weight across sub-node operators. This is intended for cases where an operator wants to split allocation between different internal setups. For example: splitting between a DVT setup and a non-DVT setup by assigning different basis point shares.

A Node Operator Group can also include ExternalOperator records. The intention is to account for stake that is active in other modules. The total external stake is computed and then attributed back to the sub-node operators proportionally to their effective weights. This ensures stake allocation reflects both CMv2 stake and referenced external stake at the group level. Group definitions are expected to be managed through the Curated Module Committee. Node Operators and the CMC multisig can edit group values in MetaRegistry.sol.

🥊 General Delayed Penalty Framework

CMv2 has a general delayed penalty mechanism for non-fully-automated protocol-rule violations, such as EL rewards rerouting, extended underperformance, out-of-order exits, or other penalizable incidents. Unlike automated penalties such as exit delay penatly, general delayed penalties are reported by the CMC through a governance-controlled process and include a challenge period before bond deductions are finalized.

To mitigate potential CMC malicious behavior, the actual penalty application (burning of a locked bond) is only available through an Easy Track motion that can be objected to by Lido DAO members over a 72 hour period.

If the penalty is not applied during challenge period the locked bond is automatically unlocked. For CMv2 a bond locked by the CMC remains locked for 60 days, and, if no further action is taken, it gets unlocked.

Node Operator can return the funds back to the Lido protocol to unlock their bond and avoid reset of the benefits. Return of the funds can be performed using the CMv2 Widget.

If Node Operators have objections regarding the locked bond, they can reach out to the Lido DAO members by creating a thread on the Lido Research forum.

The proposed Phase 1 penalty fee is 0.1 ETH for Professional Operators and 0.05 ETH for all other listed Node Operator types. The broader penalties framework is expected to be defined separately.

🎛️ Custom Fees (Phase 2)

As part of the Phase 2 extension, CMv2 is expected to add Custom Fees where instead of having fixed fee and static stake allocation, each operator will be able to define custom fee value for its keys. There will be minimum and maximum available values for the custom fees defined per NO type. It’s also considered that each operator will have a certain number of keys operating at the highest fee possible for this type to minimize the negative effect of the “race to bottom” scenario for Node Operators.

ValMart-style allocation will use fee as one input among several, alongside Node Operator type, strike/penalty signals, additional bond, and LDO locked/delegated.

✍️ Committees

CMv2 is expected to be administered operationally by the Curated Module Committee (CMC), a specialized committee proposed to take over the responsibilities historically handled by the Lido Node Operator Sub-Governance Group (LNOSG) for Curated Module operations. Its role is to handle routine operational workflows through delegated on-chain permissions and Easy Track where applicable, while preserving DAO control over high-impact decisions such as Node Operator set expansion and major parameter changes.

For CMv2, the CMC is expected to be responsible for:

reporting and revoking general delayed penalties, including locking and unlocking Node Operator bond, with settlement overseen through Easy Track;
setting general delayed penalty parameters, such as minimum penalty amounts;
reporting slashing penalties and validator loss amounts via Easy Track;
assigning and reassigning Node Operator types;
creating Node Operator Groups and defining sub-operator shares within each group;
updating Node Operator names and descriptions, where applicable;
pausing creation of new Node Operators for a specific Node Operator type.

Node Operator onboarding remains a DAO-controlled process. The CMC and NOM contributors may open onboarding rounds, review applicants, and submit onboarding proposals, but official CMv2 onboarding is expected to require DAO approval through Snapshot. After approval, onboarding can be executed on-chain via Easy Track.

The CMC is proposed to operate through a dedicated multisig with a 6-of-9 signing threshold, combining Lido contributors from NOM and technical workstreams with transitioned LNOSG members to retain external operator expertise. CMC actions, including Easy Track motions related to penalties, parameter changes, or operator management, are expected to be communicated publicly on the Lido Research Forum.

The LNOSG is proposed to be fully deprecated as part of this transition, with its responsibilities transferred to the CMC. Final authority remains with LDO tokenholders through DAO governance and Dual Governance where applicable.

🛡️ Security & Risk Mitigation

From a staker’s perspective, CMv2 is designed so that funds remain protected by Lido’s non-custodial protocol architecture. Stakers do not transfer assets to Node Operators, committees, or off-chain custodians. Validator deposits, withdrawals, and protocol funds remain controlled by Lido’s Ethereum smart contracts, while Node Operators only operate validator infrastructure on behalf of the protocol.

CMv2 inherits the core protections of Lido on Ethereum: audited and open-source smart contracts, DAO-governed upgrades, public operational processes, monitoring, and protocol-level safeguards such as the withdrawal queue, Accounting Oracle reporting, VEBO exit requests, and bunker mode in extreme scenarios.

CMv2 adds an operator-level bond as an additional security layer. Each operator or sub-operator posts a bond, held as stETH, that can be used to compensate the protocol for operator-caused losses or rule violations, such as slashing, validator balance shortfalls after exit, delayed exits, EL rewards misdirection, or other penalizable incidents. Bond deductions are expected to follow a transparent process, with CMC-administered reporting and Easy Track / challenge-period oversight where applicable.

Risk is further reduced through permissioned operator onboarding, Node Operator types, operator-level allocation weights, per-operator stake caps, and ongoing performance monitoring. These mechanisms are intended to prevent excessive concentration, route stake toward operators with appropriate track records and risk profiles, and allow stake allocation to be reduced or paused where operational issues arise.

Governance protections remain central to the security model. Material changes to the module, operator set, parameters, or core protocol contracts remain subject to Lido DAO governance. In addition, Dual Governance gives stETH holders a veto mechanism over adverse protocol changes, ensuring that stakers have a direct protection layer even where decisions are made through LDO governance.

CMv2 does not eliminate all staking risks. Stakers remain exposed to general Ethereum staking risks, including validator penalties or slashing, smart contract risk, oracle/reporting risk, market and liquidity risk of stETH, and governance risk. However, CMv2 is designed to mitigate these risks through non-custodial fund control, audited contracts, diversified permissioned operators, bond-backed accountability, transparent governance, and stETH holder protections through Dual Governance, which gives stETH holders a veto path against adverse governance actions.

📚 Resources

🛠️ Guides

CMv2 Operators Guide

🖥️ Code and interfaces

CMv2 GitHub
CMv2 Widget (testnet)
Deployed Contracts (testnet)

🎓Tech Talks & Lectures

Learn more through the recordings of our public talks and Node Operator Community Calls (NOCCs):

📄 Documentation

🛡️ Audits

CMv2 audits are pending

📈 Module Performance & Statistics

Mainnet

Not live on mainnet yet

Testnet

Operators Dashboard