You stake your ETH, someone mentions slashing, and your stomach drops. The word sounds catastrophic. Sometimes it is. But the mechanics behind it vary so much from network to network that "slashing" barely qualifies as a single concept. It's more like a family of punishments, each designed by a different committee with a different threat model in mind, assembled in different rooms, arguing about different nightmares.
The short answer: Ethereum slashes validators for specific, provable cryptographic offences and destroys a portion of their stake permanently. Other networks, including Cosmos, Polkadot, and Solana, each draw the lines differently. Some harsher on liveness failures, some softer on equivocation, some almost philosophical about what deserves punishment at all. Understanding those differences tells you a lot about what each network actually values.
The Crime, Not Just the Punishment
Slashing is not a fine for being offline. That distinction matters enormously, and it's the first thing most explainers bury.
On Ethereum's consensus layer, two and only two behaviours trigger a slash. The first is double voting (the spec calls it equivocation during attestation). The second is a surround vote, where a validator signs two conflicting attestations that bracket each other in a way that could help rewrite history. Both require a whistleblower to submit a proof on-chain. Nobody gets slashed because their node lagged for an hour.
The penalty has three parts. An immediate burn of at least 1/32 of the validator's balance. A forced exit queue. And a correlation penalty applied roughly 18 days later, calculated based on how many other validators were slashed in the same window. If 10% of the validator set gets slashed simultaneously (think: a coordinated attack), that correlation penalty scales toward 100% of the stake. If you're slashed alone, you lose perhaps 1-2 ETH out of 32 and walk away bruised but not destroyed.
The design philosophy is deliberate. Ethereum's researchers wanted slashing to be essentially impossible to trigger by accident while being catastrophic for coordinated attacks. Honest mistakes, even serious ones, are handled through inactivity leaks instead: a slow, non-slashing drain that nudges offline validators out of the active set over weeks.
Cosmos: Slashing by Committee, With a Governance Override
Cosmos (the Hub, and most chains built with the Cosmos SDK) takes a more expansive view. Two slash conditions: double signing, which carries a 5% stake burn and a permanent tombstone (the validator can never rejoin with that key), and downtime, which triggers a much smaller penalty, typically 0.01%, plus a temporary jail period.
That downtime slash is the big conceptual departure from Ethereum. A Cosmos validator that misses more than roughly 95% of blocks in a rolling window gets slashed. Not removed from a queue. Not slowly drained. Slashed, immediately, even if the cause was a cloud provider outage or a botched upgrade.
The catch: Cosmos chains can, and often do, adjust these parameters through governance. A chain can vote to reduce the downtime slash fraction to near-zero, or raise the double-sign penalty. The base SDK is a starting point, not a law. This flexibility is either a feature or a risk depending on how much you trust the validator community of a given chain to govern sensibly. Personally, I'd call it a risk dressed up as a feature.
Polkadot: The Sliding Scale
Polkadot's slashing model is the most mathematically sophisticated of the major networks. Also the most counterintuitive to newcomers.
Nominators (delegators, in Polkadot's terminology) share slashing risk with the validators they back. If a validator is slashed, the nominator's bonded DOT is slashed too, proportionally. This is not true on Ethereum, where delegating via a liquid staking protocol insulates you from the validator's misbehaviour at the protocol level. The protocol slashes the validator's 32 ETH, not your tokens directly.
Polkadot's slash magnitude also scales with the square of the fraction of misbehaving stake. One validator equivocating alone might lose only 0.1% of their stake. Ten validators equivocating in the same era, representing say 30% of the active set, face a slash approaching 90%. The formula is roughly `min(3x, 1)` squared, where `x` is the fraction of the active set involved. Same coordination-punishing logic as Ethereum's correlation penalty, just expressed differently and applied more granularly.
There's also a 28-day delay before a slash is actually applied, during which Polkadot's governance can cancel it. That has happened in practice, after a client bug caused unintentional equivocations. Whether a governable slash is more trustworthy than an automatic one is a genuine open debate. But a slash that can be cancelled by committee is, functionally, a strongly-worded letter until the committee acts.
Solana: No Slashing (Yet, Officially)
Solana is the outlier. As of its current mainnet design, there is no slashing. Validators who vote incorrectly or go offline simply lose out on rewards. They don't lose principal.
This is not an oversight. The design reasoning is that slashing introduces complexity and attack surface: a sophisticated adversary might try to trigger a slash on honest validators by feeding them bad data. Solana's team has historically argued that economic exclusion from rewards is sufficient deterrent, combined with a social and reputational layer where validators who behave badly lose delegations.
Slashing has been proposed and discussed for Solana repeatedly. The absence of it is a live design choice, not a settled one. Critics point out that without slashing, the cost of certain attacks is purely opportunity cost rather than capital destruction. Proponents argue the reward-loss mechanism is underrated as a deterrent. Both sides have a point. Neither side has closed the argument.
What People Get Wrong About This
The common assumption is that harsher slashing equals more security. That's not obviously true, and the people who say it confidently haven't thought it through.
Consider two validators running identical client software. One is on Ethereum, one is on a Cosmos chain with downtime slashing enabled. A shared data-centre outage hits both of them for four hours. The Ethereum validator loses nothing (inactivity leak kicks in, draining fractions of a percent per day, like a slow puncture rather than a blowout). The Cosmos validator gets slashed and jailed immediately.
Harshness on liveness failures tends to centralise validators toward professional infrastructure operators who can afford redundancy. It prices out smaller, geographically diverse participants. Ethereum's choice to leave liveness entirely outside the slash regime is, in my view, the single most underappreciated structural decision in its consensus design. A bet on decentralisation over maximum short-term deterrence.
And here's the thing most readers miss: on Ethereum, slashing requires someone to submit evidence. That means there's a brief window where a slashable offence exists but hasn't been reported yet. Sophisticated operators monitor the mempool for exactly this reason, hunting for slash-worthy messages to submit and claim the small whistleblower reward. The incentive to police the network is baked into the mechanism itself.
The Number That Should Anchor Your Thinking
Take a mid-sized solo validator on Ethereum running 32 ETH. She double-votes accidentally (genuinely rare, but imagine a misconfigured failover setup spins up two signing instances simultaneously). She gets slashed alone, with no correlated incident. Her immediate penalty is 1/32 of 32 ETH: 1 ETH. The delayed correlation penalty, calculated 18 days later with almost no other slashings in the window, adds perhaps another 0.5 ETH. She loses roughly 1.5 ETH total and is exited from the validator set.
Now give her 100 validators. A catastrophic bug triggers all of them simultaneously. The correlation penalty explodes. She could lose the majority of all 3,200 ETH staked. Same underlying mistake, radically different outcome depending on how alone she was in making it.
That scaling property is the sharpest tool in Ethereum's slashing design. It doesn't punish carelessness. It punishes coordination. Which is exactly the threat a decentralised network should care most about, and the one that would actually kill it.