Slashing

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 offenses

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 your 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. 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 offense:

• Double-signing — burns a large fraction (placeholder: 5% of bonded stake, final number set by governance).
• Downtime — burns a small fraction (placeholder: 0.01% per downtime window).

The burn is proportional: delegators share the slash with the validator they chose. This is the shared-slashing model — what gives delegators 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.

For operators, the practical implication is that your validator key is your identity. Protect it; back it up; do not run it on two machines at once. For that story, see Slashing Risks and Validator Key Backup.

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 this means pick validators carefully. Look at uptime history, commission, and how long they've been running. See How to Delegate.