Lesson 2 — Slashing detection and the offline validator

Question

There are exactly two ways a validator loses stake. The expensive one: sign two contradictory messages (slashing — forced exit plus a penalty that can reach the whole stake when many validators are slashed together). The slow one: be offline when the network needs you (inactivity penalty — small per epoch, growing only during a long loss of finality). Every operational decision is "pick the smaller of these two losses." What are the decision axes?

Principle (minimum model)

Two paths to losing stake. Active (slashing — cryptographically provable, forced exit, catastrophic when correlated) + passive (inactivity — gradual, small per epoch).
Three flavours of slashable violation. Double voting (same height, different blocks) + surround voting (Casper FFG — a later vote brackets an earlier one) + BFT equivocation (same height/round, different pre-commit).
Slashing-protection DB is standard. Before signing, check whether a different message at this (H, R) was already signed → if yes, refuse → if no, record, then sign.
The DB must be persistent + restart-safe + soft-update-safe + backed up.
Record before you sign. Check-and-record is one DB transaction, committed before the signature leaves the signer. A crash after the commit costs a missed duty, never a double sign. The DB can be remote if the transaction is real (Web3Signer uses PostgreSQL).
Remote signer + DB = defence in depth. Even if the validator node has a bug, the remote signer's DB is the last line.
Whistleblower reward. On Ethereum (since Electra) it is the slashed validator's effective balance / 4096 (it was / 512 before), and the spec pays it to the proposer of the block that includes the evidence — an incentive for proposers to include slashings.
Inactivity leak. When >1/3 are offline, finality stalls → every epoch shaves the offline stake → the chain self-heals back to >2/3 online.
During a network partition, fail-closed is the right answer. Keep signing (slashing risk) vs stop (small inactivity penalty) → stopping is always correct.

Worked example + steps

Slashing detection and the offline validator

There are exactly two ways to lose validator stake. The expensive way: sign two conflicting messages (slashing — one event, big chunk of stake gone). The slow way: be offline when the network needs you (inactivity penalty — drips out over days). Every operational decision in this lesson comes down to picking the smaller of those two losses when something goes wrong.

1. The two ways to lose stake

Way	What	Why
Active misbehavior (slashing)	Sign 2 conflicting messages	Cryptographically provable; major penalty
Passive misbehavior (inactivity)	Don't sign at all	Eroding penalty during partitions

Both are protocol-enforced. Both reduce your stake. The key difference: slashing is potentially catastrophic (forced exit; up to all of the stake when many validators are slashed together), inactivity is slow (lose small amounts over time).

For Ethereum mainnet (consensus-specs, Electra):

Slashing: immediate penalty of effective balance / 4096 (≈0.0078 ETH for a 32 ETH validator) and a forced exit. About 18 days later a correlation penalty is applied in proportion to 3× the total stake slashed in the surrounding ~36 days. An isolated slashing is cheap; if ≥1/3 of stake is slashed together, the whole balance goes.
Inactivity leak: only while finality is stalled. Each missed epoch adds 4 to the validator's inactivity score, and the per-epoch penalty is effective balance × score / 2^26, so losses grow quadratically — about 0.15% after one day of leak, about 7% after a week.

2. Slashable offenses, in detail

2.1 Double voting

Two votes for the same height with different blocks:

Vote1: { height: 1000, block: 0xA..., signature: SigA }
Vote2: { height: 1000, block: 0xB..., signature: SigB }

If both votes are valid and both are signed by validator V, V is slashable. Anyone with both signatures can construct a slashing proof.

The fix: validator software MUST track every signed vote and refuse to sign a second vote for the same height. This is the slashing-protection database.

2.2 Surround voting (Casper FFG specific)

Casper FFG (Ethereum's finality gadget) has validators vote on source → target checkpoint pairs. A surround-vote is one where a later vote's range strictly contains an earlier vote's range:

Vote1: source A → target B Vote2: source C → target D

If C < A and D > B (the second "surrounds" the first), this is slashable. The fix: track every voted source/target pair; reject votes that would surround prior votes.

2.3 Equivocation in BFT (Tendermint, HotStuff)

Two pre-commits (the "I'm committed to this block" message in a BFT round) for the same height/round but different blocks. Same logic as double voting; the slashing-protection database must catch it.

3. The slashing-protection database

Every production validator runs one. Its job:

Before signing message M at height H, round R:
  if any prior signed message exists at (H, R) with different content:
    REFUSE to sign  → no slashing event
  else:
    record M in database (commit)
    sign M

The database must:

Persist across restarts
Survive software updates
Be backed up (so a fresh database doesn't fall behind reality)

Common implementations:

EIP-3076 interchange format — Ethereum's standard for exporting / importing this history between validator clients and signers
CometBFT priv_validator_state.json — Cosmos chains (last signed height / round / step)
Custom files — chain-specific formats

4. The remote signer integration

Most production validators run a remote signer that also enforces slashing-protection:

[Validator node]  --request to sign-->  [Remote Signer]
                                            |
                                            +- Check slashing-protection DB
                                            +- If safe: sign + record
                                            +- If unsafe: refuse

This gives defense in depth. The validator node might have a bug, but the remote signer's database is the final check. Even if the validator node tries to double-sign, the remote signer refuses.

Web3Signer (Ethereum) implements this. CometBFT validators have their own variant.

Order matters. If you sign, then try to record but the process crashes or the network fails, you've signed without recording — and on retry you might sign something conflicting. The safe order: check-and-record in one DB transaction, commit, then sign. If the process dies after the commit but before signing, you only miss that duty. With that ordering the DB need not be on the same machine: Web3Signer keeps slashing protection in PostgreSQL and takes a per-validator lock inside the transaction before approving a signature.

5. Whistleblower watchers

The protocol enforces slashing only when somebody submits the proof. That's where watchers come in. Slashing is cryptographically provable — anyone with the two conflicting signatures can submit a slashing transaction. Ethereum's spec includes a whistleblower reward, but check who actually receives it.

For Ethereum: since Electra the reward is the slashed validator's effective balance / 4096 (/ 512 before Electra). process_proposer_slashing and process_attester_slashing call slash_validator without a whistleblower index, so the whole reward goes to the proposer of the block that includes the evidence. A watcher finds the evidence and gossips it; the proposer collects.

Watcher implementations:

Scan blockchain for attestations
Index by (validator, height, round)
Detect conflicts
Submit slashing tx

If you're building a watcher: it's open-source territory, similar to MEV searchers but for protocol-level violations.

6. The offline validator — inactivity penalty

If a validator is offline:

During normal operations: they miss rewards (small daily loss)
During finality issues (>1/3 offline): inactivity leak kicks in

Inactivity leak (the mechanism Ethereum uses to force a partitioned chain back to >2/3 online): every epoch, offline validators lose stake. The rate increases the longer finality remains delayed. The chain self-heals — eventually online validators are >2/3 and finality resumes, leaving offline ones with reduced stake.

This is the BFT-style chain's response to mass offline events. Instead of halting forever, the protocol slowly removes offline validators until quorum is achievable.

7. The Network Partition Risk

The classic disaster:

Network partition splits validator set
Each partition might think they're the majority
Each might continue signing on different forks
When partition heals: massive cross-fork slashing

Mitigations:

Liveness watchdog: detect partition (no recent blocks from peers); stop signing
Network heartbeat: verify connectivity to other validators before signing
Forced sync: refuse to sign until catching up with the network

A well-built validator has multiple of these checks. Compromised validator software (where these checks are disabled) is a real risk.

If it continues signing: it might be on a partition and producing blocks the rest of the network doesn't see. Eventually network heals, the validator's chain is the wrong one, double-sign equivalent → slashed.

If it stops signing: 30 minutes of inactivity (small penalty). When connection restores, sync up and resume.

Stop signing is correct. Lose a tiny inactivity penalty rather than risk slashing. The validator software should automatically detect this and fail-closed.

8. For my projects

Tempo validator if you operate

Tempo's public repo adds validators through an owner-only ValidatorConfig precompile; check its docs for how misbehaviour is handled before assuming Ethereum-style slashing. The checklist for any BFT validator is the same:

Double-sign protection on each validator node or in the remote signer
Peer-connectivity heartbeat; refuse to sign if connectivity is lost
2-region active-passive (transition only via consensus protocol)
Regular, versioned backups of the protection DB

Watcher opportunity

A watcher only earns where the protocol pays whoever submits evidence. On Ethereum the reward goes to the block proposer (§5), so a standalone watcher is mainly monitoring for your own validators. Read a chain's slashing rules before assuming there is a market.

9. Practice

Compute: validator with 1000 ETH stake. Slashed by 5% via double-vote. How much do they lose?
Identify: if validator A is online with 95% participation, validator B is offline. After 1 month, which has more stake?
Write pseudo-code for slashing-protection logic
Read Web3Signer slashing protection

10. Reading list

Final check: in one sentence, why is "stop signing if uncertain" the correct default for a validator? If your answer doesn't reference "slashing > inactivity penalty," re-read §7.

Pass criteria

Name the two paths to losing stake and the order of magnitude of each.
Distinguish double-vote, surround-vote, and BFT equivocation in one sentence each.
Explain why the slashing-protection record must be committed before the signature is released.
Sketch the four DB durability requirements.
Explain why remote-signer DB + validator-client DB is defence in depth, not duplication.
Recall the Ethereum whistleblower share, who receives it, and what behaviour it incentivises.
Walk the inactivity-leak self-healing mechanism.
State the fail-closed rule for network partitions and why it dominates.

Summary (3 lines)

Two paths to losing stake: slashing (catastrophic, cryptographically provable) and inactivity (gradual, small). All operational decisions reduce to picking the smaller of the two.
Slashing-protection DB is the standard defence — it must commit the record before signing, and be persistent, restart-safe, and backed up. Remote signer + DB stacks them for defence in depth.
Network partitions: fail-closed (stop signing) every time — the inactivity tax is always smaller than the slashing risk. Next lesson covers chain-wide coordinated upgrades.