Offenses and Slashes¶

Introduction¶

In Polkadot's Nominated Proof of Stake (NPoS) system, validator misconduct is deterred through a combination of slashing, disabling, and reputation penalties. Validators and nominators who stake tokens face consequences for validator misbehavior, which range from token slashes to restrictions on network participation.

This page outlines the types of offenses recognized by Polkadot, including block equivocations and invalid votes, as well as the corresponding penalties. While some parachains may implement additional custom slashing mechanisms, this guide focuses on the offenses tied to staking within the Polkadot ecosystem.

Offenses¶

Polkadot is a public permissionless network. As such, it has a mechanism to disincentivize offenses and incentivize good behavior. You can review the parachain protocol to understand better the terminology used to describe offenses. Polkadot validator offenses fall into two categories: invalid votes and equivocations.

Invalid Votes¶

A validator will be penalized for inappropriate voting activity during the block inclusion and approval processes. The invalid voting related offenses are as follows:

Backing an invalid block - a para-validator backs an invalid block for inclusion in a fork of the relay chain
ForInvalid vote - when acting as a secondary checker, the validator votes in favor of an invalid block
AgainstValid vote - when acting as a secondary checker, the validator votes against a valid block. This type of vote wastes network resources required to resolve the disparate votes and resulting dispute

Equivocations¶

Equivocation occurs when a validator produces statements that conflict with each other when producing blocks or voting. Unintentional equivocations usually occur when duplicate signing keys reside on the validator host. If keys are never duplicated, the probability of an honest equivocation slash decreases to near zero. The equivocation related offenses are as follows:

Equivocation - the validator produces two or more of the same block or vote
- GRANDPA and BEEFY equivocation - the validator signs two or more votes in the same round on different chains
- BABE equivocation - the validator produces two or more blocks on the relay chain in the same time slot
Double seconded equivocation - the validator attempts to second, or back, more than one block in the same round
Seconded and valid equivocation - the validator seconds, or backs, a block and then attempts to hide their role as the responsible backer by later placing a standard validation vote

Penalties¶

On Polkadot, offenses to the network incur different penalties depending on severity. There are three main penalties: slashing, disabling, and reputation changes.

Slashing¶

Validators engaging in bad actor behavior in the network may be subject to slashing if they commit a qualifying offense. When a validator is slashed, they and their nominators lose a percentage of their staked DOT or KSM, from as little as 0.01% up to 100% based on the severity of the offense. Nominators are evaluated for slashing against their active validations at any given time. Validator nodes are evaluated as discrete entities, meaning an operator can't attempt to mitigate the offense on another node they operate in order to avoid a slash.

Any slashed DOT or KSM will be added to the Treasury rather than burned or distributed as rewards. Moving slashed funds to the Treasury allows tokens to be quickly moved away from malicious validators while maintaining the ability to revert faulty slashes when needed.

Multiple active nominations

A nominator with a very large bond may nominate several validators in a single era. In this case, a slash is proportionate to the amount staked to the offending validator. Stake allocation and validator activation is controlled by the Phragmén algorithm.

A validator slash creates an unapplied state transition. You can view pending slashes on Polkadot.js Apps. The UI will display the slash per validator, the affected nominators, and the slash amounts. The unapplied state includes a 27-day grace period during which a governance proposal can be made to reverse the slash. Once this grace period expires, the slash is applied.

Equivocation Slash¶

The Web3 Foundation's Slashing mechanisms page provides guidelines for evaluating the security threat level of different offenses and determining penalties proportionate to the threat level of the offense. Offenses requiring coordination between validators or extensive computational costs to the system will typically call for harsher penalties than those more likely to be unintentional than malicious. A description of potential offenses for each threat level and the corresponding penalties is as follows:

Level 1 - honest misconduct such as isolated cases of unresponsiveness
- Penalty - validator can be kicked out or slashed up to 0.1% of stake in the validator slot
Level 2 - misconduct that can occur honestly but is a sign of bad practices. Examples include repeated cases of unresponsiveness and isolated cases of equivocation
- Penalty - slash of up to 1% of stake in the validator slot
Level 3 - misconduct that is likely intentional but of limited effect on the performance or security of the network. This level will typically include signs of coordination between validators. Examples include repeated cases of equivocation or isolated cases of unjustified voting on GRANDPA
- Penalty - reduction in networking reputation metrics, slash of up to 10% of stake in the validator slot
Level 4 - misconduct that poses severe security or monetary risk to the system or mass collusion. Examples include signs of extensive coordination, creating a serious security risk to the system, or forcing the system to use extensive resources to counter the misconduct
- Penalty - slash of up to 100% of stake in the validator slot

See the next section to understand how slash amounts for equivocations are calculated. If you want to know more details about slashing, please look at the research page on Slashing mechanisms.

Slash Calculation for Equivocation¶

The slashing penalty for GRANDPA, BABE, and BEEFY equivocations is calculated using the formula below, where x represents the number of offenders and n is the total number of validators in the active set:

min((3 * x / n )^2, 1)

The following scenarios demonstrate how this formula means slash percentages can increase exponentially based on the number of offenders involved compared to the size of the validator pool:

Minor offense - assume 1 validator out of a 100 validator active set equivocates in a slot. A single validator committing an isolated offense is most likely a mistake rather than malicious attack on the network. This offense results in a 0.09% slash to the stake in the validator slot
```
flowchart LR
N["Total Validators = 100"]
X["Offenders = 1"]
F["min(3 * 1 / 100)^2, 1) = 0.0009"]
G["0.09% slash of stake"]

N --> F
X --> F
F --> G
```
Moderate offense - assume 5 validators out a 100 validator active set equivocate in a slot. This is a slightly more serious event as there may be some element of coordination involved. This offense results in a 2.25% slash to the stake in the validator slot
```
flowchart LR
N["Total Validators = 100"]
X["Offenders = 5"]
F["min((3 * 5 / 100)^2, 1) = 0.0225"]
G["2.25% slash of stake"]

N --> F
X --> F
F --> G
```
Major offense - assume 20 validators out a 100 validator active set equivocate in a slot. This is a major security threat as it possible represents a coordinated attack on the network. This offense results in a 36% slash and all slashed validators will also be chilled
```
flowchart LR
N["Total Validators = 100"]
X["Offenders = 20"]
F["min((3 * 20 / 100)^2, 1) = 0.36"]
G["36% slash of stake"]

N --> F
X --> F
F --> G
```

The examples above show the risk of nominating or running many validators in the active set. While rewards grow linearly (two validators will get you approximately twice as many staking rewards as one), slashing grows exponentially. Going from a single validator equivocating to two validators equivocating causes a slash four time as much as the single validator.

Validators may run their nodes on multiple machines to ensure they can still perform validation work if one of their nodes goes down. Still, validator operators should be cautious when setting these up. Equivocation is possible if they don't coordinate well in managing signing machines.

Best Practices to Avoid Slashing¶

The following are advised to node operators to ensure that they obtain pristine binaries or source code and to ensure the security of their node:

Always download either source files or binaries from the official Parity repository
Verify the hash of downloaded files
Use the W3F secure validator setup or adhere to its principles
Ensure essential security items are checked, use a firewall, manage user access, use SSH certificates
Avoid using your server as a general-purpose system. Hosting a validator on your workstation or one that hosts other services increases the risk of maleficence
Avoid cloning servers (copying all contents) when migrating to new hardware. If an image is needed, create it before generating keys
High Availability (HA) systems are generally not recommended as equivocation may occur if concurrent operations happen—such as when a failed server restarts or two servers are falsely online simultaneously
Copying the keystore folder when moving a database between instances can cause equivocation. Even brief use of duplicated keystores can result in slashing

Below are some examples of small equivocations that happened in the past:

Network	Era	Event Type	Details	Action Taken
Polkadot	774	Small Equivocation	The validator migrated servers and cloned the keystore folder. The on-chain event can be viewed on Subscan.	The validator didn't submit a request for the slash to be canceled.
Kusama	3329	Small Equivocation	The validator operated a test machine with cloned keys. The test machine was online simultaneously as the primary, which resulted in a slash. Details can be found on Polkassembly.	The validator requested a slash cancellation, but the council declined.
Kusama	3995	Small Equivocation	The validator noticed several errors, after which the client crashed, and a slash was applied. The validator recorded all events and opened GitHub issues to allow for technical opinions to be shared. Details can be found on Polkassembly.	The validator requested to cancel the slash. The council approved the request as they believed the error wasn't operator-related.

Slashing Across Eras¶

There are three main difficulties to account for with slashing in NPoS:

A nominator can nominate multiple validators and be slashed as a result of actions taken by any of them
Until slashed, the stake is reused from era to era
Slashable offenses can be found after the fact and out of order

To balance this, the system applies only the maximum slash a participant can receive in a given time period rather than the sum. This ensures protection from excessive slashing.

Disabling¶

The disabling mechanism is triggered when validators commit serious infractions, such as backing invalid blocks or engaging in equivocations. Disabling stops validators from performing specific actions after they have committed an offense. Disabling is further divided into:

On-chain disabling - lasts for a whole era and stops validators from authoring blocks, backing, and initiating a dispute
Off-chain disabling - lasts for a session, is caused by losing a dispute, and stops validators from initiating a dispute

Off-chain disabling is always a lower priority than on-chain disabling. Off-chain disabling prioritizes disabling first backers and then approval checkers.

Note

The material in this guide reflects the changes introduced in Stage 2. For more details, refer to the State of Disabling issue on GitHub.

Reputation Changes¶

Some minor offenses, such as spamming, are only punished by networking reputation changes. Validators use a reputation metric when choosing which peers to connect with. The system adds reputation if a peer provides valuable data and behaves appropriately. If they provide faulty or spam data, the system reduces their reputation. If a validator loses enough reputation, their peers will temporarily close their channels to them. This helps in fighting against Denial of Service (DoS) attacks. Performing validator tasks under reduced reputation will be harder, resulting in lower validator rewards.

Penalties by Offense¶

Below, you can find a summary of penalties for specific offenses:

Offense	Slash (%)	On-Chain Disabling	Off-Chain Disabling	Reputational Changes
Backing Invalid	100%	Yes	Yes (High Priority)	No
ForInvalid Vote	-	No	Yes (Mid Priority)	No
AgainstValid Vote	-	No	Yes (Low Priority)	No
GRANDPA / BABE / BEEFY Equivocations	0.01-100%	Yes	No	No
Seconded + Valid Equivocation	-	No	No	No
Double Seconded Equivocation	-	No	No	Yes

Edit this page

Last update: November 15, 2024
| Created: October 16, 2024