Slashing Conditions

A validator is slashed for signing two or more conflicting blocks or votes at the same height. This is a primary defense against nothing-at-stake attacks and long-range attacks. For example, a validator might be penalized for:

• Proposing two different blocks for slot n.
• Voting for two different blocks in the same consensus round. This ensures there is only one canonical chain history.

Validators are penalized for being offline and failing to perform their duties, such as proposing or attesting to blocks. This enforces liveness and network reliability. Penalties are often proportional to the downtime duration and the number of other validators also offline. Extended downtime can lead to an ejection from the validator set.

Some networks implement slashing for violating specific governance rules or protocol parameters. This can include:

• Exceeding resource limits (e.g., block gas limits).
• Failing to process certain types of transactions correctly.
• Violating data availability rules in modular networks. These conditions tailor slashing to the specific security model of the chain.

Penalties are not uniform and are designed to be proportional to the offense. A typical structure includes:

• A base penalty (e.g., 1 ETH) for the fault.
• A correlation penalty that increases if many validators are slashed simultaneously (mitigating correlated failures).
• Ejection from the active validator set. The slashed funds are typically burned or redistributed to honest validators.

To prevent a slashed validator from immediately fleeing with remaining funds, staked assets are subject to an unbonding period. This is a mandatory waiting time (e.g., 21-36 days) before withdrawal. During this period, slashing penalties can still be applied if a past offense is discovered, acting as a crucial accountability window.

If the Ethereum beacon chain fails to finalize for more than 4 epochs, an inactivity leak is triggered. This is a specialized slashing mechanism where validators failing to attest are penalized with an increasing rate until finalization resumes. It's designed to recover liveness even if up to one-third of validators are offline.

Occurs when an oracle node reports data that deviates significantly from the consensus value or a trusted source beyond a defined threshold. This is the primary defense against submitting incorrect data.

• Example: Reporting an ETH price of $3,200 when the network consensus is $3,500, with a maximum allowed deviation of 2%.

Triggered when a node fails to submit a data attestation within a required time window. This ensures network liveness and reliability for data consumers.

• Consequence: Nodes that go offline or are unresponsive can be slashed for failing to perform their duty, protecting the service-level agreement.

A Byzantine fault where a node signs two conflicting data points or attestations for the same data request or block height. This is a severe attack on consensus.

• Mechanism: Similar to double-signing in Proof-of-Stake blockchains, it is cryptographically detectable and results in a severe slash, often the full stake.

Applied when a group of nodes is detected coordinating to manipulate reported data. Networks use cryptoeconomic design and statistical analysis to identify suspicious voting patterns.

• Defense: Schemes like data attestation and decentralized aggregation make collusion economically irrational and detectable.

A node attempting to withdraw its staked assets before the unbonding period ends or while it has pending slashing accusations. This prevents nodes from escaping penalties.

• Function: Acts as a bonding mechanism, ensuring stake remains locked and at risk during the dispute resolution or challenge period.

Enforced when a node violates network-upgraded parameters or rules established through on-chain governance. This ensures nodes adapt to protocol improvements.

• Examples: Ignoring a new minimum stake requirement, failing to upgrade client software by a mandated deadline, or not adhering to new data source requirements.

A cardinal sin in consensus protocols and a primary slashing condition. This occurs when a validator signs two different blocks at the same height. It's considered a malicious attack that can lead to chain forks. Networks like Cosmos and Ethereum impose severe slashing penalties (e.g., 5% of stake) for this offense, as it directly threatens the blockchain's canonical history.

A slashing condition for liveness failures. Validators are expected to be online and participating. Extended periods of unavailability (e.g., missing a certain number of consecutive blocks) can trigger a smaller, proportional penalty. This ensures the network remains active and that validators maintain reliable infrastructure. Penalties are typically less severe than for double-signing.

A voluntary action where a validator intentionally triggers their own slashing penalty. This is a last-resort security mechanism. If a validator's private keys are compromised, the operator can self-slash to quickly eject the compromised validator from the active set, preventing the attacker from causing more damage (like double-signing) with the stolen keys.

A complementary penalty to slashing. When a validator violates a slashing condition, they are not only fined but also jailed or tombstoned. Jailing temporarily removes the validator from the active set, preventing them from participating (and causing further harm). Tombstoning is a permanent jailing, often applied for egregious faults like double-signing.