Slashing Conditions in Detail

Proof of stake secures the network by making misbehaviour expensive. The specific conditions are narrow and worth knowing precisely.

The slashable offences

Double proposing. Producing two different blocks for the same slot. There is no legitimate reason to do this and it is a direct attack on consensus.

Double voting. Attesting to two different blocks for the same target. Same category.

Surround voting. Casting an attestation that surrounds or is surrounded by a previous one from the same validator, which is an attempt to support conflicting histories.

That is the list on most designs. All three are equivocation: saying two contradictory things.

What is not slashable

Being offline. This incurs a penalty, not a slashing. The validator loses the rewards it would have earned and suffers a small additional penalty, roughly equivalent to what it would have gained by being online.

The distinction matters. Downtime is expensive in opportunity terms and does not destroy stake.

Being slow. Late attestations earn reduced rewards.

Disagreeing with the majority honestly. Following different but internally consistent rules is a fork, not a slashing offence.

The severity

A slashing typically involves an immediate penalty, forced exit from the validator set, and an additional penalty proportional to how many other validators were slashed around the same time.

That last mechanism is the important one. An isolated slashing is a modest penalty; a correlated one, where many validators are slashed together, is severe.

The design intent is that an individual mistake is survivable and a coordinated attack is ruinous.

What causes accidental slashing

Running the same validator keys in two places. The most common cause by a wide margin. A backup that comes online while the primary is running produces double attestations immediately.

The rule is that a validator’s keys must be active in exactly one place, ever. Failover arrangements that are not carefully designed produce exactly this.

Restoring from a backup without the slashing protection database, which records what the validator has already signed.

Misconfigured redundancy intended to improve uptime.

What a delegator should know

If you delegate to someone else’s validator, their slashing affects your stake proportionally.

That makes validator selection a real decision. Uptime history, commission rate and the operator’s track record all matter, and all are published.

The practical advice for operators

Never run the same keys twice. Keep the slashing protection database with the keys. Prefer downtime over redundancy that risks equivocation, because the penalty for being offline is small and the penalty for double signing is not.

For anyone staking through a venue rather than running their own, the operator absorbs this and the venue’s terms state how penalties are handled. Platforms publishing their staking terms, including exchanges that let you specify the network, make that allocation of risk explicit, which is worth reading before staking rather than after.