Slashing: how proof of stake punishes cheaters

Carrot, stick, and the problem with free signatures

In December 2020, weeks after Ethereum's Beacon Chain went live, some of the very first validators ever punished were not attackers. They were careful operators who had done the sensible thing in any other system: they ran a backup. Two machines, the same key, both online — so that if one died, the other kept attesting. Then both signed the same duty, the network saw one validator vote twice, and the protocol destroyed part of their deposit. In ordinary operations redundancy is a virtue; in staking a naive hot backup is the single most dangerous thing you can build.

The previous guide showed the carrot: a validator that attests and proposes honestly earns a steady yield. But rewards alone cannot secure a chain. Under proof of work, building on two conflicting forks costs twice the electricity, so miners naturally pick one. Under naive proof of stake a signature is just a few bytes — signing every competing fork costs nothing and maximizes your odds of landing on the winning one. That is the nothing-at-stake problem, and if it stood, finality would be meaningless. Slashing is the answer: make signing two contradictory messages provably destroy your money.

The three ways to get slashed

On Ethereum there are exactly three slashable offenses, and all three are forms of equivocation — saying two contradictory things the network can both see and pin on you. One concerns block proposals; two concern attestations. Recall that an attestation is a vote for a `(source, target)` checkpoint pair — the building block Casper FFG uses to reason about finality.

1. Double block proposal. As a slot's chosen proposer, you sign two different blocks for the same slot. Two signed blocks, one slot — flat equivocation about which block you built.
2. Double vote. You publish two different attestations with the same target epoch. You voted for two conflicting versions of the very same checkpoint.
3. Surround vote. You publish an attestation whose `(source → target)` span strictly surrounds, or is surrounded by, an earlier attestation of yours — effectively trying to rewrite which history you already committed to.

Make the surround case concrete. Suppose at epoch 9 you attest `(source = 8, target = 9)`. Later you attest `(source = 6, target = 10)`. The second span `[6, 10]` strictly contains the first `[8, 9]`, since `6 < 8` and `9 < 10`. That is a surround vote. Why does the protocol care? Casper FFG finalizes a checkpoint only when a two-thirds supermajority links a source to a target across consecutive epochs (justification then finalization). A surround is exactly the move you would have to make to support two conflicting finalizations at once — so the rule turns any such attempt into self-incriminating evidence.

# Ethereum's two attester-slashing conditions (Casper FFG "commandments").
# An attestation votes for a (source, target) checkpoint pair.

def is_slashable_attestation(a1, a2):
    # 1) DOUBLE VOTE: two *different* attestations with the SAME target epoch.
    double_vote = (a1 != a2) and (a1.target.epoch == a2.target.epoch)

    # 2) SURROUND VOTE: a1's (source, target) interval strictly surrounds a2's.
    surround_vote = (a1.source.epoch < a2.source.epoch) and \
                    (a2.target.epoch < a1.target.epoch)

    return double_vote or surround_vote

# Proposer slashing is even simpler: two different signed blocks
# for the SAME slot, from the same validator  =>  equivocation.

The penalty: a lone slip vs. a coordinated attack

How much does a slash cost? Ethereum's answer is deliberately non-linear, and that design is the whole point. A slash has two parts: an immediate fixed bite, and a delayed penalty that scales with how many others were slashed alongside you.

The initial penalty. The moment your proof lands in a block, an immediate penalty is taken — about 1 ETH for a 32-ETH validator (effective balance ÷ 32 under current mainnet / Bellatrix parameters). You are flagged `slashed`, barred from earning, and pushed into the exit queue. A small whistleblower reward (~0.06 ETH, one part in 512 of your effective balance) goes to the proposer who included the proof — so policing the network is itself rewarded, and anyone can do it.

The correlation penalty — the clever part. A second penalty is applied roughly 18 days later, at the midpoint of a ~36-day window, and it scales with how much other stake was slashed inside that same window. Write the fraction `f = slashed_stake_in_window / total_active_stake`. If you were slashed alone, `f ≈ 0` and this penalty is almost nothing: your total loss is ~1 ETH, a survivable mistake. But if you were one of many validators slashing together — exactly the signature of a coordinated attack — a multiplier of 3 bites. Slash a third of all stake at once and the penalty caps at your entire balance.

# Roughly how Ethereum sizes a slashing penalty (mainnet / Bellatrix params).
EFFECTIVE_BALANCE = 32            # ETH, capped at 32 per classic validator

# (a) Immediate penalty, taken the moment you are slashed:
initial_penalty = EFFECTIVE_BALANCE / 32                 # = 1 ETH

# (b) Correlation penalty, applied ~18 days later (midpoint of a ~36-day window).
#     Scales with how much stake was ALSO slashed in that same window.
f = slashed_stake_in_window / total_active_stake
correlation_penalty = EFFECTIVE_BALANCE * min(3 * f, 1)

# Lone operator mistake :  f ~ 0     -> corr ~ 0      -> lose ~1 ETH (a few %)
# Attack with 1/3 stake :  f = 0.33  -> 3*0.33 = 1.0  -> lose EVERYTHING

This is the genius of the scheme: it draws a bright line between an accident and an attack. An honest operator who makes an isolated slip loses ~3% of stake and a few weeks of time; an adversary trying to revert finality with a third of the stake loses all of it — and because attestations are aggregated BLS signatures, the protocol holds the proof. (Honest footnote: newer upgrades let a single validator hold far more than 32 ETH of effective balance; the penalties scale with that balance, so the percentages above stay the same.) See validator economics for how this fits the broader reward math.

1. Someone observes two conflicting signed messages from validator V — anyone can, because they are public on the network.
2. They wrap the pair into a `ProposerSlashing` or `AttesterSlashing` and the next proposer includes it on-chain; the immediate ~1 ETH penalty hits and V is queued to exit.
3. While V waits in the queue it can no longer earn and keeps accruing ordinary attestation penalties for being inactive.
4. ~18 days in, the correlation penalty is applied, sized by the total stake slashed alongside V in the window.
5. ~36 days after the slash, V becomes withdrawable; whatever balance survives can finally be withdrawn.

It's almost never attackers — it's redundancy

Here is the honest, slightly anticlimactic truth: across years of mainnet, the overwhelming majority of slashings were not attacks at all. They were operators slashing themselves — and the leading cause is exactly the redundancy that ops engineers are trained to build. Run the same validator key on two machines for "high availability", and the day they are both online they will double-sign the same duty and manufacture your own slashing proof.

The largest single incident to date came in February 2021, when the staking provider Staked had roughly 75 validators slashed at once after a failover / redundant setup signed twice. No funds were stolen and no attack occurred — just one configuration mistake, multiplied across many keys. It is a vivid lesson in the correlation penalty: because those slashings clustered in time, they were collectively costlier than 75 unrelated ones would have been.

The defense is built into every serious validator client: a slashing-protection database. Before signing anything, the client checks a local record of the highest block slot it has ever proposed and the highest source/target epochs it has ever attested, and refuses to sign anything that could be slashable. A standard interchange format (EIP-3076) lets you export that history so it travels with the key when you migrate machines — the only safe way to move a validator.

{
  "metadata": {
    "interchange_format_version": "5",
    "genesis_validators_root": "0x04700007f..."
  },
  "data": [{
    "pubkey": "0xb845089a1457f811bfc000588fbb4e713669be8c",
    "signed_blocks":       [{ "slot": "81952" }],
    "signed_attestations": [{ "source_epoch": "2290", "target_epoch": "3007" }]
  }]
}

The inactivity leak: a softer punishment for a different sin

Slashing punishes saying two things. But what about saying nothing — simply going offline? That is not slashing at all; it is handled by a completely separate, much gentler mechanism called the inactivity leak, and understanding why the two are different is understanding the soul of the protocol.

In normal times a validator that is merely offline just misses rewards and pays tiny penalties roughly equal to what it would have earned — go dark for a day, lose about a day's yield, nothing dramatic. The leak only switches on in an emergency: when the chain fails to reach finality for more than four epochs, which can only happen if more than a third of all stake is offline at once (a cloud-region outage, a client bug downing many nodes). Without finality the chain is still alive and producing blocks, but it can no longer certify anything as irreversible.

During the leak, each validator carries an inactivity score that rises while it is offline-and-not-finalizing and decays while it is online. The per-epoch penalty is proportional to that score, so a validator that stays offline loses stake at an accelerating, roughly quadratic rate over time — while online validators leak nothing. The point is not revenge; it is recovery. By draining only the absent, the leak slowly shrinks their share of the stake until the validators who are online once again form a two-thirds supermajority of what remains — at which point the chain finalizes again (justification resumes) and the leak shuts off.

# Inactivity leak: only active when the chain FAILS TO FINALIZE for 4+ epochs.
# Each validator carries an inactivity_score:
#   offline & not finalizing  ->  score += 4    each epoch
#   online (or once finalized) ->  score -= 16   each epoch (decays toward 0)
#
# Per-epoch leak for ONE validator:
leak = effective_balance * inactivity_score / 16_777_216   # 2^24 (Bellatrix)
#
# score grows linearly with time offline  =>  cumulative loss grows QUADRATICALLY.
# Online validators' scores decay  =>  they are NOT leaked.
# Draining the absent shrinks their stake until the online set is again 2/3
# of the remainder  =>  finality resumes, leak stops.

So the two mechanisms guard two different promises, and lining them up is the cleanest way to hold the whole rung in your head. Slashing defends safety (never finalize two conflicting histories): triggered by equivocation, amplified by correlation, it ejects you and can cost everything. The inactivity leak defends liveness (keep making progress): triggered by mass absence, gentle and quadratic, it never ejects you for malice and reverses the moment you return. This is the safety-versus-liveness split made physical. A validator can be leaked below the 16-ETH floor and be force-exited for low balance — but that is an accounting consequence, not a slash: no crime, no whistleblower, no correlation multiplier.

Why this makes finality worth trusting

Step back and the architecture is elegant. Rewards make honesty profitable; slashing makes equivocation suicidal; the inactivity leak lets the chain heal after an outage instead of stalling forever. Together they turn "skin in the game" from a slogan into enforceable code, where the rules are upheld not by trusted referees but by the impossibility of profiting from breaking them.

This is the foundation of the next guide's idea: economic finality. Reverting a finalized checkpoint would require a two-thirds supermajority to vote for two conflicting histories — and that is by definition double-voting or surrounding. So at least a third of all staked ETH would be provably slashable in the very act of the reversal. Reorging finalized Ethereum does not merely need a majority of validators; it costs the attacker on the order of a third of all stake — millions of ETH, tens of billions of dollars — burned by the protocol. That price tag is what "final" actually means here.

Be honest about what slashing does not do, because the limits matter. It punishes provable equivocation, not every bad behavior: a validator can censor transactions or simply go offline without ever signing two contradictory messages, so those harms need other tools. It assumes an attacker who values money — a state actor willing to burn tens of billions to halt the chain for a day is undeterred by losing them. And it creates weak subjectivity: a brand-new node syncing from genesis cannot, by cryptography alone, tell which finalized history is the real one, because the validators who would be slashed for lying about it may have already exited and withdrawn. So fresh nodes must begin from a recent trusted checkpoint. These are not bugs to wave away; they are the honest boundary of what cryptoeconomic consensus can promise.