Clock Staleness Remediation

Overview

After Solana network halts, the Clock sysvar resumes from a stale timestamp. Programs that use timestamps in financial logic (vesting, expiration, TWAP) can be exploited in the window between restart and clock catch-up. The fix is to implement staleness bounds that reject operations when the clock is too far behind expected values.

Recommended Fix

Before (Vulnerable)

pub fn claim_vested_tokens(ctx: Context<Claim>) -> Result<()> {
    let clock = Clock::get()?;
    let vesting = &ctx.accounts.vesting;

    // VULNERABLE: no staleness check
    if clock.unix_timestamp >= vesting.unlock_time {
        token::transfer(ctx.accounts.transfer_ctx(), vesting.amount)?;
    }
    Ok(())
}

After (Fixed)

const MAX_STALE_SLOTS: u64 = 600;  // ~5 minutes at 400ms/slot

pub fn claim_vested_tokens(ctx: Context<Claim>) -> Result<()> {
    let clock = Clock::get()?;
    let global = &mut ctx.accounts.global_state;

    // FIXED: reject if clock appears stale
    let slot_delta = clock.slot.saturating_sub(global.last_known_slot);
    require!(
        slot_delta <= MAX_STALE_SLOTS || global.last_known_slot == 0,
        ErrorCode::ClockStale
    );

    let vesting = &ctx.accounts.vesting;
    if clock.unix_timestamp >= vesting.unlock_time {
        token::transfer(ctx.accounts.transfer_ctx(), vesting.amount)?;
    }

    // Update tracking
    global.last_known_slot = clock.slot;
    global.last_known_timestamp = clock.unix_timestamp;
    Ok(())
}

Alternative Mitigations

1. Use slot numbers instead of timestamps

Slot numbers are monotonically increasing and less susceptible to manipulation than timestamps:

pub fn check_deadline(clock: &Clock, deadline_slot: u64) -> Result<()> {
    // Slots advance predictably; less affected by clock drift
    require!(clock.slot <= deadline_slot, ErrorCode::DeadlinePassed);
    Ok(())
}

2. Emergency pause mechanism

Implement an admin-controlled pause that activates after network restarts:

pub fn process(ctx: Context<Process>) -> Result<()> {
    let config = &ctx.accounts.config;
    require!(!config.paused, ErrorCode::Paused);

    // Normal processing...
    Ok(())
}

pub fn set_pause(ctx: Context<Admin>, paused: bool) -> Result<()> {
    ctx.accounts.config.paused = paused;
    Ok(())
}

3. Tolerance windows for time comparisons

Instead of exact timestamp checks, use tolerance ranges:

const TOLERANCE_SECONDS: i64 = 600;  // 10-minute tolerance

pub fn check_expiry(clock: &Clock, expiry: i64) -> bool {
    // Allow operations only if clock is within tolerance of expiry
    clock.unix_timestamp >= expiry
        && clock.unix_timestamp <= expiry + TOLERANCE_SECONDS
}

Common Mistakes

Mistake 1: Only checking timestamps, not slots

// WRONG: timestamp alone can be stale after halt
if clock.unix_timestamp > last_update + 300 {
    return Err(ErrorCode::Stale);
}

Timestamps are derived from validator votes and can lag. Cross-check both slot and timestamp for robust staleness detection.

Mistake 2: Setting staleness threshold too high

// WRONG: 24-hour staleness window is too permissive
const MAX_STALE: i64 = 86400;

Network restarts typically resolve within minutes to hours. A staleness threshold of 5-15 minutes is appropriate for most DeFi applications.

Mistake 3: Not storing last-known values

// WRONG: no reference point to detect staleness
let clock = Clock::get()?;
if clock.unix_timestamp > expiry { ... }

Without storing the last-seen slot and timestamp, there is no baseline to compare against for staleness detection.