"Zero slashing incidents" is the single most quoted line on any validator's website, ours included. But few delegators know what slashing actually is at the protocol level, which makes it hard to judge whether a validator's zero is the product of engineering or of luck. This post explains the machine, then shows how we removed luck from the equation.
Two crimes, two punishments
The x/slashing module in the Cosmos SDK punishes exactly two behaviors, and they are wildly different in severity:
| Offense | Typical penalty | Jail | Recoverable? |
|---|---|---|---|
| Downtime (liveness fault) | 0.01% of stake | ~10 minutes | Yes, unjail and continue |
| Double-signing (equivocation) | 5% of stake | Forever | No, tombstoned |
The asymmetry is deliberate. Downtime hurts only the network's liveness margin; the protocol treats it as an operational mistake. Equivocation, meaning signing two different blocks at the same height and round, is an attack on safety itself, the raw material of double-spend attempts. The protocol treats it as unforgivable: the validator is tombstoned, permanently banned from ever validating with that consensus key again. Every delegator loses 5%, and their only path forward is to redelegate elsewhere.
How downtime is actually measured
Downtime slashing is governed by a sliding window, not a stopwatch. The parameters on a typical chain:
# x/slashing params (values vary per chain)
signed_blocks_window = 10000 # the sliding window, in blocks
min_signed_per_window = 0.05 # must sign at least 5% of the window
downtime_jail_duration = 600s
slash_fraction_downtime = 0.0001 # 0.01%Read that carefully: with a 10,000-block window and a 5% floor, you are jailed only after missing 9,500 consecutive-ish blocks. At a 5-second block time, that's over 13 hours of continuous failure. Downtime slashing is not something that happens to you in a bad five minutes. It happens when nobody is watching the pager for half a day. This is why our alerting fires on a 100-block missed-precommit window: we want to know about a problem 13 hours before the protocol cares.
How double-signing actually happens
No one double-signs on purpose. In practice, every tombstoning in Cosmos history traces back to one operational pattern: two processes holding the same consensus key at the same time. The classic sequences:
- The failover that wasn't. Primary node appears dead; operator starts the backup with a copy of
priv_validator_key.json; primary was actually alive behind a network partition. Both sign the next height. Tombstoned. - The migration leftover. Validator moves to a new server; old server still has the key and a systemd unit with
Restart=always. Weeks later the old machine reboots. Tombstoned. - The snapshot restore. A VM restored from a disk snapshot comes back with a stale
priv_validator_state.json, and re-signs a height it already signed. Tombstoned.
The uncomfortable truth: high availability and double-sign safety pull in opposite directions. A "hot standby with a key copy" is not redundancy. It is a tombstoning waiting for a network partition. Any HA design must make simultaneous signing physically impossible, not just unlikely.
Engineering the risk to zero
Our production stack attacks each failure mode at its root:
- The key never exists in two places. Consensus keys live in a hardware security module, accessed by a single remote signer. There is no
priv_validator_key.jsonon any validator host to copy during a panicked failover. (Details in our key custody post.) - The signer enforces monotonic state. The remote signer persists the last signed height/round/step and refuses, at the signer itself, below any orchestration bug, to ever sign the same height twice. Even a restored-from-snapshot node cannot equivocate, because the signer, not the node, is the source of truth.
- Failover moves the connection, not the key. When we fail over, the standby node connects to the same signer the primary used. The signer serializes all requests; two nodes racing each other simply means one of them waits.
- Decommissioned hosts are cryptographically dead. Migration checklists end with wiping the node key and verifying the old host can no longer reach the signer network, not with "we'll get to it."
What this means for delegators
When you evaluate a validator, "0 slashing incidents" is table stakes. The better questions are structural:
- Do they use a remote signer with double-sign protection, or does the key sit on the node's disk?
- Is their failover design key-copying (dangerous) or connection-moving (safe)?
- Do they alert on missed precommits (minutes) or on jailing (half a day too late)?
Ask these three questions and you'll learn more than any uptime dashboard will tell you. Our answers are: yes, connection-moving, and 100 blocks.
Downtime costs you 0.01% and ten minutes. Double-signing costs your delegators 5% and costs you the validator, permanently. Engineer for the second; the first takes care of itself.
Ready to put this to work? See the networks we validate or read how we hide validators behind sentries.