Skip to content

Validator slashing has no grace period or reputation recovery path #497

Description

@RUKAYAT-CODER

Background

slashing.rs currently treats every inactivity or fault detection as an immediate, permanent penalty, with two related gaps called out directly in the code:

/// # TODO
/// - Add a grace period counter so a validator gets one warning before
///   being slashed (reduces false positives from transient network issues).
pub fn check_inactivity(env: &Env, validator: Address) -> Result<bool, BridgeError> { ... }
/// # TODO
/// - Consider a time-based reputation recovery mechanism so validators can
///   rehabilitate after a period of honest behaviour.
fn calculate_new_reputation(current: u32, reason: &SlashingReason) -> u32 { ... }

Today, check_inactivity slashes on the very first detected inactivity window with no tolerance for transient network issues (a validator briefly unreachable due to a network blip is penalized the same as one that's actually gone offline), and calculate_new_reputation only ever subtracts via saturating_sub — reputation can never recover, so a validator who was slashed once for a minor issue (e.g. Inactivity, -5) stays permanently closer to the MIN_ACTIVE_REPUTATION = 40 removal threshold even after months of honest behavior.

Implementation Plan

  • Add a grace-period counter (e.g., stored alongside ValidatorInfo) so a validator gets one recorded warning on first inactivity detection and is only slashed if inactivity persists past a second check.
  • Add a time-based reputation recovery mechanism: reputation gradually increases toward a cap during sustained honest activity (e.g., a small recovery increment per elapsed period since the last slash, capped at the original baseline).
  • Add tests: a single transient inactivity event does not trigger a slash (only a warning), a persistent inactivity event does slash, and reputation recovers over time after a slash given continued honest activity.

Acceptance Criteria

  • A validator's first inactivity detection results in a warning, not an immediate slash
  • Reputation recovers over time following honest behavior after a slash, bounded by a sensible cap
  • Tests cover the grace-period and recovery paths

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions