Slashing Conditions

A validator signs two different blocks at the same height on the same chain, which is a direct attack on consensus safety. This is also known as equivocation.

• Mechanism: The protocol detects conflicting signed messages.
• Penalty: Typically results in the slashing of a significant portion (e.g., 5-30%) of the validator's stake and immediate ejection (jailing).
• Example: Signing block A for slot 100 and also signing a different block B for slot 100.

A validator fails to participate in consensus by being offline or unresponsive for a sustained period, harming network liveness.

• Mechanism: Measured by missed block proposals or attestations over an epoch or unbonding period.
• Penalty: Often a smaller, proportional penalty (e.g., based on downtime) rather than a large fixed slash. Repeated offenses can lead to jailing.
• Example: In Cosmos, validators are jailed for missing >95% of blocks in a 10,000-block window.

In networks like Ethereum with sharding or data availability sampling, a validator fails to make their block data available for verification.

• Mechanism: The protocol checks if the data for a proposed block is published and can be sampled.
• Penalty: Slashing for failing to provide data, which is critical for fraud proofs and validity proofs in rollups.
• Context: A core security condition in Ethereum's Dankrad and other data availability layer designs.

A validator votes maliciously in on-chain governance, such as supporting a proposal that clearly steals funds or corrupts the protocol.

• Mechanism: Protocol-defined slashing for voting in a way that violates a social consensus or coded rules.
• Penalty: Varies by chain; may involve slashing and removal from the validator set.
• Note: This is less common than technical faults and relies on subjective fork choice rules.

Validators violating specific rules around Miner/Maximal Extractable Value (MEV). This includes censoring transactions or manipulating the order beyond allowed fair ordering protocols.

• Mechanism: Enforced by proposer-builder separation (PBS) schemes or consensus-layer rules.
• Penalty: Slashing for demonstrable censorship or order manipulation that breaks protocol guarantees.
• Example: In a PBS system, a validator using an unregistered or non-compliant block builder.

This is the most common slashing condition across Proof-of-Stake networks. It occurs when a validator signs two or more conflicting blocks at the same height, which threatens the canonical chain and could enable double-spend attacks.

• Example: Signing blocks for competing forks.
• Purpose: Enforces consensus safety and liveness.
• Typical Penalty: High severity, often resulting in the loss of a significant portion (e.g., 5-10%) of the validator's stake and immediate ejection (jailing).

A validator is slashed for failing to participate in consensus when called upon, such as missing too many block proposals or attestations. This is penalized to ensure network liveness and reliability.

• Detection: Tracked via missed block counts or unavailability over a sliding window.
• Example: A validator node going offline for an extended period.
• Typical Penalty: Lower severity than double signing, often a small, proportional penalty (e.g., 0.01-0.1%) and temporary jailing.

Ethereum's consensus layer defines two explicit slashing conditions for validators.

• Proposer Slashing: A validator proposes two different blocks for the same slot (a form of double signing).
• Attester Slashing: A validator submits two conflicting attestations that surround or double vote.
• Penalty: The slashed validator's effective balance is burned over 36 days, and they are forcibly exited from the validator set.

Chains built with the Cosmos SDK implement slashing through discrete modules with tunable parameters.

• Double Sign: Handled by the Slashing module.
• Downtime: Governed by the Slashing module based on signed block window.
• Unbonding Slashing: Validators can still be slashed for faults committed during the unbonding period, protecting against last-minute attacks.
• Governance: Penalty percentages, jail duration, and other parameters are set via on-chain governance.

In Polkadot's NPoS, slashing affects both validators and the nominators who stake with them, creating shared responsibility.

• Conditions: Includes equivocation, unresponsiveness, and misbehavior reported by Fishermen.
• Collateral Damage: Slashing is applied proportionally to the validator's stake, and nominators backing that validator are also penalized.
• Severity Tiers: Penalties are non-linear; larger stakes face proportionally higher slash percentages for the same offense.

The design of slashing conditions is a critical cryptoeconomic security parameter. Teams must balance deterrence with validator viability.

• Key Trade-offs: Setting penalties too low reduces security; setting them too high discourages participation.
• Parameter Examples: Slash fraction, slash window, jail duration, and minimun stake to be slashed.
• Dynamic Adjustments: Some protocols, like Celo, implement slashing weight that adjusts penalties based on the validator's historical performance.

A validator is slashed for signing two different blocks at the same height, which could enable a double-spend attack. This is considered a severe fault because it directly threatens the canonical chain.

• Mechanism: The protocol detects conflicting signatures from the same validator key.
• Penalty: Typically severe (e.g., 5-10% of stake) and may result in the validator being forcibly exited from the active set.

Validators are penalized for being offline and failing to perform their duties (e.g., proposing or attesting to blocks). This ensures network liveness and reliability.

• Detection: Missed attestations or block proposals over a sliding window.
• Penalty: Usually a small, incremental leak of stake (e.g., inactivity leak), which is less severe than for double signing but accumulates over time.

Some networks implement slashing for violating specific governance rules or consensus parameters. This can include voting on invalid chain upgrades or exceeding resource limits.

• Example: In a delegated Proof-of-Stake (DPoS) system, validators may be slashed for failing to maintain sufficient hardware uptime as defined by governance parameters.
• Purpose: Enforces adherence to network-wide policies beyond core consensus.

Harsh slashing conditions maximize security but can increase validator churn if honest operators are penalized for minor mistakes or infrastructure issues. This trade-off impacts network stability.

• Security Priority: High penalties deter attacks but require professional operation.
• Decentralization Impact: Excessive risk may discourage smaller, independent validators, leading to centralization among large, well-funded operators.

Validators use slashing protection databases to prevent accidental double-signing, especially when migrating or restoring validator keys. This is a critical operational safeguard.

• Function: Tracks previously signed messages to prevent the validator client from signing conflicting ones.
• Standard: Implemented in clients like Prysm, Lighthouse, and Teku as a local database file.

The slashing ratio determines the penalty severity. Many protocols implement a whistleblower mechanism where other validators can submit proof of a violation for a reward.

• Economic Design: The whistleblower reward is often a percentage of the slashed funds, incentivizing network monitoring.
• Outcome: This creates a self-policing system where validators are economically motivated to report malicious actors.

A voluntary action where a validator operator intentionally triggers their own slashing penalty. This is a defensive tactic used in specific failure scenarios, such as when a validator's private key is compromised. By self-slashing, the operator can:

• Force the ejection of the compromised validator from the active set
• Initiate the withdrawal of the remaining stake after a penalty period
• Prevent an attacker from causing more severe, repeated slashing penalties.

A severe, non-linear slashing penalty applied when many validators are slashed for the same offense within a short time window (e.g., 36 days in Ethereum). The penalty increases with the total amount of stake slashed, punishing coordinated attacks or widespread client failures more harshly than isolated incidents. This mechanism protects against cartel formation and catastrophic consensus failures.

A safety mechanism implemented in validator client software (like Prysm or Lighthouse) that prevents a validator from accidentally signing two conflicting messages. It maintains a local database of signed messages and blocks the validator client from creating a signature that would trigger a double-signing slashing condition. This is a critical defense against operational errors, not malicious intent.