1. Purpose
This Penalty Framework describes the categories of incidents, misbehavior patterns, and operational failures that may give rise to penalties for Node Operators participating in the Curated Module v2. Its purpose is to support consistent, proportionate, and risk-aware decision-making by the Curated Module Committee and the NOM team (Node Operator Mechanisms workstream of DAO contributors) while preserving sufficient discretion to address circumstances that cannot be fully predicted in advance.
Node Operators are entrusted with operating validators as a part of the Lido protocol. Their actions, monitoring procedures, infrastructure decisions, and responsiveness may directly affect protocol performance, validator safety, withdrawal processing, validator reward capture, and the reputation of Lido and Ethereum as a whole. For that reason, incidents involving Node Operator conduct should be assessed based on their specific circumstances, including their impact, cause, recurrence, and the level of risk they introduce to the protocol.
This Framework is not intended to be an exhaustive catalogue of all possible incidents. The Curated Module Committee may consider any conduct, technical configuration, response procedure, operational practice, or pattern of behavior that results in, or may reasonably be expected to result in, harm to the protocol, validators, stakers, withdrawal processing, rewards, security, or reputation.
2. Background and Rationale
Lido Node Operators are expected to perform duties reliably and safely, including attesting, proposing blocks when selected, maintaining validator keys securely, and following protocol and module-specific operational requirements. Failures in validator operation may lead to missed rewards, penalties on the Ethereum consensus layer, delayed withdrawals, slashing, execution layer reward leakage, reputational harm, or other direct and indirect losses.
The objective of penalties is not punitive for its own sake. Penalties are intended to:
- compensate the protocol for identifiable losses, missed rewards, or improperly redirected rewards;
- discourage conduct that creates avoidable operational, security, or reputational risk;
- encourage timely remediation and cooperation by Node Operators;
- protect stakers and the protocol from bearing losses caused by preventable or conduct that does not comply with applicable Lido policies, requirements, or operational standards;
- preserve the integrity and reliability of the Curated Module v2.
At the same time, not every incident should necessarily result in a penalty. Some incidents may arise from client bugs, relay-level failures, network-wide events, planned migrations, coordinated risk-mitigation decisions, or other circumstances outside the reasonable control of a Node Operator. In certain cases, temporary downtime or a controlled operational response may be the safer course of action, for example where immediate key migration could increase slashing risk. The CMC and NOM team should therefore assess each incident case by case.
3. Core Principles
The following principles should guide the assessment of incidents (described in more detail in the Section 7) and the application of penalties.
3.1 Case-by-case assessment
Each incident should be assessed based on its facts. The presence of a listed incident category does not automatically require a penalty. Conversely, the absence of an incident type/category from this Framework does not prevent the CMC from considering a penalty where it is reasonable to do so, including where the incident caused or may reasonably be expected to have caused losses, missed rewards, withdrawal delays, security risks, reputational harm, or other damage to the protocol.
3.2 Proportionality
Any penalty should be proportionate to the actual or reasonably estimated harm, including direct penalties, missed rewards, improperly redirected rewards, additional operational costs, risk introduced to the protocol, and any relevant aggravating or mitigating factors.
3.3 Accountability for preventable harm
Node Operators are expected to maintain robust infrastructure, secure key management practices, appropriate monitoring, and timely communication channels. Where harm results from preventable misconfiguration, negligence, non-compliance, lack of monitoring, inadequate redundancy, insufficient responsiveness, or intentional misconduct, the CMC may apply penalties and/or recommend additional measures.
3.4 Preservation of protocol safety
The framework should not incentivize unsafe remediation. Where a Node Operator, in coordination with NOM contributors or other relevant Lido contributors, takes conservative action to reduce slashing, key compromise, or systemic risk, such conduct should be assessed in light of the risk avoided, even if it results in temporary downtime or missed rewards.
3.5 Non-exhaustiveness and discretion
The categories and examples in this Framework are illustrative and non-exhaustive. The CMC may determine that other incidents, combinations of incidents, or repeated lower-severity incidents justify a penalty or other response.
4. General Delayed Penalty Mechanism
The General Delayed Penalty is the primary mechanism contemplated by this Framework for manually reported violations or losses that are not fully handled by an automatic penalty mechanism.
Under the General Delayed Penalty process, the CMC may report a penalty amount intended to compensate for the violation or loss, together with the applicable fixed fine specified in the CMv2 parameters. Once reported, the relevant amount is locked from the Node Operator’s bond. Depending on the subsequent outcome, the Node Operator may compensate the penalty, the locked bond may be subject to burn through the applicable governance or Easy Track process, or the locked bond may be released if the relevant the compensation was sent directly or the CMC didn’t take further steps to apply the penalty over a certain period of time (see parameters).
5. Assessment Factors
When deciding whether to apply a penalty and how to determine its amount, the CMC and NOM team should consider the following factors, where relevant:
- Impact: the amount of ETH, number of validators, rewards, penalties, withdrawals, or users affected;
- Duration: whether the incident was isolated, prolonged, repeated, or recurring;
- Cause: whether the incident resulted from negligence, misconfiguration, insufficient monitoring, external dependency failure, client bug, relay issue, deliberate misconduct, or other cause;
- Intent: whether the conduct appears accidental, negligent, or malicious;
- Preventability: whether reasonable infrastructure, monitoring, configuration, or operational practices could have prevented or reduced the incident;
- Responsiveness: how quickly and constructively the Node Operator acknowledged, investigated, communicated, and remediated the incident;
- Coordination: whether the Node Operator coordinated with NOM contributors or other relevant Lido contributors before taking actions that could affect validators or protocol performance;
- Transparency: whether the Node Operator provided complete and accurate information, including timelines, root cause analysis, affected validators, and remediation steps;
- Recurrence: whether the Node Operator has a history of similar incidents or unresolved operational concerns;
- Risk avoided: whether the Node Operator’s conduct, even if resulting in downtime or missed rewards, was a reasonable action to avoid greater harm, such as slashing or key compromise;
- Evidence quality: whether the loss or violation can be measured precisely or must be estimated using reasonable assumptions.
6. Incident Review and Decision Process
The following process should generally apply, subject to urgency, governance requirements, and the need to protect the protocol. As a general division of responsibilities, the NOM team is expected to perform incident detection, initial analysis, loss calculation, evidence collection, and communication with the Node Operator. The CMC is expected to assess the materials provided by the NOM team and the Node Operator and to decide whether a penalty should be settled, reported, escalated, or not applied.
6.1 Detection and Initial Review
Incidents may be identified through monitoring, validator performance data, relay or builder data, execution layer reward analysis, exit monitoring, key submission checks, public reports, community reports, Node Operator self-reporting, or other sources.
The NOM team performs an initial review to determine whether an incident should be opened. An incident may be opened where a threshold is met, where a material risk is identified, or where the circumstances otherwise warrant investigation. At this stage, the NOM team may also make an initial determination of whether urgent mitigation or additional information from the Node Operator is required.
6.2 Information Gathering
The NOM team collect information, including but not limited to:
- incident timeline;
- affected validators or keys;
- root cause analysis;
- infrastructure or configuration details;
- relay, builder, fee recipient, or reward flow evidence;
- available data required to estimate or calculate missed rewards, penalties, rerouted rewards, or other protocol losses;
- remediation actions already taken or planned by the Node Operator.
Node Operator’s failure to provide timely and complete information may be considered an aggravating factor.
6.3 NOM Analysis and Loss Calculation
Following the initial review and information gathering, the NOM team prepares the relevant materials for the CMC. These materials may include the incident description, available evidence, Node Operator submissions, proposed root cause, affected validators or rewards, estimated or actual losses, and any relevant mitigating or aggravating factors.
Where the incident resulted in missed rewards, Ethereum consensus layer penalties, rerouted execution layer rewards, withdrawal delays, or another measurable form of protocol harm, the NOM team should calculate or reasonably estimate the loss based on available data. Where precise calculation is not possible, the NOM team may use conservative estimates, documented assumptions, or other reasonable calculation methods.
6.4 CMC Review
The CMC review the incident, relevant evidence, NOM team analysis, Node Operator submissions, and any other applicable information. The CMC may determine that:
- no penalty is warranted;
- further information or monitoring is required;
- voluntary compensation by the Node Operator is appropriate;
- a General Delayed Penalty should be applied;
- the Node Operator’s allocation, participation in the Curated set, or type should be reviewed;
- the matter should be escalated to governance or other relevant bodies.
6.5 Voluntary Compensation Fast Track
Where the NOM team, the CMC, and the Node Operator mutually agree on the incident assessment and compensation amount, the Node Operator may compensate the relevant amount voluntarily as a fast track mechanism.
In such cases, the Node Operator may send the agreed compensation directly to the Lido Execution Layer Rewards Vault, following the approach currently used in CMv1. This route may simplify the process where the Node Operator is responsive, the amount is agreed, and no further escalation is required.
Voluntary compensation does not prevent the CMC and the NOM team from requiring further remediation, post-incident explanation, monitoring, or other non-penalty measures where appropriate. However, where the compensation is timely made and the incident is otherwise resolved, the CMC may decide not to proceed with the General Delayed Penalty mechanism.
6.6 General Delayed Penalty Settlement
Where the Node Operator is not responsive, does not provide sufficient information, does not compensate the agreed or assessed amount, disagrees with the proposed settlement without providing a satisfactory basis, or where the incident otherwise requires formal reporting, the CMC may proceed with the General Delayed Penalty mechanism described in this Framework.
In this case, the CMC may report the penalty amount through the applicable CMv2 process. The reported amount should be based on actual or reasonably estimated protocol harm, including missed rewards, Ethereum penalties, rerouted or missing execution layer rewards, and any other relevant loss, together with fixed fine under the CMv2 parameters.
6.7 Forum Communication and Node Operator Disagreement
Each reported penalty should be communicated by the CMC through the Lido Research Forum. The communication should generally include a description of the incident, the basis for the penalty, the affected category of harm, and the calculation or estimation approach used, subject to any confidentiality, security, or operational limitations.
If a Node Operator disagrees with the NOM team’s assessment, the CMC’s decision, the proposed compensation amount, or the application of a General Delayed Penalty, the Node Operator may present its position through the relevant Research Forum thread. The Node Operator may provide additional evidence, alternative calculations, explanation of mitigating circumstances, or any other information it considers relevant.
The CMC may take the Node Operator’s forum submission into account before taking further steps, where the timing and circumstances allow. However, disagreement alone does not suspend urgent protective measures, incident escalation, or penalty-related actions where the CMC determines that such actions are necessary to protect the protocol.
6.8 Communication and Remediation
Where appropriate, the Node Operator should be informed of the incident determination, the basis for any penalty, and any expected remediation actions. Urgent protective actions may be taken before the investigation is fully complete where necessary to protect validators, stakers, or the protocol.
7. Indicative Penalty Treatment by Case Type
The following table provides indicative treatment for common incident types.
| Incident type | Indicative opening trigger | Assessment focus | Indicative penalty basis |
|---|---|---|---|
| Validators offline | More than 2048 ETH affected for more than 0.5 hours, or other material downtime pattern | Cause, preventability, coordination, responsiveness, number and balance of affected validators, missed rewards, penalties | Consensus layer penalties plus missed rewards, where attributable to the Node Operator |
| Low performance | Performance (RAVER) below NET.AVG - 3% for 7 days, or another material deviation from expected performance | Number and balance of affected validators, root cause, remediation, recurrence. For Decentralization Operator type, the applicable deviation or tolerance may differ, taking into account that such operators may maintain more challenging setups while contributing to the decentralization and resilience of the protocol. | Missed rewards and penalties reasonably attributable to the underperformance |
| Validator slashing | Any slashing event affecting a validator operated in CMv2 | Cause, key handling, correlated risk, final losses, remediation, the speed of reaction | Ethereum penalties, missed rewards, and other losses once determined or reasonably estimated |
| Out-of-order exit | Exit conducted outside the expected process | Cause, missed rewards, coordination, responsiveness | Missed rewards caused by the stake being non-productive (exit/entry queues), where attributable to the Node Operator |
| EL rewards rerouting | Incorrect fee recipient caused rewards being sent to wrong address | Amount rerouted, intent, recurrence | Amount of rerouted EL rewards |
| Relay, builder, and MEV policy violations | Failure to use the highest available bid, unrecognized builder payment, use of a disallowed relay, failure to use required relay sets, incorrect minimum bid, or other relay, builder, or MEV-related configuration inconsistent with applicable requirements | Cause, affected proposals or blocks, available data, configuration, duration, and whether the incident caused missed or misdirected rewards | Missed rewards, estimated missed rewards, or misdirected rewards where applicable |
Other incidents that cause or may reasonably be expected to cause penalties, missed rewards, withdrawal delays, reward leakage, key compromise risk, slashing risk, operational burden, or reputational harm may also be considered by the NOM team and the CMC. The CMC may apply a General Delayed Penalty or other measure where it determines that doing so is necessary or appropriate to protect the protocol.
8. Review and Amendment
This Framework is intended to be adopted through the Lido DAO governance process. By approving this version of the Framework, the DAO establishes the baseline rules, principles, and processes for penalty assessment within CMv2.
It is also proposed that the Curated Module Committee gets authorized to make updates to this Framework without requiring a full DAO vote, provided that such updates do not materially alter the core principles, penalty mechanisms, or governance structure defined herein.
Within this delegated scope, the CMC may update or refine:
- thresholds, benchmarks, and indicative triggers;
- calculation methodologies and estimation approaches;
- examples, clarifications, and explanatory language;
- operational procedures that do not materially affect Node Operator rights or obligations;
- categorization or consolidation of incident types where the underlying principles remain unchanged.
Any changes that materially affect the scope of penalties, introduce new penalty mechanisms, significantly alter Node Operator obligations, or modify the governance or decision-making authority described in this Framework should be subject to DAO approval through the standard governance process.
The CMC should communicate any updates made under its delegated authority through the Lido Research Forum, ensuring transparency and allowing for community review and feedback.
, the