Slashing risk explained: what insurers and institutions need to know

Slashing is the one staking risk that can destroy part of the stake itself. It is also one of the most misunderstood. This guide explains it in plain words, for anyone who has to approve, insure or oversee staking.

What slashing is

In a proof-of-stake network, validators lock up tokens as a security deposit. In return they earn rewards for proposing and confirming blocks.

If a validator breaks the network's core rules in a way that could harm it, the protocol destroys part of that deposit. This is called slashing. It happens automatically. Nobody decides it and nobody can reverse it.

On Ethereum, a validator is slashed for one of two things:

• Double proposing: signing two different blocks for the same slot.
• Contradictory voting: signing two votes (attestations) that conflict with each other.

Other proof-of-stake networks have similar rules. Some also slash for long downtime. The exact rules and percentages are set by each network, so they need to be checked chain by chain.

What actually causes it

Slashing is rarely an attack. In practice it is almost always an operational mistake, and the same few mistakes come up again and again:

• The same keys running in two places. An operator sets up a backup machine for redundancy, or moves validators to new servers, and for a moment both copies are signing. This is the most common cause by far.
• Lost or wiped slashing protection data. Validator software keeps a record of what it has signed so it never signs a conflicting message. If that record is lost during a migration, the protection is gone.
• Badly built failover. Automatic "switch to backup if the main node looks down" logic can start the backup while the main node is still running.
• Software bugs. Rare, but when many operators run the same client software, one bug can hit many validators at once.

Slashing is not the same as downtime

People often mix the two up. When a validator is simply offline, it misses rewards and pays small penalties, roughly what it would have earned in the same time. That is a cost, not a loss of the deposit.

Slashing is different: it is a penalty on the deposit itself, and the validator is forced out of the network. Good operators accept a little downtime rather than risk running a second copy of the same keys. Safety first, uptime second is the right rule.

How large can the loss be?

On Ethereum a slashing has three parts:

1. An initial penalty, which is small.
2. A forced exit. The validator is removed and its funds stay locked for about 36 days, during which it keeps paying penalties and earns nothing.
3. A correlation penalty, applied about halfway through. Its size depends on how much other stake was slashed around the same time.

The third part is what matters most for risk. A single, isolated mistake usually costs a small share of the stake. But if many validators are slashed together, the penalty grows quickly. If around a third of all stake were slashed in the same window, a validator could lose all of it.

So the real question for an institution or insurer is not only "how good is this operator?" but also "how much stake would fail at the same time, for the same reason?" Concentration in one operator, one cloud provider, one client software or one key setup is what turns small losses into large ones.

The controls that reduce the risk

These are the controls we look for when we assess a staking operator:

• Slashing protection that is always on, and carried over safely whenever validators move (Ethereum has a standard export format for this).
• No "active-active" setups. Only one live copy of each key, ever. Backups stay cold until the main node is confirmed down.
• Doppelganger protection, which makes a validator wait and check that its keys are not already active before it starts signing.
• Remote signers or distributed validator technology (DVT), which keep keys separate from the nodes or split signing across several machines.
• Client diversity, so one software bug cannot hit all validators at once.
• Change management for migrations and upgrades, with written runbooks, a second person checking, and a rollback plan.
• Monitoring and incident response that is tested, not just written down.

Questions to ask an operator

If you are choosing, insuring or overseeing a staking operator, these questions get to the point quickly:

1. How do you make sure a key can never run in two places at once?
2. What happens to slashing protection data when you move validators?
3. How does your failover work, and who decides to switch?
4. Which client software do you run, and how is it spread?
5. Have you ever been slashed? What happened and what changed afterwards?
6. Are your controls audited against a recognised standard?

Clear, specific answers are a good sign. Vague answers about "enterprise-grade security" are not.

Standards are catching up

Until recently there was no shared bar for validator operations, so every institution had to build its own checklist. That is changing.

ValOS, the validator operations standard developed with the Lido community, went live in August 2026. It is aligned with ISO 27001 and SOC 2 and is published open source, so any operator can be assessed against it. For risk committees and underwriters, that means a recognised standard to point to instead of a home-made list.

We have worked on this from both sides: helping define operator best practice, and running slashing workshops for insurance teams such as Munich Re so they can price the risk.