# Node Operator Type Assessment Framework | CMv2 **URL:** \ **Category:** Proposals\ **Created:** [April 20, 2026, 6:58pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477 "2026-04-20T18:58:49Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Aleksandra\_G](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/aleksandra_g/32/2024_2.png) [@Aleksandra\_G](https://research.lido.fi/u/Aleksandra_G)\ **Post date:** [April 20, 2026, 6:58pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/1 "2026-04-20T18:58:49Z")
# **TL;DR** This proposal focuses on **how Node Operators qualify for [CMv2](https://research.lido.fi/t/future-of-the-curated-module-cmv2-landscape/10929) Node Operator Types**, rather than on the specific values for the parameters assessed. - The [**Phase 1 CMv2 parameters by Node Operator type**](https://research.lido.fi/t/future-of-the-curated-module-cmv2-landscape/10929/16) 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](https://research.lido.fi/t/future-of-the-curated-module-cmv2-landscape/10929/16) 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)](https://research.lido.fi/t/proposal-transition-the-lnosg-into-the-cmc/11341), 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](http://www.lido.fi/governance), 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](https://research.lido.fi/t/proposal-curated-module-intra-operator-dvt-guidelines/10197) 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](https://docs.lido.fi/guides/oracle-operator-manual/)** or the **[DSM](https://docs.lido.fi/guides/deposit-security-manual/)** 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](https://research.lido.fi/t/rewards-share-program-committee-updates/11107/2). - **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.** ![Stake contributions](https://europe1.discourse-cdn.com/flex013/uploads/lido/original/2X/8/8e42add2aac331e9a499f376a999b7f6811fc96c.png) 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 **LDO** , the governance token of the Lido DAO. This pathway recognizes Node Operators that demonstrate long-term alignment with the DAO either by **holding LDO** or by **holding LDO and actively participating in governance**. The latter should qualify under **lower LDO thresholds** than holding alone. To qualify under the **holding + voting** variant, 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, and the operator must have voted in at least **two Snapshot and/or onchain voting slots during the 6 months preceding the assessment date**. Operators that meet the holding requirement but not the voting requirement may still qualify under the **holding-only** thresholds. The table below should therefore distinguish between: - **Holding-only thresholds** - **Holding + voting thresholds** ![LDO contributions](https://europe1.discourse-cdn.com/flex013/uploads/lido/original/2X/c/c6d0aa56cf778631d79f00877b11c0ddebe29e89.png) If the LDO balance supporting an operator’s Extra Effort qualification later **decreases** , the operator’s **tier should be reduced** accordingly. If the operator no longer meets the minimum threshold, or disposes of the relevant LDO entirely, the **LDO-based Extra Effort qualification should be removed** outside the reassessment round. The LDO-based pathway is intended to reflect genuine and durable alignment with the Lido DAO. Accordingly, operators are discouraged from relying on borrowed or otherwise temporary LDO positions to qualify for the Extra Effort type. Where the CMC concludes that the relevant LDO position does not represent such alignment, the operator should not receive the type on that basis. 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)](https://app.hex.tech/8dedcd99-17f4-49d8-944e-4857a355b90a/app/VaNOM-Lido-on-Ethereum-Validator-Node-metrics-1vnpSDa7PtbyA6HX0bVNj1/latest) 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: 1. **Client diversity:** [-10; +30] points 2. **Geography:** [-10; +20] points 3. **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 ![DO weights](https://europe1.discourse-cdn.com/flex013/uploads/lido/original/2X/7/7183adf4ddf2ec31dfa3c92316e266a6a6f45799.png) ## 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. ![DO client curves](https://europe1.discourse-cdn.com/flex013/uploads/lido/original/2X/d/d507e314b58d8684784a9e8241a20d809a0520ba.jpeg) _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)_ ---
**Author:** ![Aleksandra\_G](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/aleksandra_g/32/2024_2.png) [@Aleksandra\_G](https://research.lido.fi/u/Aleksandra_G)\ **Post date:** [April 20, 2026, 7:01pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/2 "2026-04-20T19:01:08Z")
_(Beginning of Part 2 – continued from previous section)_ # Assessment cadence and flow It is proposed that reassessment happens **twice a year** , aligned with the cadence of reliable new VaNOM data availability. This cadence reduces noisy month-to-month changes and ensures Operators are assessed on a meaningful operating window rather than one-off events. Assessments in the current version of the framework rely on operator-submitted applications and VaNOM data. Unless otherwise stated, the CMC assumes submitted data is truthful and materially accurate, and any indication that the data provided is not truthful or accurate would be investigated with possible penalties (up to and including removal from the Curated Module). Further, Node Operators wishing to apply for the PG or DO node operator types would be asked to assent possible audits with regards to verification of submitted data. This cadence is intended primarily for the **Public Good** , **Extra Effort** , and **Decentralization Operator** types. **Professional Operator** onboarding and **Professional Trusted Operator** graduation continue to follow their dedicated processes described above. For the special types, the proposed order of assessment within each reassessment wave is: 1. **Public Good Operator** | Application-based assessment 2. **Extra Effort Operator** | Application-based assessment 3. **Decentralization Operator** | VaNOM-based assessment, no application required Data submitted by Operators through application forms or VaNOM reports is not intended to be publicly shared in raw format. Instead, **aggregated assessment outcomes** (for example, Public Good approvals, Extra Effort tiers, and Decentralization scores / rankings) should be shared on the forum to provide transparency on the outcome of each assessment wave. ## **Framework Maintenance** In order to keep the framework flexible and to streamline the governance process around it, it is proposed that the CMC will be responsible for: - Adjusting the framework: its score system, requirements and general methodology - Defining thresholds and parameters for each assessment round - Define when the reassessment should take place - Assigning types according to the actual version of the framework - Communicate updates and adjustments to the framework publicly on the research forum Tokenholders may at any time vote to rescind or reassign these responsibilities to another group, entity, individual, and may vote to modify, extend, or remove them entirely. ---
**Author:** ![Pacobits](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/pacobits/32/3056_2.png) [@Pacobits](https://research.lido.fi/u/Pacobits)\ **Post date:** [April 21, 2026, 3:48pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/3 "2026-04-21T15:48:37Z")
Thank you very much @Aleksandra_G for the extensive post and for clarifying the criteria. We have a few questions we would appreciate some clarification on: - How would mixed setups be treated under the “Validators run On-Premises” category? For example, cases where the VC runs on cloud, an EC/BN runs on-premises, and the backup components are split between cloud and on-premises environments. - Are bare metal servers rented from third-party providers classified as cloud or as a different category? On a separate note, we would also like to share one suggestion for future revisions of the framework. It may be worth considering a category for operators that perform strongly across all areas without necessarily being the top performer in any single one of them. Now that more numerical criteria exist, having a category that recognizes an operator for its overall contribution and balance could add meaningful value. For example, this could include operators that maintain a strong balance across client diversity, geographic distribution, resilience, attracting clients to Lido, holding LDO, voting and participating in governance, and contributing to the broader Ethereum ecosystem. In my view, the “Extra Effort” category initially reflected that idea, whereas now it seems to have evolved more toward client acquisition, which also makes complete sense. ---
**Author:** ![Aleksandra\_G](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/aleksandra_g/32/2024_2.png) [@Aleksandra\_G](https://research.lido.fi/u/Aleksandra_G)\ **Post date:** [April 22, 2026, 10:34am UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/4 "2026-04-22T10:34:20Z")
Thank you for the comment, @Pacobits ! > [@Pacobits](#): > > How would mixed setups be treated under the “Validators run On-Premises” category? For example, cases where the VC runs on cloud, an EC/BN runs on-premises, and the backup components are split between cloud and on-premises environments. Currently only EC/BN server type is taken into account. > [@Pacobits](#): > > Are bare metal servers rented from third-party providers classified as cloud or as a different category? If labeled `"On-Premises"` → counts as on-prem, gets positive score If labeled `"Cloud"` or `"VM"` → counts as cloud, gets negative score If labeled anything else (e.g. `"Bare Metal"`, `"Dedicated"`) → is treated as neutral > [@Pacobits](#): > > It may be worth considering a category for operators that perform strongly across all areas without necessarily being the top performer in any single one of them. Now that more numerical criteria exist, having a category that recognizes an operator for its overall contribution and balance could add meaningful value. This could become a consideration for future iterations, though it would be more tricky to reason about which particular combinations can bring a node operator to a higher tier. The DAO fee target would be a main limitation factor here. ---
**Author:** ![hc\_bitsheaven](https://avatars.discourse-cdn.com/v4/letter/h/f14d63/32.png) [@hc\_bitsheaven](https://research.lido.fi/u/hc_bitsheaven)\ **Post date:** [April 23, 2026, 1:32am UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/5 "2026-04-23T01:32:05Z")
Thanks for the detailed explaination @Aleksandra_G! > 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. When will Lido consider taking in applications for new operator again? We are very interested in becoming a node operator for Lido. ---
**Author:** ![katernoir](https://avatars.discourse-cdn.com/v4/letter/k/f475e1/32.png) [@katernoir](https://research.lido.fi/u/katernoir)\ **Post date:** [April 23, 2026, 9:32am UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/6 "2026-04-23T09:32:10Z")
> [@Aleksandra\_G](#): > > 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. Do I understand correctly that to quality for the extra effort category, one only has to hold sufficient LDO token and not actually actively participate in governance? Why wouldn’t we require the extra effort to be involved in governance? Borrowing LDO token on a lending market, holding them for the reassessment date and then paying them back might be profitable depending on commission rewards. Since there is not that much one can do with LDO token otherwise, I would expect the borrow rate to be very low on LDO token. Will you allow LDO holdings to be spread out in multiple addresses or does everything have to be in one address? > [@Aleksandra\_G](#): > > Geo diversity increases resilience against regional outages (power, connectivity), natural disasters, and jurisdiction-specific risks (regulatory action, censorship pressure, or policy-driven infrastructure restrictions) I believe we need to be careful with jurisdiction-specific risks and analyze where both the company hosting the servers is incorporated and also the company running the validators (+ where the actual people are based that operate the validators). Looking at the server alone ---
**Author:** ![KimonSh](https://avatars.discourse-cdn.com/v4/letter/k/df788c/32.png) [@KimonSh](https://research.lido.fi/u/KimonSh)\ **Post date:** [April 23, 2026, 1:00pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/7 "2026-04-23T13:00:43Z")
> [@hc\_bitsheaven](#): > > When will Lido consider taking in applications for new operator again? We are very interested in becoming a node operator for Lido. Thanks for the question - as of right now, the focus regarding the Curated Set is moving forward with the migration from Curated Module V1 to V2. Depending on the state of the protocol in terms of stake distribution and inflows (or outflows, as we are seeing currently with the ongoing market volatility), it is possible an onboarding round could be opened near the end of the migration. If there is an onboarding round (again, this very much depends on what the state of the protocol looks like after the migration), it would likely be small in scope in terms of the number of Node Operators onboarded and with a specific focus on what benefits onboarding these Node Operators would bring to the protocol’s infrastructure resilience, as well as broader ecosystem participation. With ETH : USD/EUR prices fairly low, the recent change to Node Operators reward share, and upcoming introduction of the Valmart marketplace, there is an important consideration to keep in mind regarding the economics for existing Node Operators in the Curated Module. I would hope to share more information regarding our thinking around the Lido Core Node Operator set as we get closer to the CMv2 migration, when we have a more accurate picture of what stake distribution of the protocol will look like closer to year end. ---
**Author:** ![hc\_bitsheaven](https://avatars.discourse-cdn.com/v4/letter/h/f14d63/32.png) [@hc\_bitsheaven](https://research.lido.fi/u/hc_bitsheaven)\ **Post date:** [April 23, 2026, 7:33pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/9 "2026-04-23T19:33:19Z")
Thanks for the detailed update, @KimonSh — really appreciate the transparency around the CMv2 migration and onboarding considerations. Looking forward to hearing more as things progress later this year! ---
**Author:** ![Aleksandra\_G](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/aleksandra_g/32/2024_2.png) [@Aleksandra\_G](https://research.lido.fi/u/Aleksandra_G)\ **Post date:** [April 24, 2026, 12:49pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/10 "2026-04-24T12:49:11Z")
Hi @katernoir , thank you for your feedback! > [@katernoir](#): > > Do I understand correctly that to quality for the extra effort category, one only has to hold sufficient LDO token and not actually actively participate in governance? Why wouldn’t we require the extra effort to be involved in governance? The intent was not to say that passive LDO holding is the “ideal” form of governance alignment, but to define a measurable baseline that can be verified consistently across operators. Requiring some form of governance participation could make sense, though I would be careful not to require participation in every vote, since operators may have conflicts of interest or may reasonably abstain on some proposals. But requiring evidence that the operator is not simply holding LDO passively is a reasonable direction that will be considered. > [@katernoir](#): > > Borrowing LDO token on a lending market, holding them for the reassessment date and then paying them back might be profitable depending on commission rewards. Since there is not that much one can do with LDO token otherwise, I would expect the borrow rate to be very low on LDO token. On the borrowing concern: yes, this is a good callout. The 2-month continuous holding requirement was meant to reduce this type of short-term behavior, but I agree it may not be sufficient on its own. We propose that if a Node Operator disposes of the LDO used to qualify for Extra Effort during the period in which that Extra Effort tier is active, CMC may downgrade the operator by removing the relevant Extra Effort tier. This should make clear that the LDO requirement is intended to represent an ongoing commitment, not a temporary balance held only for the reassessment date. The longer-term solution will be something that is being cooked for the second phase of CMv2: locking + delegation functionality that makes the contribution bring benefits only during the time LDO is held. > [@katernoir](#): > > Will you allow LDO holdings to be spread out in multiple addresses or does everything have to be in one address? Our initial preference would be to allow balances across multiple addresses as long as a Node Operator can prove the ownership of there addresses (within the application form, by providing a signature hash of the signed msg). Requiring everything to sit in a single address is simpler, but may not reflect how some operators structure treasury, custody or governance participation. ---
**Author:** ![Max\_whatname](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/max_whatname/32/5121_2.png) [@Max\_whatname](https://research.lido.fi/u/Max_whatname)\ **Post date:** [April 28, 2026, 10:12am UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/11 "2026-04-28T10:12:05Z")
What will be the target for the final number of operators, or the “floor” of revenue/operator? I’m just wondering if/when/how those numbers would be decided, assuming there will be more qualified operators than there is stake to go around… ---
**Author:** ![KimonSh](https://avatars.discourse-cdn.com/v4/letter/k/df788c/32.png) [@KimonSh](https://research.lido.fi/u/KimonSh)\ **Post date:** [April 28, 2026, 11:18am UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/12 "2026-04-28T11:18:15Z")
Hi Max, There is not expected to be a hard target for the number of operators within the module, this very much depends on the amount of ETH that is staked with the protocol. The Lido Node Operator set overall is continuing to grow with CSM, and as the share limit continues to increase this trend should continue. In terms of revenue/operator, again, there is no hard target. The cost of operations varies significantly per operator depending on the way they run their infrastructure, team size, business goals, etc. The introduction of ValMart later this year will allow Node Operators to compete based on fee (in addition to other factors) and provide an opportunity for Node Operators to directionally target a level of stake/revenue from the protocol, factoring in their cost of operations. From my perspective, we have been at the point where there are more qualified operators than stake to go around for some time. The staking industry has matured significantly in the past two years. During that time, we’ve seen staking inflows generally flow to more centralized setups. If the protocol was to receive significant and sustained inflows, my view is there would be appetite for another small onboarding round to the Curated Module, but based on the numbers today (especially amidst the ongoing market volatility), I personally do not think that there is not a rush to onboard more Node Operators at this time. As we move through the year, we’ll share a more in depth update around what the stake situation looks like for Lido Core and CMv2. ---
**Author:** ![Aleksandra\_G](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/aleksandra_g/32/2024_2.png) [@Aleksandra\_G](https://research.lido.fi/u/Aleksandra_G)\ **Post date:** [May 10, 2026, 6:41pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/13 "2026-05-10T18:41:22Z")
Based on the feedback received, I updated the LDO section in the Extra Effort part of the framework: - split the LDO pathway into holding only vs holding + voting, so that passive alignment and active governance participation are treated separately, with more favorable thresholds for operators that actually use their LDO in governance - added that if the relevant LDO balance is no longer sufficient, the EE tier should be lowered or removed, so that the type continues to reflect the operator’s actual ongoing alignment rather than a one-time snapshot ---
**Author:** ![governance-data-bot](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/governance-data-bot/32/2204_2.png) [@governance-data-bot](https://research.lido.fi/u/governance-data-bot)\ **Post date:** [May 11, 2026, 5:38pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/14 "2026-05-11T17:38:00Z")
## Snapshot vote started The [Adopt the Node Operator Type Assessment Framework for CMv2](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0x2b221847bae789551593115be9a364db4c9a478056d6394b1bef7728790258ee) Snapshot has started! Please cast your votes before Mon, 18 May 2026 16:00:00 GMT 🙏 ---
**Author:** ![governance-data-bot](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/governance-data-bot/32/2204_2.png) [@governance-data-bot](https://research.lido.fi/u/governance-data-bot)\ **Post date:** [May 18, 2026, 4:02pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/15 "2026-05-18T16:02:05Z")
## Snapshot vote ended Thank you all who participated in [Adopt the Node Operator Type Assessment Framework for CMv2](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0x2b221847bae789551593115be9a364db4c9a478056d6394b1bef7728790258ee) Snapshot! 🙏 The results are: **Approve** : 56.7M LDO **Reject** : 5.4M LDO ---
**Author:** ![Aleksandra\_G](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/aleksandra_g/32/2024_2.png) [@Aleksandra\_G](https://research.lido.fi/u/Aleksandra_G)\ **Post date:** [July 24, 2026, 1:25pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/16 "2026-07-24T13:25:59Z")
In preparation for the CMv2 release, and on behalf of the Curated Module Committee, I would like to share the results of the first assessment round for the Public Good, Extra Effort, and Decentralization Operator types. Lido Core contributors, together with CMC members, conducted the application, assessment, and data verification processes in accordance with [the Node Operator Type Framework](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477). As a result, the following node operators have been found eligible for the respective types: **Extra Effort Operators** - Staking Facilities - [P2P.org](http://P2P.org) - stakefish **Decentralization Operators** - Everstake - RockLogic GmbH **Public Good Operators** - Attestant (BVI) Limited (Vouch) - ChainSafe (Lodestar) - Consensys (Besu / Teku) - Develp (Nimbus) - Prysm Team at Offchain Labs (Prysm) - Sigma Prime (Lighthouse) - Twinstake (Nethermind) These types will become available to the respective node operators in CMv2 once the corresponding CMC transaction is approved through the Easy Track governance process, which is expected to take place next Monday. These operators will start receiving rebates on stake run in CMv1 starting on August 1st. ---
**Author:** ![stefa2k](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/stefa2k/32/6940_2.png) [@stefa2k](https://research.lido.fi/u/stefa2k)\ **Post date:** [August 4, 2026, 6:10am UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/17 "2026-08-04T06:10:36Z")
We received the Decentralization Operator type in round one. Having been through the assessment, here is what stood out. None of it requires a vote or a change to the fee schedule. ## TL;DR 1. **Publish the round parameters before each round** , as the adopted framework commits to. 2. **Give every assessed operator their breakdown and the round’s cutoff** , and publish scores for candidates who opt in. 3. **Close the EC/BN scoring boundary.** The validator client and the signer are not scored at all. 4. **Apply the majority-provider penalty beyond cloud** , with one round of notice before it bites. 5. **Score the five values of the server type field as a gradient** , not three. * * * ## 1. Publish the round parameters The adopted framework commits to this: > “Before each assessment round, the CMC should publish the parameters that apply to the Decentralization Operator assessment for that round, including the number of available seats, client category mappings (non-majority / majority / super-majority), geography classifications, and any other relevant methodology updates” It makes the same commitment for the country classification list and for the Extra Effort tier values. Round one published the list of approved operators. It did not publish the seat count, the client category mappings, the country classifications, the Extra Effort thresholds applicable to the round, or which tier each Extra Effort recipient received. One item is not a publication commitment but a gap in the text: the framework describes three scoring curves and never states in prose how the per-client values combine into a layer score. It is inferable, since the minority curve peaks at three clients of roughly a third each and each layer caps at 15 points, but an operator should not have to reverse the rule out of a graph to know whether the framework rewards running more clients or fewer. **Ask:** publish the round parameters before each round, and write the aggregation rule down. ## 2. Publish the scores, and tell operators where the line was The framework promises that “Decentralization scores / rankings” will be shared on the forum. Round one shared names. **Every assessed operator should get their own breakdown as a matter of course, and the round’s cutoff with it.** The breakdown is available on request, which is not the same as being provided: it assumes an operator knows to ask and has a channel to ask through. The cutoff is the piece that decides whether building is worth the capital, because without it an operator cannot tell whether they were one point short or thirty. It is also a single number that names nobody, so the concern about revealing other operators’ scores does not reach it. **On publication:** the framework already requires DO candidates to “accept that this data may be utilized to report infrastructure setup publicly (at a disaggregated level)”. Making publication of the resulting score part of entering the assessment is a small extension of a consent that already exists. Operators who want a seat opt in and are published. Operators who do not are not scored, so silence signals nothing about them. Publication is the contestable half. The private breakdown and the cutoff are not, and they should not wait for agreement on the rest. ## 3. The Infrastructure pillar stops at the beacon node Only the EC/BN server type is scored. So a setup with the validator client in cloud and the execution and beacon nodes on premises registers as on premises, and the signer, which is where the keys are, is not scored at all. **Ask:** extend the scored scope past EC/BN. This matters more than any refinement to the hosting categories, because it is what currently makes the pillar cheap to satisfy without changing the underlying risk. ## 4. Provider concentration is only penalised inside cloud The pillar penalises reliance on the largest cloud provider in an operator’s fleet. The instinct is right and the scope is too narrow. In VaNOM’s own Q2 provider data for the Curated Module, the largest single hosting provider is OVHcloud at 19.8 percent of module keys, labelled Dedicated Server. AWS follows at 9.9 percent, labelled Cloud. The penalty reaches the smaller concentration and not the larger one. The same shape shows up at the network layer: Doumanidis and Apostolaki (_Financial Cryptography and Data Security 2026_; arXiv:2505.07713v2) infer that the top three autonomous systems host more than half of all Ethereum validators, and OVH alone almost 27 percent. The risk does not depend on the label. In August 2022 Hetzner confirmed that its prohibition covers Ethereum proof of stake, in its own words: _“It is true for all of our products, except colocation.”_ Ten weeks later it enforced the same policy against Solana, and per the Solana Foundation’s validator health report, _“Over 1000 validators and 20% of active stake went offline in a matter of hours.”_ Those operators recovered by rehosting elsewhere. What saved them was having somewhere to go. **Ask:** apply the penalty across all hosting categories, and credit the ability to move: capacity already running with a second provider, or a completed migration inside the review window. **With one round of notice.** Operators concentrated with a single dedicated-server provider made that choice under the current rules. Repricing them in the round where the criteria change would punish them for a decision the framework did not previously penalise. Announce it, then apply it the round after. An operator spread across three providers already sits in three different networks without running any network infrastructure of its own. That makes provider diversity the cheap version of this property, and unlike facility ownership it is within reach of every operator in the set. We run three providers across three sites, so this ask favours us too. ## 5. The server type field has five values and three scores VaNOM’s server type field carries five values: Public Cloud, Managed Server, Dedicated, Colo and On-Premises. They are separated by real properties: exclusive use of the server, who administers the OS, who owns the hardware, who controls the facility. The scoring resolves three. On-Premises scores positive, Cloud and VM score negative, everything else is neutral. So an operator that specifies and buys its hardware, does its own cabling and switching and holds its own spares scores the same as one renting a machine whose OS is administered by the provider. **Ask:** score the five values as a gradient. The definitional work is done, only the mapping needs to follow it. Two of our three sites are colocation with owned hardware, so this ask would benefit us. It would benefit every operator that buys and runs its own machines, which is the behaviour the pillar says it wants. * * * None of the five needs a Snapshot. Two are commitments already in the adopted text, two correct how the score is applied, and the fifth uses a distinction the data model already makes. There is a separate question about what the score pays below the seat cutoff, and whether a fixed number of seats is the right shape for a continuous score. That belongs in its own post rather than mixed in here, and I will write it up separately. CMC: will the round two parameters be published before the Q4 assessment window closes, and is there a comment period on them? We are happy to contribute data for the provider-concentration work. ---
**Author:** ![Aleksandra\_G](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/aleksandra_g/32/2024_2.png) [@Aleksandra\_G](https://research.lido.fi/u/Aleksandra_G)\ **Post date:** [August 17, 2026, 3:13pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/18 "2026-08-17T15:13:14Z")
# **Additional information on the Round 1 assessment parameters** Following up on [the results of the first Node Operator Type assessment round](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/16), I’m publishing additional information on the parameters used for the assessment and the resulting Decentralization Operator scores. ## **Decentralization Operator assessment** **Number of available DO seats:** 2 **Data used for the assessment:** [Q2 2026 VaNOM data](https://app.hex.tech/8dedcd99-17f4-49d8-944e-4857a355b90a/app/VaNOM-Lido-on-Ethereum-Validator-Node-metrics-1vnpSDa7PtbyA6HX0bVNj1/latest) ### **Geography classification** **Overrepresented:** Finland, France, Germany, Netherlands, United Kingdom, United States. **Neutral:** Albania, Andorra, Australia, Austria, Belarus, Belgium, Bosnia and Herzegovina, Bulgaria, Canada, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Greece, Hungary, Iceland, Iran, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Mexico, Moldova, Monaco, Montenegro, North Korea, North Macedonia, Norway, Poland, Portugal, Romania, Russia, San Marino, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey, Ukraine, Vatican City. All other countries/jurisdictions were classified as **underrepresented** for this assessment round. ### **Client classification** **Execution Layer** - Majority: Geth, Nethermind - Non-majority: all other EL clients - Super-majority: none **Consensus Layer** - Majority: Lighthouse - Non-majority: all other CL clients - Super-majority: none **Client score aggregation:** For each layer, the individual client scores are summed and the resulting layer score is capped at 15 points. The EL and CL layer scores are then summed to produce the final Client Diversity score. ### **Infrastructure classification** **Cloud providers classified as majority:** AWS, GCP. All other infrastructure scoring parameters were applied as described in the adopted framework. **Round 1 DO results** The table below shows the ten highest Decentralization Scores calculated using the Round 1 assessment data. Operators that had already qualified for Public Good or Tier 5 Extra Effort status were excluded from DO assignment in accordance with the assessment flow and are shown here for transparency. | **Node Operator** | **Assessment result** | **Client Diversity** | **Geography** | **Infrastructure** | **Total** | | --- | --- | --- | --- | --- | --- | | Everstake | Classified as DO | 17.93 | 17.0 | -6.7 | 28.23 | | [P2P.org](http://P2P.org) | Excluded — EE Tier 5 assigned | 25.11 | -0.3 | 0.0 | 24.81 | | RockLogic GmbH | Classified as DO | 21.02 | 0.0 | 0.3 | 21.32 | | Galaxy | Not classified as DO | 25.20 | 0.0 | -6.7 | 18.50 | | SenseiNode | Not classified as DO | 3.20 | 15.0 | -0.7 | 17.50 | | Staking Facilities | Excluded — EE Tier 5 assigned | 17.27 | -10.0 | 10.0 | 17.27 | | Launchnodes | Not classified as DO | 2.00 | 15.0 | 0.0 | 17.00 | | Stakely | Not classified as DO | 25.63 | -6.2 | -3.3 | 16.13 | | Attestant (BVI) Limited | Excluded — Public Good type assigned | 17.27 | -3.3 | 0.0 | 13.97 | | Develp GmbH | Excluded — Public Good type assigned | -3.52 | 15.0 | 0.0 | 11.48 | ## **Extra Effort Operator assessment** The applicable Extra Effort thresholds were unchanged from those published in the adopted framework; no changes to these parameters were made for Round 1. The successful operators and the tiers awarded were: - Staking Facilities — Tier 5 - [P2P.org](http://P2P.org) — Tier 5 - stakefish — Tier 5 ---
**Author:** ![Aleksandra\_G](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/aleksandra_g/32/2024_2.png) [@Aleksandra\_G](https://research.lido.fi/u/Aleksandra_G)\ **Post date:** [August 17, 2026, 3:15pm UTC](https://research.lido.fi/t/node-operator-type-assessment-framework-cmv2/11477/19 "2026-08-17T15:15:52Z")
Thanks for the detailed feedback. Some of the points you raised around transparency of the assessment parameters and results are addressed in the follow-up post above, where I’ve added further information on the parameters used in the previous assessment round and the resulting DO scores. On the proposed methodology changes including expanding the infrastructure assessment beyond EC/BN, introducing broader provider-concentration scoring, refining the server-type scoring gradient, and related adjustments: these will be discussed with the CMC. We’ll address them based on the outcome of that discussion and communicate any agreed methodology changes before they are applied in a future assessment round. The same applies to the process for publishing future assessment parameters and allowing time for feedback before they are finalized: I’ll align this with the CMC and follow up once there is a clear approach.