Validator Slashing: How Stakers Lose Money

Slashing is a penalty that destroys part of a validator's staked funds for provably harmful behavior — mainly double-signing (equivocation) or surround votes. It exists to make attacking the chain expensive. Ordinary downtime is not slashing; going offline causes small inactivity penalties instead.

That is the short answer. The rest of this page separates the two very different ways a staker loses money, and shows where the real risk sits.

---

Slashing vs downtime: two different penalties

Proof-of-stake chains punish validators in two categories, and confusing them is the most common misconception.

Slashing is reserved for offenses the protocol can cryptographically prove are attacks on consensus. A slashed validator has funds burned, is forcibly ejected from the active set, and cannot rejoin. On Ethereum, slashable offenses are:

• Double-proposing — signing two different blocks for the same slot.
• Double-attesting (equivocation) — signing two conflicting attestations for the same target.
• Surround votes — casting an attestation whose vote span surrounds or is surrounded by a previous vote, a pattern only a dishonest or misconfigured validator produces.

All three amount to the validator saying two contradictory things about chain history at once. That is exactly what an attacker trying to fork or reverse the chain would do, so the protocol treats it as hostile regardless of intent.

Downtime is not slashing. If your validator is offline and misses attestations, you suffer a small inactivity leak — you fail to earn rewards and lose a tiny amount roughly equal to what you would have gained. Under normal conditions this is measured in fractions of a percent per day. It only escalates into serious losses during an "inactivity leak" event, when the chain fails to finalize for a long time and offline validators are drained to restore a supermajority. That is a rare, chain-wide emergency, not a routine penalty.

---

The correlation penalty

Slashing is not a fixed fine. The amount scales with how many validators are slashed around the same time, through the correlation penalty (on Ethereum, the proportional slashing).

The logic: one validator equivocating is probably a mistake or a lone bad actor and does little harm. Thousands equivocating together looks like a coordinated attack. So the more stake slashed in the same window, the larger the penalty each offender pays — potentially their entire balance if the correlated share is high enough.

This design directly discourages concentration. Running many validators on identical infrastructure means one bug can slash them all simultaneously, triggering the correlation multiplier. It is a deliberate incentive to spread stake across independent clients, machines, and operators.

---

Events, causes, and severity

The gap between the top row and the rest is the whole point: downtime costs you rewards, slashing costs you principal.

---

Who is at risk and how to avoid it

The overwhelming majority of real-world slashings have one root cause: the same validator keys running on two machines at once. Someone sets up a backup or failover node with the same keys, both come online, and the two instances sign conflicting messages — an instant equivocation slash. There is no attack here, just a misconfiguration that the protocol cannot distinguish from one.

If you run validators yourself, the practical defenses are:

• Never run identical keys on two nodes simultaneously. Do not build a "hot spare" that shares keys. If you migrate to new hardware, fully shut down and confirm the old instance is dead before starting the new one.
• Use the slashing-protection database. Clients keep a local record of every message signed and refuse to sign anything that would be slashable. Always import and carry this database forward when moving setups; never start fresh with existing keys.
• Diversify clients and infrastructure so a single client bug cannot slash your whole fleet and trip the correlation penalty.
• Understand the delegation trade. With a staking pool or liquid staking provider, the operator runs the validators. The slashing risk sits with them, not you directly — but you inherit their competence and their concentration.

---

Honest limits

There is no risk-free version of staking; there is only a choice of which risk you hold.

Solo staking gives you full rewards and full control, and full responsibility. A downtime event costs you rewards; a keys-on-two-machines mistake costs you principal through slashing. The failure modes are operational and largely in your hands.

Delegated or liquid staking shifts that operational burden to a provider. You are no longer the one who can double-sign. But you take on provider and counterparty risk instead: the operator can still get slashed (and pass losses to you), the platform can fail, custody arrangements can break, and a liquid staking token can depeg from the underlying stake. You have traded a risk you control for one you do not.

Neither is strictly safer. Slashing is a small, avoidable tail risk for a careful solo operator, and a delegated risk you cannot personally prevent when you use a pool.

---

FAQ

What gets a validator slashed? Provable consensus violations: proposing two blocks for the same slot, or making conflicting attestations (double votes and surround votes). In practice these almost always come from running duplicate keys on two machines, not from deliberate attacks.

Will I get slashed for going offline? No. Downtime is not a slashable offense. You lose rewards and pay a small inactivity leak roughly equal to what you would have earned. Losses only become serious during a prolonged non-finality event, which is rare.

How much can slashing cost? It starts with an initial burn and forced ejection, then adds a correlation penalty based on how much stake was slashed alongside yours. In isolation the loss is modest; in a correlated mass slashing it can scale toward your entire staked balance.

Does staking through a pool protect me from slashing? It moves the operational risk to the operator rather than eliminating it. You will not personally double-sign, but the operator can still be slashed and pass the loss to you, and you take on provider and counterparty risk in exchange.

---

Before you stake at all, make sure you understand the mechanism you are securing — read what staking is and how proof-of-stake compares to proof-of-work. If you would rather not run a validator, weigh the trade-offs in liquid staking.