Slashing is a proof-of-stake protocol destroying part of a validator's staked collateral for a provable offense and then forcing it out of the validator set. On Ethereum the trigger is equivocation: signing two conflicting messages where the rules allow one. The penalty is not a single deduction. It is an immediate burn, a drip of attestation penalties across a fixed removal window, and a second penalty at the midpoint whose size depends on how much other stake was slashed in the same period.
Your loss depends on other operators' mistakes as much as your own. An isolated slashing rounds down to close to nothing, while the same misconfiguration made by everybody running the same setup on the same day can take the entire balance.
Scroll to see the full diagram
The offense is equivocation, not poor performance
Ethereum lists three slashable actions: proposing and signing two different blocks for the same slot, attesting to a block that surrounds another attestation, and double voting by attesting to two candidates for the same block.1 Ben Edgington's annotated treatment groups all three under one idea. Every slashable behaviour is equivocation, which is a validator contradicting something it previously advertised to the network.2
Downtime is not on that list. Missing a source or target vote costs the reward that vote would have paid, missing a head vote costs nothing at all, and failing to propose a block carries no penalty.1 An offline validator loses income. A contradicting validator loses capital. Those are different orders of magnitude and they get collapsed into one bullet on most risk pages.
The practical version matters more than the taxonomy. Edgington's own note is that as far as can be determined, every Ethereum slashing to date has been caused by a node operator running the same validator keys on two different machines, usually as a misguided attempt to improve uptime, with one exception attributed to a proposer attacking an MEV relay.2 The offense the protocol punishes is a signing-key duplication accident, not an attack.
One offense, three separate deductions
The first deduction is immediate and small on purpose. Ethereum burns 0.0078125 ETH for a 32 ETH validator, scaled linearly with active balance, the moment the evidence lands in a block.1 Read the size as a policy choice rather than an accident: it is set low enough that consolidating many validators into one large balance does not concentrate a punishing amount of first-loss exposure.
The second is a drip. The validator's withdrawable epoch is pushed 8192 epochs out, roughly 36 days, and for that whole period it is penalised exactly as though it were failing to participate, whatever it actually does.2 Edgington puts the size of that drip at about 0.0827 ETH under one worked set of assumptions, and notes it is far higher if the chain is in an inactivity leak at the time.2
The third arrives at the midpoint, on day 18, and it is the one that decides whether a slashing is an operational annoyance or a capital event.
The correlation penalty is a fraction you can compute
The beacon chain keeps a record of the effective balances of every validator slashed in the trailing 8192 epochs. The penalty is the minimum of the validator's own effective balance and three times that slashed sum multiplied by the balance and divided by total active balance, with the multiplier fixed at three since Bellatrix.2 Strip the balance out of both sides and what remains is a fraction of your own stake set entirely by the ratio of slashed stake to total stake in a 36 day window.
Run it. If one in a thousand units of active stake is slashed in that window, the penalty is three tenths of one percent of your balance. If one in a hundred, three percent. At five percent slashed, fifteen percent. Once the slashed share crosses a third, the multiplier takes the whole effective balance and the maximum slash is the full stake of everyone caught in it.1
Then read the rounding rule, which almost nobody quotes. The integer arithmetic returns zero whenever three times the slashed sum times your balance is less than total active balance, so at realistic network sizes an isolated slashing produces no correlation penalty at all.2 Edgington records that no correlated slashing to date has incurred a penalty greater than zero under this mechanism.2 That is the design working, and it is also why a founder who prices slashing risk off the historical record is pricing a regime that has never been tested.
Restaking slashing is a different object with the same name
On Ethereum the offense list is fixed, provable onchain and identical for everyone. Inside a restaking protocol it is whatever the service operator wrote. EigenLayer states plainly that its slashing function is maximally flexible, that services may slash for any reason, and that slashing does not have to be objectively attributable, meaning provable onchain, though services are encouraged to publish clear process around how theirs works.3
Where the money goes also differs. Slashed funds are burned by default, but a redistributable operator set sends them to a recipient the service controls and cannot change after the set is created, and the protocol's own guidance is that there is a larger incentive to slash when redistribution is enabled.3 A seven day resolution delay sits between the slash and the funds leaving. Natively restaked ETH cannot be redistributed at all and stays permanently locked in the EigenPod contract.3
In our view that is the single most under-read paragraph in the restaking stack. A penalty that pays somebody is a different economic instrument from a penalty that burns, and any depositor product built on redistributable sets has a counterparty who profits from the depositor being penalised. The restaking entry covers the layered exposure; this is the part that changes who benefits.
What we settle before a staking product ships
Three things, written down, before anyone quotes a rate. Name the slashable offenses for every layer the capital touches, base chain and services separately, and say for each whether the offense is provable onchain or adjudicated by somebody. State the loss-sharing rule: whose capital absorbs the first unit of loss, whose absorbs the second, and at what point depositor balances move. And size the reserve against correlated loss, not per-event maximum, because the base-layer formula is explicitly built so that correlated failures cost more than the sum of independent ones.
The failure pattern we see repeatedly is a disclosure listing a maximum loss per service side by side, which implicitly claims those losses are independent. Shared operators, shared client software and shared cloud regions make them anything but. The slashing reserve entry works through the sizing arithmetic.
One boundary. This page describes mechanisms and the design questions they raise. It is not investment advice and not a recommendation to stake, restake or hold any asset.
Common questions
What causes a validator to get slashed?
Equivocation. Ethereum slashes for proposing two different blocks for the same slot, attesting to a block that surrounds another attestation, or double voting on two candidates for the same block.1 In practice almost every recorded slashing traces to one cause: an operator running the same validator keys on two machines at once, often as a mistaken attempt to improve uptime.2 Being offline is penalised separately and far more mildly.
How much ETH do you lose if you are slashed?
It depends on how many others are slashed around the same time. The immediate burn is 0.0078125 ETH for a 32 ETH validator.1 A 36 day forced removal follows, during which attestation penalties keep accruing, and at day 18 a correlation penalty applies equal to three times the slashed share of total stake, capped at your full balance.2 Isolated incidents round to roughly nothing. Correlated events can take everything.
Can you be slashed for validator downtime?
No. Downtime is penalised through missed rewards, not slashing. Missing a timely source or target vote costs the same amount the vote would have earned, missing a head vote costs nothing because head votes are rewarded and not penalised, and there is no penalty for failing to propose a block.1 Slashing applies only to provable equivocation. A separate inactivity leak can drain stake, but only when the chain stops finalising.
Is restaking slashing the same as Ethereum slashing?
No. Ethereum's offense list is fixed and provable onchain. On EigenLayer each service defines its own conditions, the protocol states that slashing does not have to be objectively attributable, and services may slash for any reason they design for.3 Slashed funds are burned by default, but redistributable operator sets pay them to a recipient the service controls, which creates a party with an incentive to slash.
See Tokenomics Audit for how this applies in practice.
Sources
- Proof-of-stake rewards and penalties
ethereum.org, Ethereum Foundation, 2026
The three slashable actions, the 0.0078125 ETH initial burn for a 32 ETH validator, the 36 day removal, the day 18 correlation penalty and the reward-penalty asymmetry that leaves downtime unslashed. Page last updated 3 April 2026, read 3 August 2026. - Upgrading Ethereum, section 2.8.7: Slashing
Ben Edgington, eth2book.info, 2026
Equivocation as the common root of all three offenses, the correlation formula with the multiplier fixed at three, the rounding rule that zeroes the penalty for isolated events, the observation that no correlated slashing has yet incurred a non-zero correlation penalty, and the attribution of recorded slashings to duplicated signing keys. Page published 13 January 2026, read 3 August 2026. - Slashing Overview
EigenCloud, Eigen Labs, 2026
Slashing as maximally flexible and not required to be objectively attributable, the burn versus redistribute paths, the seven day slash resolution delay, and the exclusion of natively restaked ETH from redistribution. Cloudflare returns 403 to automated clients; content read by stealth fetch on 3 August 2026.
Last reviewed 2026-08
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
100+ projects advised. Complete tokenomics in 4 to 6 weeks.