A staking team receiving a slashing alert faces several questions at once. Which validators are affected? Is the behaviour continuing? Which client assets are exposed? Can the team safely move signing to another system? A runbook written around those questions is more useful than a generic instruction to restart infrastructure as quickly as possible.
Ethereum's proof-of-stake documentation distinguishes slashing from ordinary penalties and explains that correlated slashing can increase losses. EIP-3076 describes an interchange format for slashing protection data. Together they point to an operational priority: understand signing history and prevent further unsafe signing before attempting recovery.
Establish what the alert means
Do not treat every missed attestation or lost reward as a slashing incident. Confirm the evidence and validator identifiers using the relevant network records. A service-provider notification is useful, but the institution should retain its own record of the affected keys, time window and account mapping.
Classify what is known and what remains uncertain. The initial report might identify one validator while a shared deployment process puts others at risk. Assign an incident owner to maintain that distinction. An early client update should avoid turning a provisional list into an assertion that the problem is fully contained.
Contain unsafe signing
A failover that brings two instances of the same validator key online can create further danger. The runbook should identify how signing is disabled, how duplicate instances are detected and who can authorise a restart. Recovery speed is an operating objective, but it must be constrained by signing safety.
Slashing protection information belongs in the recovery plan. The interchange proposal describes a way to transfer that data across clients; using a format does not by itself prove a migration is safe. The team still needs to validate exports, imports, network identifiers and source shutdown according to its actual client implementation.
Preserve an evidence trail
Retain client versions, configuration changes, deployment records, signing logs and relevant infrastructure timestamps. Protect the evidence from automatic log rotation and routine clean-up. Keep access controlled so incident investigation does not introduce a new path to signing keys.
A reconstruction should show the sequence of actions and the scope of shared dependencies. Was a key imported twice, did an automation retry unexpectedly or did a migration omit protection history? These are questions to investigate, not assumptions about the cause. Record corrections to the timeline rather than quietly overwriting the original account.
Reconcile financial exposure
Map each affected validator to the beneficial owner and the contractual service arrangement. Explain which balances and rewards are affected, what can be measured immediately and what depends on subsequent protocol outcomes. Avoid presenting a single initial deduction as the complete economic loss where additional penalties or withdrawal effects remain possible.
Ethereum's documentation describes correlation-sensitive losses. Institutions should therefore assess the wider incident context rather than assume an isolated-validator outcome. Do not reuse a penalty estimate from an older network version without checking the applicable rules. Our institutional staking risk and reward article covers the investment perspective; an incident ledger needs greater account-level detail.
Keep compensation separate from protocol loss
A provider's promise to cover certain losses is a contractual claim. Establish the covered events, exclusions, evidence requirements and payment process. The institution should report the protocol loss separately from an expected reimbursement until its accounting and legal treatment has been assessed.
If an insurer or provider needs prompt notification, assign responsibility for delivering it and preserving proof. A technically competent response can still fail commercially if the required notice is missed. Include customer communications, finance and legal teams in the incident structure so each works from the same reconciled facts.
Make restart a documented decision
Restart approval should require evidence that the unsafe condition has been removed and that protection history is usable. Test the relevant migration or failover process in a controlled environment before relying on it again. Close the incident only after reconciling affected accounts and recording corrective actions with owners.
The broader question of shared dependencies appears in our analysis of restaking and shared security. A slashing runbook converts that concern into specific operating decisions: identify the scope, contain signing risk, preserve evidence and account for the outcome. Those decisions should be rehearsed before the first production alert.