Going offline does not itself slash an Ethereum validator. It can cause missed rewards and duty penalties, while prolonged network nonfinality can activate an inactivity leak. Slashing requires evidence of specific conflicting signatures; processing it marks the validator slashed, initiates an exit if needed, and can include an initial deduction plus a later correlation penalty. Diagnose the event from duties, finality and signing evidence before estimating the loss.
A red uptime monitor describes availability. It does not, by itself, identify which protocol rule changed the validator's balance.
Start with the event, not a percentage
Keep these four entries separate when reading an incident report:
| Event | What must be established | What follows |
|---|---|---|
| Missed duty | A required duty was not performed or credited correctly | Missed rewards and applicable participation penalties |
| Inactivity leak | The network's measured finality delay exceeds its threshold | Additional inactivity accounting for affected validators |
| Slashing | Valid evidence satisfies a slashable signing condition | Slashed status, an exit initiated if needed and an initial deduction |
| Correlation assessment | A slashed validator reaches its scheduled assessment epoch | A further deduction based on relevant slashed stake and network state |
Even ordinary downtime has several accounting effects. Missing a block proposal forfeits its reward without a separate missed-proposal penalty. Missing source or target attestation participation can deduct ETH; missing the head component loses its reward without that component's direct penalty. Ethereum's rewards and penalties explanation distinguishes these duties. Sync committee participation has separate accounting.
That distinction matters when comparing actual balance with an imagined perfect-uptime balance. If an account lost 0.001 ETH and also missed a hypothetical 0.001 ETH reward, the actual deduction is 0.001 ETH. The shortfall against that hypothetical reward path is 0.002 ETH. Calling both numbers “the penalty” obscures the comparison.
An annualized reward display cannot identify the cause either. Use the staking APR versus APY ledger to separate reward measurement, compounding and deductions before interpreting a changed rate.
When downtime becomes a network problem
One validator's outage does not set the network's inactivity-leak mode. The inherited consensus helper measures finality delay as the previous epoch minus the finalized checkpoint's epoch. Leak mode applies when that result is greater than four, according to the finality-delay predicate.
Consider a hypothetical sequence of evaluations. With previous epoch 200 and finalized epoch 196, delay is four: the predicate is false. If the finalized checkpoint remains 196 while the previous epoch advances to 201 and 202, delays become five and six: it is true. If a later evaluation has previous epoch 203 and finalized epoch 202, delay is one: it is false again. These are constructed state inputs, not an observed mainnet outage.
The leak is intended to help restore finality by reducing inactive stake's weight. Finality depends on a supermajority of stake participating appropriately, so a widespread failure differs from one disconnected operator. This mechanism does not require evidence that an offline validator signed conflicting messages. Ethereum's inactivity-leak overview explains that recovery purpose.
Individual participation still matters. The inactivity-score accounting tracks timely target participation and changes score recovery outside leak mode. Leaving leak mode does not mean every validator's score has instantly returned to zero. Inspect the recorded score and subsequent balance changes rather than treating a network recovery announcement as a complete account reconciliation.
Which signatures can trigger slashing?
Ethereum's inherited slashing checks distinguish three conflicts:
- Double proposal: the same proposer signs different block headers for the same slot.
- Double vote: a validator signs different attestation data with the same target epoch.
- Surround vote: one attestation's source-to-target interval strictly surrounds another's.
The eligibility window can extend beyond active duties. An activated validator that is not already slashed remains slashable before its recorded withdrawable epoch, including after its exit epoch. Scheduling an exit therefore does not cancel previously signed conflicting evidence. The validator slashability predicate defines that boundary.
For a numerical surround example, source 190 to target 205 surrounds source 197 to target 200 because 190 is less than 197 and 200 is less than 205. Merely seeing two attestations at different times does not establish either conflicting condition.
The protocol evaluates signed evidence, not an operator's intention. An accidental failover can therefore create a slashable conflict. Conversely, owning two machines or rebroadcasting the same signed message does not automatically prove a slashable pair; the messages and validator identity must satisfy the checks.
A dangerous migration mistake is moving a signing key without its current signing history. EIP-3076 explains why a keystore alone cannot tell the replacement client what the key already signed. Its interchange format addresses that history transfer; it does not make arbitrary concurrent operation safe.
Follow one hypothetical failover incident
Assume an active validator has a 32 ETH effective balance, no exit is already scheduled, and the network continues finalizing normally throughout this incident. N is an arbitrary reference epoch. The events below are invented to distinguish failure states.
| Hypothetical time | Operator or chain observation | Diagnosis |
|---|---|---|
| Epoch N | Primary signer works normally | No incident |
| N + 1 through N + 6 | Primary loses connectivity and misses its attestations | Six missed-duty epochs; no conflicting signatures stipulated |
| N + 7 | Operator starts a backup with the same key but incomplete protection history; primary can restart unattended | Unsafe overlapping signing capability |
| N + 8 | Both sign different attestation data with target epoch N + 8 | A slashable double-vote pair exists |
| N + 9 | Valid evidence is included and processed while the validator is slashable | Slashed flag is set, exit is initiated and initial deduction applies |
| Later assessment | The relevant correlation calculation becomes due | Reconcile its deduction separately |
The mainnet configuration specifies a 12-second slot. With 32 slots per epoch, six complete epochs span 6 × 32 × 12 = 2,304 seconds, or 38 minutes 24 seconds. This duration does not determine an exact offline penalty: participation, effective balance, network totals and assigned duties still matter.
The key change occurs at N + 8. Restoring connectivity did not repair the incomplete signing-history boundary. It allowed two signers to create conflicting evidence. If no such conflict had been signed, the six missed epochs would remain a downtime event under the scenario's normal-finality assumption.
For a migration, follow the selected client's procedure and positively isolate the old signer. EIP-3076 recommends exporting protection history only while the signer or validator client is stopped, and importing while the receiving client is stopped. An old export can omit messages signed after that export.
Calculate the initial and correlation deductions separately
The calculations here use Electra's slashing rules inherited by the stable Fulu specification, as listed in the consensus specification index on 28 October 2026. For an actual incident, use the fork active at its epoch.
The Electra slashing function computes the initial deduction by integer-dividing effective balance in Gwei by 4,096. In the hypothetical 32 ETH case:
32,000,000,000 Gwei ÷ 4,096 = 7,812,500 Gwei = 0.0078125 ETH
This is one specified component for that balance and rule set. It is not the total loss or a universal slashing quote.
Now construct two alternative states at the later correlation assessment. In each, assume total active effective balance is 40 million ETH and this validator's effective balance is still 32 ETH. These are hypothetical inputs, not estimates of current stake. The relevant slashings window contains either only 32 ETH or 40,000 ETH of slashed effective balance.
Electra's correlation calculation adjusts the window total using the inherited multiplier of three, capped at total active balance. It then uses integer division per 1 ETH effective-balance increment.
| Hypothetical assessment input or result | Isolated window | Larger slashed window |
|---|---|---|
| Windowed slashed effective balance | 32 ETH | 40,000 ETH |
| Adjusted amount after multiplying by three | 96 ETH | 120,000 ETH |
| Correlation deduction for the 32 ETH validator | 0.0000768 ETH | 0.096 ETH |
| Initial plus correlation deductions | 0.0078893 ETH | 0.1038125 ETH |
For the larger window, the adjusted share is 120,000 / 40,000,000 = 0.003. Multiplying by 32 ETH gives 0.096 ETH. Recomputing the specified integer-Gwei steps gives the same result for these inputs.
The two-deduction subtotal excludes participation penalties and foregone rewards during the incident and slashed period. Effective balance can also change before assessment. A quote for the initial deduction cannot settle those unknowns, and a small isolated example cannot bound a widespread event.
Slashing also extends the withdrawable epoch to at least the slashing epoch plus the 8,192-epoch slashings-vector length. The correlation check runs when the current epoch is exactly 4,096 epochs before that recorded withdrawable epoch, half the vector length. Electra's slashing and correlation functions specify both conditions.
If an exit was already scheduled, the exit initializer preserves it; the slashing function can still extend the withdrawable epoch. Electra's exit initializer makes that distinction. Read the actual exit and withdrawable fields; neither processing the evidence nor reaching an eligibility field proves ETH has arrived in a withdrawal wallet.
Identify whose balance and obligation you hold
A protocol deduction removes ETH from a validator balance. A fall in ETH's dollar price is a valuation change. A staking receipt can also trade at a different market price from the claim it represents. Keep those three records separate.
If you stake through a provider, establish which validators back your claim and how the provider allocates deductions, fees or compensation. Consensus rules do not establish a provider's reimbursement promise. The staking ratio and liquid supply guide explains why a transferable receipt and completed native withdrawal are different states.
Additional commitments need additional evidence. The restaking versus staking comparison separates Ethereum validation exposure from obligations introduced by another service. Do not assume this article's three Ethereum signing conditions describe every possible restaking penalty.
The same identity discipline applies when reconciling other balances in the account. The native versus bridged USDC guide traces different chain and backing relationships behind a familiar ticker. A bridge claim, a provider receipt and a native validator balance need their own incident explanations.
Keep a restart and loss worksheet
Record these fields before treating an alert as resolved:
- Validator identity and rules: network, validator index and public key, incident epochs, active fork, actual balance and effective balance. Never put secret signing material into the worksheet.
- Duty and finality evidence: credited and missed duties, the previous and finalized epochs used for each leak check, and any remaining inactivity score.
- Signing boundary: every process capable of signing for that key, client versions, proof the previous signer is isolated, the protection-history export time and successful import evidence.
- Slashing state: the conflicting signed data if present, evidence inclusion, slashed flag, exit epoch and withdrawable epoch. Keep “suspected” separate from accepted on-chain evidence.
- Reconciliation: opening balance plus credited rewards and incoming transfers, minus identified deductions and outgoing transfers, equals closing balance. List initial and correlation deductions separately; record foregone rewards only against an explicit comparison path.
For a failover, the next actionable record is proof of which signer is disabled, where its final protection history was imported, and which validator state was checked before the replacement signs. A green process status alone cannot supply those facts.