Lido staking can lose ETH through downtime penalties or validator slashing

Attestations, proposals and sync duties produce staking rewards

Ethereum validators earn consensus rewards for timely attestations, successful block proposals and assigned sync committee participation, with each duty contributing differently to their staking results. Attestations vote on the chain and its checkpoints. A selected proposer publishes a block, while sync committees help light clients follow the chain. Proposals can also bring execution rewards from transaction tips and block-building activity. Participating node operators perform these duties for the Core pool. Their missed opportunities reduce its earnings before any separate penalty enters the calculation.

Downtime can reduce stake without triggering slashing

A validator that misses required attestation components can incur ordinary balance penalties even when Ethereum continues finalizing normally. Lost rewards and deducted stake represent different parts of the damage. An outage can cause both, although its eventual effect on pooled returns also includes the performance of unaffected validators.

Missed attestation components

Attestations contain source, target and head votes. Missing timely source or target participation can deduct a component of the validator’s base reward. Missing the timely head vote forfeits its reward without a separate head-vote penalty. The base reward depends on effective balance and total active stake, so an hour offline has no universal ETH cost. Duty performance also includes timeliness; a running server can still miss reward requirements.

Missed block proposals

Failing to propose an assigned block forfeits the available proposal income without adding a separate consensus penalty for that omission. An active validator can resume earning through later successful duties after ordinary downtime. Reconnection does not refund penalties already charged. Prolonged balance depletion can eventually cause ejection under Ethereum’s rules, which remains distinct from a recorded slashing offense.

Finality loss changes the cost of being offline

Ethereum enters an inactivity leak when its finality delay exceeds four epochs. Finality requires checkpoint agreement from at least two-thirds of total active effective stake. Missing that threshold changes the penalty environment for validators that miss timely target votes. Their inactivity scores contribute to additional deductions. The mechanism reduces inactive stake’s relative weight, helping participating validators regain the share that they need to finalize the chain.

The same downtime duration can therefore produce different losses during normal finality and a network-wide disruption. Restored participation improves an affected validator’s position; finality recovery ends the network’s leak condition.

Slashing adds an initial loss and a later correlation penalty

Slashing begins when Ethereum accepts valid evidence of a slashable signing conflict involving an eligible validator. It marks that validator as slashed and initiates an enforced exit, with consequences that extend beyond the initial deduction.

The initial deduction and withdrawal boundary

The initial penalty derives from effective balance under the applicable consensus rules. It does not represent the complete loss. Slashing sets validator withdrawal eligibility no earlier than 8 192 epochs after the slashing epoch. An existing later withdrawal schedule can extend that boundary. This restriction belongs to the affected validator; it does not set a universal waiting period for every stETH holder.

The correlation component

A later penalty scales with the effective stake slashed within the protocol’s slashing window, relative to total active stake. Closely timed slashings can therefore impose much larger losses than an isolated event. Continuing participation penalties can add to the total. The first reported deduction is insufficient to establish the final cost while these components remain unresolved.

Validator incidents have different recovery boundaries

Ordinary missed duties preserve the possibility of returning to validation while the validator remains active; slashable conflicts initiate exit and extend withdrawal eligibility. Any subsequent operator-bond settlement or token-accounting adjustment happens under the relevant staking arrangement, so the validator’s gross loss and the holder’s eventual loss need not match.

Pool accounting determines the effect on stETH holders

Validator losses enter the Core pool’s aggregate results alongside rewards, so an individual penalty does not automatically produce a negative token rebase. Earnings elsewhere in the pool can offset a loss. The net outcome also reflects applicable compensation and other accounting adjustments.

An stETH account holds shares whose token balance follows the protocol’s pooled-ETH accounting. When net losses reduce the backing per share, a negative rebase can reduce the account’s stETH balance without an outgoing transfer.

Wrapping changes how the same exposure appears. A wstETH balance does not change with a rebase, but the amount of stETH represented by each wrapped token does. A negative rebase can lower that conversion amount despite an unchanged token count.

A secondary-market discount is a separate measurement. Trading demand and available liquidity can move the exchange price independently of an accounting loss. A token quote therefore cannot identify which validators incurred penalties.

Report checks govern when accounting recognizes losses

OracleReportSanityChecker applies configured limits to reported balance changes before the protocol accepts an accounting update. A decline beyond its allowance requires confirmation from a configured Second Opinion Oracle; without that oracle, the oversized report fails the check. Its getOracleReportLimits() view exposes the active limits. These settings govern report acceptance and can change through authorized updates. They do not cap penalties that Ethereum can impose on validators. A reporting delay may separate an underlying balance loss from its appearance in token accounting.

Unresolved losses can delay withdrawal finalization

Bunker mode responds to detected or anticipated negative Consensus Layer rebases and can impose stricter withdrawal-finalization boundaries. Mass slashing can trigger those conditions, as can sufficiently severe validator penalties without slashing. The mechanism limits early withdrawals that would leave unresolved losses with remaining holders. An incomplete slashing associated with a withdrawal request can prevent that request’s finalization. An incomplete, unrelated slashing does not automatically block every request. The relevant accounting frame and safe finalization borders determine the scope.

Finalization also requires available ETH. If losses push the share rate below its level when a withdrawal request was created, finalization can allocate less ETH than the stETH amount submitted. A validator’s withdrawal eligibility, the resolution of its penalties and a token withdrawal request’s eligibility describe separate constraints. A fixed calendar estimate cannot replace those conditions during an incident.

Bonds and vault collateral change who absorbs losses

Operator bonds provide security collateral that can absorb assessed losses, with their amount and treatment determined by the staking module. In the Community Staking Module, slashing-related losses are assessed after the validator’s withdrawal and deducted from the operator’s bond. A bond covers the operator’s validator set rather than constituting the same stake that Ethereum penalizes. Bond requirements follow the applicable operator curve, so a fixed collateral figure cannot describe every operator.

stVaults use a separate staking position with collateral requirements when stETH is minted against its ETH. Penalties can reduce that collateral buffer and trigger health-restoration mechanisms. The owner can supply ETH or reduce the stETH liability; protocol rebalancing provides another response. Severe uncovered shortfalls can ultimately reach protocol-level loss sharing, so reserve requirements do not establish complete insulation from losses.

Operator diversification also has limits. Validators can share client software or infrastructure despite belonging to different operators. A common failure can produce correlated downtime or slashings, and collateral protection has to be assessed alongside that shared exposure.

Signed records distinguish the slashable offenses

Block proposals in the same slot

Proposer slashing requires conflicting signed block headers from the same validator for the same slot. A slot identifies a scheduled block opportunity. Proposals from different validators do not meet that same-signer condition. Running independent signing setups with the same validator key creates a route to conflicting signatures. Signing safeguards have to prevent conflicts during failover as well as routine operation.

Double votes and surround votes

Double voting means signing different attestation data with the same target epoch. A surround vote has an earlier source epoch and a later target epoch than another attestation signed by that validator. Source and target checkpoints establish the vote’s finality relationship. The signed records must satisfy the applicable conflict and signature checks before Ethereum can process slashing. Missing an attestation supplies none of that conflicting-message evidence.

Operator control and pooled exposure create different trade-offs

Solo staking places operational choices and their validator-level consequences with the validator operator. Core pooled staking delegates those operations across participating node operators and passes aggregate results into token accounting. Pooled staking reduces reliance on one validator’s performance, while correlated incidents can still affect a substantial part of the pool.

Direct operation permits control over client selection and signing safeguards. A pooled token holder instead relies on the operator set, module protections and accounting mechanisms, with less control over an individual validator’s recovery.

Open full-size image