• Curated Module v2 Overview
• 📝 Summary
• 🔭 Vision
• 🏷️ Characteristics
• 📜 Status
• 🤝 Node Operators
• 🛠️ Expectations
• ⚖️ Consequences of Non-conformance
• 🤝 Onboarding, Lifecycle & Business Continuity
• 💹 Economics
• 🗃️ Bond
• 🎁 Rewards
• 🥅 Penalties
• ⚙️ Mechanisms
• 🔀 Stake Distribution
• 👥 Node Operator Types & Groups
• 📊 Parameters by Node Operator Type
• 👨‍👨‍👦‍👦 Node Operator Groups
• 🥊 General Delayed Penalty Framework
• 🎛️ Custom Fees (Phase 2)
• ✍️ Committees
• 🛡️ Security & Risk Mitigation
• 📚 Resources
• 🛠️ Guides
• 🖥️ Code and interfaces
• 🎓Tech Talks & Lectures
• 📄 Documentation
• 🛡️ Audits
• 📈 Module Performance & Statistics

Curated Module v2 Overview

🤝 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

1. Node Operators must meet the general expectations of operating as a part of the Lido protocol
2. Node Operators must keep their nodes running and not get slashed
3. Node Operators are expected to follow the SNOPs (Standard Node Operator Protocol):
1. 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.
2. Block ProposalsRewards 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:

1. Operational escalation
1. Issues may be raised publicly and tracked with the community and relevant committees/workstreams.
2. The CMC may recommend or initiate measures to pause or reduce new stake allocation to the operator while issues are investigated.
2. Bond-based penalties (See more below)
1. 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.
2. 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.
3. Offboarding
1. 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.
2. 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 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:

1. Node Operator rewards, paid out of staking rewards associated with the stake they operate and calculated per active key in fixed-length frames, and
2. 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:

1. 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.

2. 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.

3. 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.
4. 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

👥 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, including. 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 were approved by the DAOhave 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.

👨‍👨‍👦‍👦 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 fullbroader Ppenaltyies Fframework can be found here 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 operates 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 wasis 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 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 the protocol 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) (mainnet)
• Deployed Contracts (testnet) (mainnet)

🎓Tech Talks & Lectures

Learn more through the recordings of our public talks and Lido Poolside community calls:

• Future of the Curated Module | Sasha Gusakova | Lido Day 2025
• Fireside Chat | Lido Day 2025
• Curated Module v2 Landscape — Lido Poolside Spotlight
• Sasha Gusakova – Road To CMv2: Status Update | Lido Day Cannes 2026
• Fireside Chat | Lido Day Cannes 2026

📄 Documentation

• Future of the Curated Module | CMv2 Landscape
• CMv2 bond analysis
• Lido Improvement Proposal | CSMv3 and CMv2
• Proposed parameters for CMv2
• Node Operator Type Assessment Framework | CMv2

🛡️ Audits

Contributors maintain the highest security practices with every upgrade undergoing two independent security reviews. The Curated Module v2 is no exception with audits covering smart contracts, governance components, and off-chain infra.

• Certora (audit report)
• Statemind (audit report)

The other audits of the Lido protocol are listed here.

📈 Module Performance & Statistics