Skip to content

Flawed Slashing Conditions

id: LS24H
title: Flawed Slashing Conditions 
baseSeverity: H
category: consensus-mechanism
language: solidity
blockchain: [ethereum]
impact: Honest participants may be punished or malicious actors may evade slashing
status: draft
complexity: high
attack_vector: internal
mitigation_difficulty: hard
versions: [">=0.6.0", "<latest"]
cwe: CWE-697
swc: SWC-132

πŸ“ Description

  • Flawed slashing conditions arise when the logic responsible for penalizing validators, stakers, or participants:
  • Incorrectly identifies misbehavior,Fails to detect actual violations, Can be abused to penalize honest actors or evaded by malicious ones.
  • This typically affects staking protocols, validator networks, or oracles, and can result in:
  • Unfair slashing of good actors (loss of funds, reputation),No punishment for actual malicious behavior (downtime, equivocation, delay),Governance disputes and loss of network trust.

🚨 Vulnerable Code

function slash(address validator, bool evidence) external onlySlasher {
    if (evidence) {
        stake[validator] = 0; // ❌ No validation of evidence, no protection
        emit Slashed(validator);
    }
}

πŸ§ͺ Exploit Scenario

Step-by-step breakdown:

  1. A malicious actor gains access to the slasher role (e.g. governance, multisig).
  2. They pass a true flag as evidence, regardless of validator behavior.
  3. The validator’s stake is immediately zeroed out, despite being honest.
  4. Meanwhile, another malicious validator avoids slashing due to missing checks or poor liveness detection.

Assumptions:

  • Validators avoid slashing by exiting before finalization.
  • Network latency causes false downtime slashing.
  • Lack of cryptographic proof in misbehavior evidence.

βœ… Fixed Code

function slash(address validator, bytes calldata evidence) external onlySlasher {
    require(validateEvidence(evidence, validator), "Invalid or insufficient proof");
    require(block.timestamp < evidenceExpiry[evidence], "Evidence expired");

    uint256 penalty = (stake[validator] * penaltyRate) / 100;
    stake[validator] -= penalty;
    emit Slashed(validator, penalty);
}

function validateEvidence(bytes calldata data, address validator) internal view returns (bool) {
    // e.g. double-signature, equivocation proof, signed block hash
    // βœ… Use verifiable cryptographic checks
    return isValidProof(data, validator);
}

🧭 Contextual Severity

- context: "Anyone can slash using loosely defined uptime logic"
  severity: H
  reasoning: "Leads to griefing and full stake loss"
- context: "Slashing requires governance or multisig approval"
  severity: M
  reasoning: "Impact contained by oversight"
- context: "Slashing disabled or only used for reputation"
  severity: L
  reasoning: "No asset loss, minimal impact"

πŸ›‘οΈ Prevention

Primary Defenses

  • Require cryptographic proof of misbehavior (e.g., BLS signatures, PoS equivocation).
  • Enforce time bounds, cooldowns, and challenge periods before slashing.
  • Ensure only authorized, auditable sources (e.g. consensus or quorum) can initiate slashing.

Additional Safeguards

  • Emit detailed Slashed logs with reason, evidence hash, and proof for on-chain audits.
  • Allow appeal or dispute mechanisms for challenged slashing events.
  • Use off-chain consensus proofs (e.g., attestation reports or ZK-based evidence) for accuracy.

Detection Methods

  • Slither: unconditional-slash, missing-evidence-check, slasher-role-danger detectors.
  • Manual audit of all slashing conditions and roles.
  • Simulation of false positive slashing attacks in fuzz tests.

πŸ•°οΈ Historical Exploits

  • Name: Beaconcha.in Slashing Misreporting Incident
  • Date: April 2023
  • Loss: Potential misinterpretation of validator behavior; no direct financial loss
  • Post-mortem: Link to post-mortem

πŸ“š Further Reading


βœ… Vulnerability Report

id: LS24H
title: Flawed Slashing Conditions 
severity: H
score:
impact: 5         
exploitability: 3 
reachability: 3   
complexity: 4     
detectability: 4  
finalScore: 4.15

πŸ“„ Justifications & Analysis

  • Impact: Critical β€” could unjustly destroy validator capital or let malicious actors go free.
  • Exploitability: Moderate β€” needs privileged access or flawed logic.
  • Reachability: Common in custom staking, L2, or oracle systems.
  • Complexity: High β€” safe slashing systems require protocol-grade engineering.
  • Detectability: High β€” flaws are exposed in audits and validator testing.