TL;DR
This proposal focuses on how Node Operators qualify for CMv2 Node Operator Types, rather than on the specific values for the parameters assessed.
- The Phase 1 CMv2 parameters by Node Operator type are proposed separately; this document explains the qualification mechanics, requested data, assessment logic, and reassessment flow.
- Professional Operator remains the onboarding / trial / downgraded stage, while Professional Trusted Operator remains the default trusted state for established operators or successful graduates from the trial stage.
- Public Good and Extra Effort are assessed through operator applications, while Decentralization Operator is assessed through a score-based methodology using VaNOM data and has a limited number of seats.
- Reassessments are proposed to happen twice a year. For the special types, the proposed assessment order is Public Good → Extra Effort → Decentralization.
- Assessment outcomes are intended to be shared on the forum in aggregated form, while raw operator submissions and raw VaNOM data are not intended to be published.
Purpose
This framework is intended to increase transparency and consistency in how Node Operators are assessed and how Node Operator Types are assigned in Curated Module v2 (CMv2). It proposes a common qualification framework so that type assignments can be explained, replicated, and audited over time.
While the Phase 1 CMv2 parameters by Node Operator type have already been proposed separately, an equally important question remains: how do Node Operators qualify for those types in practice? This proposal addresses that question by defining the requested data, assessment logic, scoring methodology, and reassessment flow for assigning Node Operator Types within CMv2.
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. It may also serve as a fallback type for operators that are downgraded from another Node Operator Type following a significant incident or reassessment outcome showing that they no longer meet that type’s requirements.
- Professional Trusted Operator – a for-profit entity that was onboarded to CMv1/graduated Professional Operators 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.
- Public Good Operator – an entity developing or substantially supporting in a financial manner an Ethereum Execution, Consensus Layer or validator client.
- Extra Effort Operator – an entity that demonstrates strong alignment with the Lido Protocol through additional contributions: bringing stake via stVaults or Lido Core, has ability to participate in Lido DAO governance by holding its governance token (LDO).
- Decentralization Operator – an entity maintaining its infrastructure in underrepresented geographic regions in terms of Ethereum decentralization, or running diverse and decentralized client and infrastructure setups.
- Intra-Operator DVT Cluster – a distributed validator cluster composed of cluster members belonging to the same entity.
Professional Operator Type Assessment
The Professional Operator type is the entry tier of the Curated Module v2 and is designed as a trial stage for newly onboarded Node Operators. It applies to NO’s joining the Curated Module after the CMv2 release that have not yet established a performance and reliability track record within the Lido Protocol.
New Professional Operators are onboarded through onboarding rounds, which are proposed when the Curated Module Committee (CMC), together with contributors from the Node Operator Mechanisms (NOM) workstream, determine that protocol conditions and DAO strategy justify expanding the curated operator set.
Data Requested During Onboarding Rounds
Node Operators applying during an onboarding round will be required to submit structured information covering the 5 following areas:
- General Entity Information: Basic information about the applying company, including legal entity name, jurisdiction, headquarters address, and primary contact details.
- Experience & Business Case: Evidence of prior staking experience, validator fleet size, assets staked historically, duration of operations, performance track record, any slashing history, clients served, and the strategic rationale to the protocol for joining the Curated Module.
- Infrastructure Setup: A detailed description of their validator architecture, including server type (bare metal/cloud), hosting providers and locations, redundancy and standby setup, overall failover design, EL and CL client choices, validator client and signer configuration, EL connection type (one to one or multiplexer), PBS setup, and relay configuration.
- Key Generation & Key Management: Explanation of key generation procedures, custody model, storage setup, access controls, backup and recovery processes, and whether signing infrastructure is hosted on bare metal or cloud environments.
- Operations & Monitoring: Description of monitoring and alerting systems, on-call rotation and incident response processes, security practices, audits or certifications (if any), performance tracking methodology, and general operational maturity.
Once all required data is gathered during an onboarding round, the CMC conducts a structured assessment of each applicant. The purpose of this assessment is to evaluate whether the Node Operator meets the risk, operational, and decentralization standards expected for entry into the Curated Module under the Professional Operator category.
The assessment is multi-dimensional and score-based. CMC members independently review the submitted materials and assign a score to a defined set of categories. The final list of the Node Operators to get onboarded is proposed to the DAO via Snapshot.
| Category | What is Assessed |
|---|---|
| Key Generation & Key Security Management | Security of key creation process, ceremony controls, isolation, documented procedures, custody model, signer setup, access controls, backups, recovery procedures |
| Infrastructure Architecture | Redundancy, failover design, client diversity, hosting model, avoidance of single points of failure |
| Decentralization Contribution | Geographic, jurisdictional and provider diversity; marginal impact on stake concentration |
| Strategic / Business Case Alignment | How onboarding the Node Operator supports the Lido ecosystem, e.g. increasing stake within the protocol, improving stETH trading liquidity, building products based on stETH, etc. |
| Operational Experience & Performance | Validator fleet size, duration of operation, historical performance, slashing history |
| Monitoring & Incident Response | Monitoring stack, alerting quality, on-call rotation, incident playbooks, responsiveness |
| Security Posture | Audits, insurance (if any), bug bounty participation, general security maturity |
Exceptional Onboarding Cases
While onboarding rounds represent the standard mechanism for admitting new Professional Operators, there may be exceptional situations in which the CMC determines that proposing the onboarding of a specific operator or a small number of operators is beneficial even when there is no immediate need to materially expand the Node Operator set.
In such cases, the CMC may submit a proposal to the DAO if the candidate demonstrates a particularly strong strategic or ecosystem-aligned business case for inclusion in the Curated Module. Examples may include situations where onboarding the operator enables meaningful collaboration with an important ecosystem participant, strengthens Lido’s presence within a relevant network segment, or otherwise advances the protocol’s strategic objectives. Any such proposal would still be accompanied by a full assessment of the operator’s technical, operational, and risk profile consistent with the Professional Operator evaluation framework.
In all cases, the DAO is the final arbiter of operator inclusion into the Curated Module, and any person or entity may put forth a proposal for consideration of inclusion of a Node Operator into the permissioned part of the protocol following the standard governance process, bypassing the standard CMC-driven process.
Downgrading Path
In addition to serving as the entry tier for newly onboarded operators, the Professional Operator type may also function as a fallback category for operators that were previously assigned another Node Operator Type but, following reassessment or a material operational event, no longer meet the requirements for that type. In particular, where a significant incident demonstrates a meaningful deterioration in the operator’s reliability, security posture, operational maturity, or overall standing, the CMC may determine that the operator should be downgraded to the Professional Operator type, either temporarily or until the relevant concerns are remediated and verified in a subsequent reassessment cycle.
Graduation Criteria
Operators that have been onboarded in CMv2 as Professional Operators and comply with the following criteria may become eligible to transition out of the trial stage and be assigned another Node Operator Type. Meeting these criteria should be understood as a general graduation baseline applicable across CMv2 type reassessments. Additional operator types (Decentralization Operator, Extra Effort Operator, and Public Good Operator) impose their own additional type-specific eligibility criteria.
- Ideally 9 months of active participation in CMv2, with average performance above network average. Slightly lower performance can be acceptable for candidates to Decentralization Operator type (e.g. due to operation in regions that materially affect performance) and assessed on case by case basis.
- No slashing events and no material inactivity penalties
- No major operational incidents within the last 6 months
- Responsive and constructive communication with the NOM team, including timely replies to operational, technical, and incident-related requests
- Demonstrated security and operational maturity. This may be evidenced through formal proofs, such as a SOC 2 Type II audit, ValOS certification, or a comparable independent security or infrastructure audit, but may also be supported by other non-formal evidence demonstrating mature operational and security practices.
Operators meeting these conditions may be reviewed by the CMC and, upon confirmation, reclassified as Professional Trusted Operator or other types within CMv2.
Professional Trusted Operator Type Assessment
The Professional Trusted Operator type represents the default type for established, for-profit Node Operators within the Curated Module. It consists of two groups:
- CMv1 Operators that migrate to CMv2 and remain in good standing.
- Newly onboarded operators to CMv2 that successfully complete the Professional Operator trial stage and fulfill the defined graduation criteria.
CMv1 operators are included by default, as they have already demonstrated sustained performance and reliability within the Lido Protocol. Their historical track record serves as the basis for trusted status upon migration to CMv2.
Intra-Operator DVT Cluster
This type builds on the single operator DVT framework introduced in June 2025 and can be issued to a Node Operator on request in addition to other types. This type can be issued outside of the reassessment window. The Intra-Operator DVT Cluster type will allow for Node Operators to clearly delineate validators utilizing single-operator DVT within their stack, and provide flexibility for the DAO to modify parameters related to the Node Operator type if needed in the future. Node Operators running keys under this type must:
- Run validators using Obol or SSV
- Generate the keys via DKG ceremony
- Enroll in monitoring via DVT provider specific tooling (e.g. Obol Grafana metrics, automated SSV Network metrics)
- Maintain a Intra-Operator DVT cluster on an Ethereum testnet (e.g. Hoodi)
- Coordinate with contributors in the Node Operator Mechanisms workstream to verify DKG utilization and monitor protocol infrastructure diversity
Public Good Type Assessment
The Public Good Operator type acknowledges operators that are meaningfully involved in the development or maintenance of core Ethereum infrastructure, including:
- Execution Layer (EL) clients
- Consensus Layer (CL) clients
- Validator clients
Operators in this type (often referred to as Client-Team Operators) contribute engineering resources or a meaningful portion of their revenue to the development and maintenance of Ethereum client software used across the network. These efforts play a critical role in maintaining the health and decentralization of Ethereum by ensuring that multiple independent client implementations remain viable and actively maintained.
Beyond their development contributions, Public Good Operators frequently serve as technical resources for the broader Node Operator set, helping other operators adopt, operate, and troubleshoot different client implementations. This role supports the diversification of client usage across the validator ecosystem and helps mitigate systemic risks associated with client monoculture.
Assessment Considerations
When evaluating eligibility for the Public Good Operator type, CMC may consider several factors, including but not limited to:
- Active involvement in the development or maintenance of an Ethereum client
- Participation in client maintenance, bug fixing, and release support
- Portion of revenue allocated to the development or maintenance of an Ethereum client
- Engagement with the broader Ethereum community and developer ecosystem
Extra Effort Type Assessment
The Extra Effort type is designed to recognize Node Operators who contribute additional value to the Lido ecosystem beyond validator operations. While the Professional Operator assessment focuses on operational reliability and infrastructure quality, the Extra Effort type rewards operators who actively strengthen the protocol through capital participation and long-term alignment with the Lido DAO.
An operator may qualify for the Extra Effort type through one or both of the following forms of contribution:
- Bringing stake to the protocol, either to Lido Core or to stVaults
- Demonstrating long-term alignment with the Lido DAO through meaningful LDO token holdings (and ideally vote participation)
Node Operators seeking the Extra Effort designation must submit an application to the Curated Module Committee providing verifiable proof of their contributions. Submitted data will be reviewed and validated by the CMC as part of the reassessment process.
The framework also recognizes certain forms of ongoing protocol service as a partial equivalent of capital-based contribution. In particular, Node Operators that operate Lido Oracles or the DSM perform additional responsibilities beyond validator operations, including supporting critical protocol infrastructure and operational security. Because this work creates recurring operational burden and protocol-level responsibility, it may be recognized within the Extra Effort framework as a limited adjustment to tier thresholds.
Tier Structure
The Extra Effort type is applied proportionally to the validator keys/stake operated by a Node Operator. Depending on the magnitude of their contribution, operators may qualify for one of five tiers.
| Tier | Qualified Stake Share |
|---|---|
| Tier 1 | 20% |
| Tier 2 | 40% |
| Tier 3 | 60% |
| Tier 4 | 80% |
| Tier 5 | 100% |
This means that only the corresponding portion of the operator’s validator stake will be treated as Extra Effort qualified.
The system is additive across contribution categories, capped at 100%. For example:
- An operator qualifying for Tier 1 via LDO holdings (20%)
- And Tier 2 via stVaults stake contribution (40%)
would receive a combined Tier 3 qualification, allowing 60% of their stake to be classified under the Extra Effort type.
As a limited exception, a Node Operator that operates Lido Oracles or the DSM may receive a contribution credit equal to one half of Tier 1. This credit may be applied as a reduction to the otherwise required threshold under the stake, stVaults, or LDO pathway. In practical terms, this means that such an operator would need to satisfy only half of the Tier 1 requirement to reach Tier 1, and the same fixed equivalent may also be applied toward higher tiers. For example, if the default Tier 1 stake threshold is 8,800 ETH, an eligible Oracle/DSM operator would need to contribute 4,400 ETH to reach Tier 1. If the default Tier 2 threshold is 17,500 ETH, the same operator would need to contribute 13,100 ETH instead. The same logic applies to LDO-based thresholds and to stake brought through stVaults.
Eligibility and Capacity
The Extra Effort type does not have a fixed number of available slots. Any Node Operator that satisfies the relevant tier thresholds and successfully passes the CMC review may receive the Extra Effort designation.
This structure ensures that the mechanism:
- Encourages operators to bring additional value to the protocol
- Maintains transparent and measurable qualification thresholds
The quantitative thresholds for each tier will be reassessed periodically, typically prior to each reassessment cycle, to ensure they remain appropriate relative to protocol growth and overall stake distribution.
Lido Core / stVaults Contributions
One pathway to qualifying for the Extra Effort type is through bringing additional ETH stake to the Lido ecosystem.
Operators may contribute stake in two ways:
- Lido Core — whereby attributable stake is determined through the rewards share program.
- stVaults — whereby attributable stake is determined through stVaults which operated by the NO.
Recognizing stake contributions incentivizes Node Operators to actively grow the protocol’s TVL and to promote Lido as a part of their product offerings.
The table below outlines the minimum stake contribution thresholds at default fees required to qualify for each tier.
These thresholds may change as the protocol grows or as staking market conditions change. Actual thresholds will be defined by the CMC before each reassessment round.
If a Node Operator has a custom set of fees for stVaults, the thresholds will be recalculated ad-hoc for this Operator.
LDO Contributions
The second pathway to Extra Effort qualification is through holding LDO tokens, the governance token of the Lido DAO.
LDO holders can participate in protocol governance by voting on proposals affecting:
- protocol upgrades and configuration / parameters
- treasury decisions
- node operator set composition
- broader strategic direction
Recognizing LDO holdings within the Extra Effort framework rewards operators who demonstrate long-term alignment with the DAO and its governance process.
To qualify under this pathway, the relevant LDO balance must be continuously held at the Node Operator’s designated address for at least 2 months prior to the reassessment date. This requirement is intended to prevent short-term balance parking around reassessment rounds.
The table below outlines the LDO holding thresholds required to qualify for each tier.
These thresholds may change as the LDO/USD; LDO/ETH ratio or staking market conditions change. Actual thresholds will be defined by the CMC before each reassessment round.
Decentralization Operator Type Assessment
In Phase 1 of CMv2, Node Operator fees are fixed and the DAO fee target constrains how many Decentralization Operator seats can exist at any given time. For each reassessment cycle, the CMC defines the number of available Decentralization Operator seats in advance, scores all eligible operators under the methodology below, and assigns the type to the highest-ranked operators.
It is proposed that operators are ranked using a scoring system: Operators can see where they stand and what levers improve their outcome. In order to be eligible for this node operator type, Node Operators must disclose information regarding their infrastructure setup at the full detail requested for Lido Validator and Node Operator Metrics (VaNOM) reporting, and accept that this data may be utilized to report infrastructure setup publicly (at a disaggregated level).
Pillars
It is proposed that the Decentralization Score is built from three pillars:
- Client diversity: [-10; +30] points
- Geography: [-10; +20] points
- Infrastructure: [-20; +10] points
Score = Client [-10; +30] + Geo [-10; +20] + Infra [-20; +10]
Scores under this framework may be negative. A negative score does not affect an Operator’s participation in Lido Operator set or its eligibility for other operator types. It only affects relative ranking for the limited Decentralization Operator seats in that reassessment cycle.
Parameter weights
Client diversity
Assessment on CL and EL client diversity is based on a system of predefined scoring curves. Under this approach, at each reassessment round, every client is classified according to its current network position as a non-majority (minority) client, a majority client, or a super-majority client, and the corresponding predefined curve is used to convert the operator’s share of that client into points.
This approach is intended to capture two related but distinct objectives. First, it rewards Node Operators that contribute to network-wide client decentralization by materially using non-majority clients. Second, it rewards operators that improve intra-operator resilience by distributing their validator fleet across multiple clients rather than depending on a single one. As a result, the methodology does not treat a setup with a single minority client at 100% as equivalent to a balanced multi-client setup: concentrated minority-client usage can still receive some positive credit, but materially less than a diversified configuration. Additionally, setups where client pairs are used in a consensus or circuit-breaker like setup (e.g. utilizing Vouch, Vero, intra-operator DVT with multiple clients, etc.) may eventually also be treated as a separate class of infrastructure diversity or lead to changes in the proposed framework in the future.
CL and EL client diversity are assessed separately. Each layer can contribute up to 15 points, for a total Client diversity score of up to 30 points.
How the scoring works
For every EL and CL client, the operator’s usage share is mapped onto one of three predefined curves:
- non-majority (minority) client curve
- majority client curve
- super-majority client curve
The graph below shows the three scoring curves used in the framework.
X-axis: Percentage of stake run by the operator using the client
Y-axis: Score points
More specifically:
- the non-majority curve peaks at roughly 33% usage and then declines gradually, while remaining above zero even at very high shares;
- the majority curve peaks at roughly 20% usage, then declines, crosses below zero once usage becomes too high, and converges to a negative floor;
- the super-majority curve is strongly disincentivizing: after minimal usage, it becomes sharply negative and quickly reaches the maximum penalty.
What this means for non-majority client usage
For non-majority clients, the curve reaches its highest value when a client represents roughly one third of the operator’s fleet. This reflects the idea that the strongest operator-level setup is a balanced distribution across several non-majority clients. In practical terms, the highest score within a given layer can be achieved when a Node Operator runs an approximately even split across at least three non-majority clients, each representing around 33% of that layer. It is recognized that even more optimal combinations are possible (e.g. full circuit-breaker setup via Vouch), and it is possible that the framework will be further calibrated in the future to reflect this.
At the same time, the non-majority curve remains positive even at very high shares. This is intentional. Running 100% of a layer on a single non-majority client still contributes to network-wide client decentralization, however, because such a setup does leave room for additional meaningful intra-operator client resilience or failover diversity, it would score lower than a balanced multi-client setup. In other words, 100% on one non-majority client is better than 100% on one majority client, but substantially worse than a 33% / 33% / 33% split across three non-majority clients (or better).
What this means for majority client usage
For majority clients, the curve peaks at a lower share and at a lower score than for non-majority clients. This means majority clients are not forbidden, and they are not treated as automatically harmful when used in moderation. A majority client can still be part of a healthy setup when it represents a limited portion of the fleet.
However, once a majority client grows beyond its preferred range, the score falls quickly, crosses below zero, and eventually reaches a negative floor. The effect is that the framework allows majority clients to play a limited supporting role, but clearly discourages dependence on them as the dominant client inside an operator’s fleet.
What this means for super-majority clients
For super-majority clients, the curve is designed to be strongly disincentivizing. Small or incidental usage may remain close to zero, but once a super-majority client represents a meaningful share of the operator’s fleet, the score turns sharply negative and quickly reaches its minimum. This reflects the view that materially adding to the dominance of a super-majority client increases systemic client concentration risk and should therefore be treated as harmful within the Decentralization Operator assessment.
Reassessment of client categories
Client classifications should be re-evaluated before each reassessment cycle based on the then-current network state. A client that is treated as non-majority in one cycle may be treated as majority in a later cycle, and vice versa. If a client reaches super-majority conditions, it should be scored under the super-majority curve for that reassessment period. This ensures that the methodology remains responsive to actual network conditions rather than static assumptions.
Geographical diversity
Underrepresented regions
This scoring category is meant to incentivize operating in regions that are currently underrepresented in Ethereum’s / Lido Protocol validator geography distribution. Geo diversity increases resilience against regional outages (power, connectivity), natural disasters, and jurisdiction-specific risks (regulatory action, censorship pressure, or policy-driven infrastructure restrictions). From a protocol perspective, it reduces the chance that a single region’s disruption causes a large fraction of validators to go offline simultaneously.
Overrepresented regions
This scoring category is meant to disincentivize concentration in overrepresented regions because it amplifies correlated risks: if too many validators share similar legal jurisdictions, cloud markets, peering paths, or power grids, the network becomes more fragile to region-specific shocks.
The list of countries / jurisdictions and their classification as underrepresented, neutral, or overrepresented should be published for each assessment cycle together with the relevant methodology updates.
Dispersion / resilience score
In addition to rewarding placement in underrepresented regions and penalizing concentration in overrepresented ones, the Geography pillar should also reward operators that distribute meaningful parts of their validator fleet across multiple materially distinct countries or jurisdictions. The purpose of this subscore is to capture operator-level resilience: an operator that is spread across several separate legal, regulatory, power, connectivity, and hosting environments is less exposed to a single regional outage or jurisdiction-specific shock than an operator concentrated in one place. For this purpose, a country or jurisdiction counts as materially distinct if it represents a separate sovereign country or a geographically distinct territory with meaningfully independent power, connectivity, and hosting infrastructure, and it hosts at least 15% of the operator’s average active validator stake during the assessment period; multiple cities, data centers, or availability zones within the same country do not count as additional dispersion, and token deployments below 15% are ignored for scoring.
The Dispersion / resilience score is assigned as follows:
- 0 points if the operator has only 1 qualifying country/jurisdiction;
- +2 points if the operator has 2 qualifying countries/jurisdictions;
- +5 points if the operator has 3 or more qualifying countries/jurisdictions.
The score is capped at +5, so the framework rewards meaningful cross-jurisdiction distribution without encouraging artificial fragmentation.
Infrastructure
Validators run On-Premises
This category is meant to incentivize meaningful on-prem presence because it reduces reliance on shared cloud failure domains. On-prem validators diversify away from correlated cloud outages, cloud networking incidents, provider-level policy changes, and large-scale credential compromise patterns that can affect many tenants at once.
Validators run on Cloud
This scoring category is meant to disincentivize extreme dependence on cloud hosting. Cloud infrastructure is operationally efficient, but from a decentralization lens it introduces correlated dependencies: shared provider control planes, shared physical regions, shared upstream outages, and sometimes shared compliance constraints.
Validators run on majority Cloud
This scoring category is meant to disincentivize reliance on the single largest cloud provider in the Operator’s fleet. Even if an Operator is “on cloud,” distributing across providers reduces correlated risk from a single vendor’s control-plane outage, regional routing events, or policy/enforcement actions. It is proposed that the “majority cloud” provider is defined per quarter from VaNOM/provider-mapping data, rather than hard-coded, because market share can shift.
(End of Part 1 – continuation in next section)