Slashing Risks

TL;DR

One thing gets you slashed today: double-signing (running your signing key on two machines). It tombstones your validator, removing it from the active set; no stake is burned on the testnet today, though burning is planned. Prolonged downtime costs you the rewards you miss, and a downtime penalty is planned but not live. For the protocol side, see Slashing. This page is the operator's checklist for avoiding both.

What actually triggers slashing

Stake burning and a downtime penalty are planned, and their amounts will be published before they go live. 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 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. Consensus is not like a web server, there is 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. Every block you miss is reward you don't earn, and a downtime penalty on stake is planned.

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." Stop and disable the old node completely before starting the new one with the same key. Rotate operational keys, never validator keys: there is no supported validator key rotation on testnet.
• Automatic OS patches: yes. Automatic node-software upgrades: no. Upgrade manually.

If you do get slashed

Downtime - there is no downtime slash on the testnet today; you simply missed rewards. Fix whatever caused the downtime, and your validator continues.

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 resets.