Slashing
Why validators behave · Estimated read time: 6 minutes
TL;DR
Slashing is the mechanism that makes proof-of-stake economically secure. Validators who attack the chain have evidence of the attack posted on-chain; their stake is burned and they are tombstoned — permanently banned from the validator set. All slashing is keyed on objectively verifiable evidence. There is no human jury.
Slashable offences
Only two behaviours are slashable:
- Double-signing. Signing two different pre-votes or pre-commits at the same height and round. This is what a validator would do to attack BFT finality. Always a bug or an attack — never an accident.
- Prolonged downtime. Missing more than a threshold fraction of blocks during a committee rotation. Less punishing than double-signing, but meaningful: uptime is a committed service.
Being offline briefly, being slow, running old software, disagreeing with governance — none of these are slashable. Slashing is only for protocol-breaking behaviour.
Evidence & detection
For double-signing: anyone who sees two conflicting signed votes from the same validator can post them as evidence in a slashing transaction. The chain verifies the signatures mathematically — no judgement call required. If both signatures verify against the same validator pubkey at the same height and round but sign different hashes, the slashing contract fires.
For downtime: the chain itself tracks missed block signatures during committee rotations and fires automatically if the threshold is exceeded.
The tombstone
A slashed validator's state gets a tombstone marker set to true. The tombstone is permanent and irreversible. The validator's pubkey is banned from rejoining the candidate set — even if they unbond, pay back the slash, and try again with the same key.
Permanence is on purpose. A validator who double-signs has demonstrated either a catastrophic operational failure or active malice. Either way, they don't get another chance with that key.
Stake impact
Slashing doesn't just tombstone — it burns part of the stake. The burn fraction depends on the offence:
| Offence | Burn fraction |
|---|---|
| Double-signing | 5% of bonded stake (governance-adjustable) |
| Prolonged downtime | 0.01% per downtime window (governance-adjustable) |
The burn is proportional: delegators share the slash with the validator they chose. This is the shared-slashing model — what gives delegators real skin in the game.
Recovery
After a slash, the validator can still unbond the remaining stake and move it elsewhere. But the tombstoned key is dead forever. To rejoin the validator set, the operator must generate a new Dilithium3 key — and any reputation or delegation relationships they had are reset.
The practical implication: your validator key is your identity. Protect it, back it up, and do not run it on two machines at once.
What it means for delegators
Delegators take the slash pro-rata with the validator they delegated to. That's not a bug — it's the feature. If delegators had no risk, a validator could run a sloppy operation with other people's money and pay nothing when it went wrong.
In practice: pick validators carefully. Look at uptime history, commission, and how long they've been running without incident. See How to Delegate.