Slashing Risks

TL;DR

Two things get you slashed: double-signing (running your signing key on two machines) and prolonged downtime (missing too many blocks during your rotation). For the protocol side, see Slashing. This page is the operator's checklist for avoiding both.

What actually triggers slashing

Numbers are placeholders pending governance tuning. Double-signing is the one that ends your validator permanently — downtime just stings.

Things that are NOT slashable

• Being briefly offline (minutes, not hours during your committee turn).
• Being slow (as long as you meet commit deadlines).
• Voting against a proposal you dislike.
• Running old but still-compatible software.
• Misbehaving in the mempool or peer gossip — those get you throttled, not slashed.

Slashing is reserved for protocol-breaking behaviour with objective cryptographic evidence. Subjective "bad actor" judgement doesn't exist at the protocol level.

The double-sign trap

Double-signing means signing two different blocks at the same height and round with the same key. It only happens if your signing key is running on two machines simultaneously. Common ways people accidentally cause this:

• Setting up "HA failover" with both nodes hot. Don't do this. BFT consensus is not like a web server — there's no benefit to two active replicas.
• Restoring a validator onto a new box without confirming the old one is dead. Confirm first. Kill the systemd service, unplug it if you have to.
• Copying the data directory to another machine for "backup" and starting it. Never start a second copy.
• Running asentum start twice against the same data directory on different hosts via a shared volume.

The downtime trap

You only need to be available during your committee rotations — a few hours a day when you're actively in the active set. Miss too many blocks during those rotations, and the chain starts nibbling at your stake.

Downtime usually sneaks in through disk I/O starvation, OS updates that require reboot, or ISP maintenance. Watch the missed-blocks metric and set up alerts so you catch it in minutes.

Operational checklist

• One signing key, one machine. Always.
• Back up the operator wallet, not the signing key. Use a recovery phrase.
• Separate validator signing key from operator wallet — see Validator Key Backup.
• Prometheus alerts on missed blocks + peer count + sync lag.
• Test on testnet before any infrastructure change.
• Never migrate a live validator "live." Unbond, migrate, re-bond — or rotate the signing key on-chain.
• Automatic OS patches: yes. Automatic node-software upgrades: no. Upgrade manually.

If you do get slashed

Downtime slash — the penalty has already landed. Fix whatever caused the downtime, and your validator continues. Your delegators shared the hit pro-rata.

Double-sign slash — your validator is tombstoned, permanently. You can unbond the remaining stake after the unbonding period, then start a new validator with a new key if you want to keep operating. Reputation and delegations reset.