Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Research · Ethereum

Slashing

Slashing is not the penalty for being offline. It applies to two specific offences — proposing two blocks in one slot, and signing two conflicting attestations — and the amount burned scales with how many validators offend at the same time.

Last reviewed 2026-09-21Source: Ethereum Consensus Specs (Phase 0) and ethereum.org slashing documentationConditions and mechanics as specified; no penalty amounts are stated as fixed figures.

The two slashable offences

Ethereum's consensus specification defines exactly two offences that are slashable, and both are attacks on the chain's ability to agree on one history. The first is proposing two different blocks for the same slot. The second is signing two conflicting attestations — two votes with the same target checkpoint that disagree about the source, or two votes that surround each other in a way that lets a validator support two conflicting chains. A validator that simply goes offline commits neither offence and is not slashed.

The narrowness of the definition is the point. Slashing is a punishment for equivocation, and equivocation is what an attacker needs in order to convince part of the network that one chain is canonical while convincing another part of a different one. A validator that is merely absent reduces the weight available to finalise, which the inactivity leak handles; a validator that signs two conflicting messages actively undermines the agreement the protocol depends on, which is what slashing addresses.

The practical consequence is that the risk of slashing is almost entirely an operational risk rather than a market risk. A validator is slashed when the same key signs two conflicting messages, which happens when two machines are running the same validator key at the same time, or when a key is migrated without the old instance being shut down first. That is why the standard advice for validator operators is to ensure that a key is active in exactly one place, and why the tooling for migrating a validator includes explicit safeguards against running two copies.

The correlation penalty

How the penalty for a slashable offence scales with the number of validators slashed in the same window.
CaseHow the penalty scalesWhat it implies
A single validatorA base amount proportional to the validator's balanceConsistent with an operational mistake rather than an attack
A small groupSlightly above the base amountStill consistent with a shared operational failure
A large share of the stakeScales up with the share slashed in the same windowTreated as evidence of a coordinated attempt to split the chain
A supermajorityApproaches the loss of the entire bondMakes a successful attack economically self-defeating

Last reviewed 2026-09-21Source: Ethereum Consensus Specs, Phase 0 — Honest ValidatorThe scaling rule is specified; the interpretation column is the author's analysis.

The correlation penalty is what makes the mechanism a deterrent rather than a fee. If every slashed validator lost the same fixed amount, an attacker with a large stake could treat the penalty as a cost of doing business: pay it, split the chain, and profit from the confusion. By making the penalty grow with the number of validators slashed in the same window, the protocol ensures that the cost of an attack scales with the size of the attack, so a large coordinated offence is punished far more heavily than a large number of independent mistakes.

The design has an acknowledged tension. A correlated failure — a shared client bug, a common hosting provider outage, a coordinated key-management mistake — would be treated by the protocol as though it were an attack, and the validators involved would lose far more than the base amount. That is a real risk, and it is one of the reasons the ecosystem places weight on client diversity: if every validator runs the same implementation, a bug in that implementation is a correlated event, and the penalty for it is the attack penalty.

The penalty is burned rather than paid to anyone. A slashed validator's balance is reduced and the ether is removed from circulation, so slashing is not a transfer from the offender to the honest participants. That matters for how the mechanism is understood: it is a destruction of the offender's capital, not a reward for catching them, and no participant profits from a slashing event.

Ejection and the exit queue

A slashed validator is ejected from the active set immediately. It stops receiving duties, so it stops earning, and it enters a queue before its remaining balance becomes withdrawable. The queue is not an additional punishment so much as a delay: it gives the protocol time to detect any further offences from the same validator and to apply the correlation penalty across the full window, and it prevents a slashed validator from withdrawing and re-depositing under a new key before the penalty has been fully assessed.

The exit queue is shared with ordinary voluntary exits, and its throughput is bounded by the protocol. That bound exists for the same reason the entry queue does: the size of the active set is a security parameter, and a mechanism that let the set shrink without limit would let a large group of validators leave at once and reduce the stake securing the chain below the level the protocol assumes. A mass exit is therefore spread over time rather than executed at once.

For a validator operator, the practical summary is that slashing is avoidable and its cause is almost always a key-management error. The defences are procedural rather than technical: run one instance per key, verify that the previous instance is stopped before starting a new one, use a signer that refuses to sign conflicting messages, and keep the withdrawal credentials under separate control from the signing key. None of those is enforced by the protocol, and all of them are the operator's responsibility.

Sources and references

The slashable conditions, the correlation penalty and the ejection described above are taken from Ethereum's consensus specification and its developer documentation.

  • The two slashable offences. Ethereum Consensus Specs, Phase 0 — Honest Validator: proposing two conflicting blocks and signing two conflicting attestations are the offences, and slashing burns funds and ejects the validator.
  • Rewards, penalties and the correlation rule. ethereum.org, Rewards and penalties: how slashing differs from the inactivity penalty and how the penalty scales.
  • The beacon-chain parameters. Ethereum Consensus Specs, Phase 0 — The Beacon Chain: the slashing and correlation constants, and the exit-queue parameters.
  • Operational guidance for validator keys. ethereum.org, Solo staking: the requirements for running a validator and the key-handling practices that avoid a slashing event.

Related reading