Slashing: What Actually Triggers It, and Who Pays

Slashing is a protocol-level penalty that destroys part of a validator's stake for behaviour the network can prove is dishonest. It is deliberately narrow: it targets actions that are only explicable as an attack on consensus, and it is distinct from the much milder penalties applied for being offline. Understanding which category a given failure falls into is the difference between a rounding error and a permanent loss.

The two offences that actually trigger it

Almost every slashable offence reduces to signing two conflicting things when honest participation would have produced one.

The first is double signing: proposing two different blocks for the same slot. An honest validator has no reason to do this — there is one correct block to propose, and producing two is either an attempt to split the network's view or the result of running the same key on two machines that cannot see each other.

The second is contradictory attestation: voting for two incompatible versions of history, or casting a vote that surrounds an earlier one in a way that would let the validator support two conflicting chains. Again, honest behaviour produces one vote. The protocol does not need to know intent; the contradiction itself is the proof.

That narrowness is the design. A penalty that destroyed capital for ambiguous behaviour would make validation uninsurable, so networks restrict it to actions where the evidence is self-contained and undeniable.

Why running a backup is the classic way to get slashed

The most common cause of slashing is not an attack. It is an operator trying to be careful.

The instinct when you have a validator that must stay online is to run a second instance for redundancy. If both instances hold the same key and both are active, they will eventually sign conflicting messages, and the network will punish exactly the behaviour the redundancy was meant to prevent. The failure mode is worse than the outage it was designed to avoid.

This is why competent operators run failover as an explicitly manual or strongly interlocked process, and why a provider's answer to the question of how they handle failover tells you more about their competence than their marketing does. An operator who describes an automatic hot standby holding the same key is describing a slashing incident that has not happened yet.

Downtime is a different thing, and much smaller

Being offline is penalised, but through a separate mechanism. A validator that fails to attest simply does not earn the rewards it would have earned, and on some networks loses a small amount in addition. The design intent is symmetry: over a given period, a validator offline half the time ends up roughly where it would have been having not staked at all.

This matters because downtime and slashing are routinely bundled together in discussions of staking risk, and they are different in scale by orders of magnitude. Downtime is an opportunity cost. Slashing is destruction of principal.

There is one exception worth knowing: several networks apply a correlation penalty, where the severity of a slashing scales with how many other validators were slashed around the same time. An isolated mistake is treated as a mistake. A large group of validators failing together looks like a coordinated attack, and is punished as one. The practical consequence is that using the same client software, the same hosting provider or the same operator as a large share of the network raises your penalty in precisely the scenario where a penalty is most likely.

Who absorbs the loss

This is the question that decides whether slashing is your problem, and it is answered by the arrangement rather than by the protocol.

In non-custodial delegation, the protocol slashes the stake, which is yours. Unless the operator has undertaken to make you whole, the loss stops with you. Most have not undertaken anything.

In custodial staking, the platform holds the asset, and whether it passes the loss through depends entirely on its terms. Some platforms have absorbed slashing events without passing them on; that is a commercial decision, not an obligation, and a decision made once is not a commitment.

A small number of operators publish an indemnity with terms — what is covered, what is excluded, what the cap is. That document is the product. An assurance that slashing is unlikely is not an indemnity, and neither is a page describing an operator's excellent record.

Reading a provider's real exposure

• Ask how failover works. If the answer involves two live instances sharing a key, the risk is structural rather than hypothetical.
• Check the operator's slashing history on-chain. It is public, and an empty record over a long period is meaningful evidence.
• Find out what share of the network runs the same client software as your operator. Client diversity is the main defence against a correlated penalty.
• Read the indemnity if one exists, and note its exclusions. Read the terms of service if one does not.
• Distinguish downtime guarantees from slashing cover. Providers frequently offer the first and imply the second.

The realistic assessment is that slashing is rare with competent operators and catastrophic when it happens. That combination is exactly the profile that makes people underprice it, because the base rate is low enough to feel like zero right up until it is not.