the hash slinging slasher

Eth2 Slashing Prevention Tips

Raul Jordan
Nov 29, 2020 · 12 min read

This post regards information on slashing in the Eth2 network — what it is, why it’s used, how to avoid being slashed, and what to do if slashing occurs. Most of the information presented within this documentation is implementation agnostic, meaning it will be applicable to all users, regardless of whether they choose to run Prysm, Lighthouse, Teku, Nimbus, or another implementation for their validator setup.

*Important Disclaimer*

This post is merely meant as a set of tips for security best practices. It does not guarantee slashing prevention.

What is slashing

Slashing is not to be confused with inactivity penalties, which are normal loss of funds incurred over time the longer your validator is offline and unable to perform its duties

The goal of slashing is to disincentive those who seek to harm the eth2 network, and inversely reward those who maintain, police, and operate the network as intended. The main purpose of slashing is to mitigate attacks that might be otherwise cheap to perform on the eth2 network, such as trivially creating conflicting forks of validators attesting on a different view of historical checkpoints.

A validator that correctly follows the protocol never emits a slashable vote in normal operations. Validators will not be slashed for simply being offline.

How slashing works

Though slashing is intended to be a method of punishment, even as a benevolent user, it is still possible to get slashed if you have a validator has been configured improperly; thus, it is critical to understand how to properly set up and manage a validator client and operating system, and to avoid attempting advanced instructions without understanding its entire functionality.

Slashing occurs in the following scenarios:

  1. A validator proposes two conflicting blocks at the same slot with a different root (essentially a hash of the inner data). If this action were not penalized, it would be trivial for validators to try to create unnecessary forks and chaos in the chain. Note: simply proposing the same, exact block twice is not a slashable offense.
  2. A validator attests to two conflicting blocks at the same slot. This is known as a double vote, and also signifies that a validator could be attempting to create conflicting forks of the chain. Note: simply voting for the same, exact block twice is not a slashable offense
  3. A validator casts a vote which “surrounds” or is “surrounded” by a previous vote, meaning the validator is trying to vote against history, which is a slashable offense.
eth2 surround vote deep dive by @protolambda

What happens after a slashing

A couple of additional resources can be found here and here.

In the event a validator is slashed, a number of things will happen:

  1. The slashed validator is forced to exit the beacon chain ~36 days in the future
  2. Three penalties types are earned by the slashed validator (source):
  3. A minimum penalty is incurred at the moment a proposed whistleblower includes the whistleblowing message in a block
  4. A penalty at the beginning of every epoch until the validator leaves the exit queue
  5. A special penalty is applied midway between the time when the whistleblowing message is included in a block, and the time when the slashed offender can withdraw. This special penalty is proportional to how many other validators have also been slashed over the period. The maximum applied can be as high as the whole offender’s effective balance.

This means if a validator is slashed, it will immediately see a penalty, and will continue to incur penalties for ~36 days until it can exit, AND also receive a one time penalty at day ~18 in the ~36 day period. The amount slashed is also influenced by the number of validators who are also found to be guilty of slashable offenses (in addition to the number online) during the same epoch (ie, is this a coordinated attack or a single bad actor). For a more detailed breakdown, please visit here.

Finally, it is worth noting slashed validators cannot re-enter the validator set. A new stake and keys would need to be generated to continue validating. Slashing is irreversible!

Being slashed essentially results in a slow bleed of ETH staked, with a big hit taken at the halfway point as well. An exit from the beacon chain is possible after ~36 days and any remaining ETH staked can also be withdrawn, but a sizable portion of ETH will be lost during this ~36 day time period.

Common user mistakes leading to slashing

The same validating keys running on two servers at the same time, with one of them perhaps serving as a failover in case the first one is down


You migrate your keys to another machine or another eth2 client without also migrating your slashing protection history

You delete or lose your slashing protection history in your validator client:

Validating using a containerized environment that does not have a persistent volume

Protocol bug that may cause slashing errors (this is very unlikely, worst case scenario)

When choosing a validator, it is critical to understand how to set up, configure, upgrade, and troubleshoot any installed software. A great resource to better understand the risks of staking Eth2 can be found here at Another great resource explaining how to detect slashing conditions can be found here.

Who Does the Slashing?


All the network needs is 1 honest slasher client to monitor the network because any slashings found are propagated to the entire network for it to be put into a block as soon as possible.

Whistleblower Rewards

While incentivizing detection is valuable, simply running a slasher client will not have you earn whistleblower rewards if you find a slashing in Prysm. By default, any slashings found are propagated to the network to be included in the block ASAP so usually the reward goes to the proposer immediately after the slashing is detected, not to the validator running the slasher.

Running a slasher is not meant to be profitable. Slashing is meant to be rare and whistleblower rewards are low on purpose. Running a slasher is meant to be an altruistic action, and once again, only a single honest, properly functioning slasher needs to be active in the network to catch slashable offenses. Thankfully, this is a low bar to entry, and we envision quite a lot of users and entities will run slashers to ensure network security.

Slashing Prevention

Local slashing protection database

Local slashing protection does not protect against running multiple validator instances with the same validator keys, as the database is local to the validator it is paired with.

This database only tracks the signing events of the validators in that local instance. This also means if the user changes their validator to a different client (for example, moving from Lighthouse to Nimbus), or moves to a new hardware setup (installing on a fresh linux machine, moving to a hosted solution) it is critical to also migrate the signing history database. This will ensure the history of past actions is preserved on any new client moving forward.

Remote slashing protection

An alternative implementation for slashing prevention is the use of slasher itself as a middleware between your beacon node and validator client. Before a validator client submits a block or an attestation, it asks the slasher if it is slashable first. If the check passes, the data will go through to the beacon node. This is the most advanced form of slashing protection as slasher is, ideally, aware of everything happening in the network and has recorded history of blocks and attestations for every validator. There is a caveat, however, that remote slashing protection is not yet optimized in Prysm as our slasher is still a resource hog. Given the high resource consumption of our slasher, it might cause your validator to miss attestations or blocks. Remote slashing protection is meant to run as an added layer on top of local slashing protection. For security reasons, local slashing protection cannot be disabled in Prysm.

Migrating Your Slashing Protection History

The slashing protection standard: EIP-3076

  • Information about the genesis state of the chain the validating history is for (to differentiate between testnets and mainnet)
  • Information about all signed blocks and signed attestations for validator public keys the user is running

By exporting this file and importing it when you migrate to another computer or eth2 client, you get a ton of benefits and are able to remain protected against simple slashing conditions that may occur if you did not have this local history stored.

Importing existing validating keys into Prysm

Exporting your slashing protection history from Prysm

Important files to assist your migration from one machine running Prysm to another

  1. Turn off your beacon node and validator on machine 1, make sure it is not running as a system process. You can check this using the process monitor tools of your OS, or a command line tool such as top or htop and check for anything containing the name “prysm” “validator” or “beacon”
  2. Note the location of your wallet directory. If you used the default when you started Prysm, you can view its path at the top of the output of `validator accounts list`, which varies based on your operating system
  3. Take that entire directory and move it over to your next machine
  4. If you modified your validators’ — datadir, also migrate that directory to your next machine
  5. Wait at least a few epochs, sync your beacon node on your second machine, then start your validator client on your second machine
  6. Ensure you never run the same keys again on machine 1 or anywhere else


Prysmatic Labs

Implementing Ethereum 2.0 - Full Proof of Stake + Sharding