Temporal Parameter Staleness

TEMPORAL_PARAMETER_STALENESS Skill (Solana)

Trigger Pattern: interval|epoch|period|duration|delay|cooldown|lock_period|timelock|unbonding|claim_delay|withdraw_delay|maturity Inject Into: Breadth agents, depth-state-trace Finding prefix: [TPS-N] Rules referenced: R2, R8, R10, R13, R14

Cached parameters in multi-step operations become stale when authority changes them mid-operation. On Solana, timing has unique properties: 400ms slot time, Clock sysvar shared across all instructions in a transaction, Solana epoch boundaries (~2-3 days, 432k slots), and leader schedule predictability.

Step 1: Enumerate Multi-Step Operations

Find all operations that span multiple transactions:

For each multi-step operation:

• What parameters are read/cached at Step 1 (stored in an account)?
• What parameters are re-read at Step N?
• What parameters are used but NOT re-read at Step N?
• Which clock source is used? (Clock::get()?.unix_timestamp, Clock::get()?.slot, Clock::get()?.epoch)

Solana Clock Semantics

Critical property: Within a single transaction, ALL instructions see the same Clock values. Unlike EVM where multi-block operations have timing variation per block, a Solana transaction's instructions share identical timing. Multi-step timing attacks require separate transactions.

Step 2: Identify Cached Parameters

For each parameter used across steps:

Solana caching patterns:

• Config account cache: User's request account stores a snapshot of config params at initiation time (e.g., request.fee_rate = config.fee_rate)
• Inline cache: Parameter copied into instruction data or user PDA during Step 1
• Re-read pattern: Step N re-reads from the config/global account (no staleness possible for that param)
• Epoch snapshot: Protocol snapshots state at epoch boundary, uses snapshot until next epoch

Red flags: Parameter is cached in a user account at Step 1 AND authority can change the source account AND Step N does NOT re-read from source.

Step 3: Model Staleness Impact

For each cached parameter that can become stale:

Scenario A: Parameter INCREASES between steps
1. User initiates at Step 1 - user PDA stores param = X (read from config account)
2. Authority updates config account: param = X + delta
3. User completes at Step N - uses cached X from user PDA
4. Impact: {what happens with stale value X when current is X + delta}

Scenario B: Parameter DECREASES between steps
1. User initiates at Step 1 - user PDA stores param = X
2. Authority updates config account: param = X - delta
3. User completes at Step N - uses cached X
4. Impact: {what happens with stale value X when current is X - delta}

BOTH directions are mandatory - increase and decrease often have different impacts.

Solana-Specific Staleness Vectors

Step 3b: Update Source Audit

For each parameter updated from an external source (oracle account, other program's state):

• Is the source the correct representation of what this parameter tracks?
• Is the source account ownership validated? (Solana-specific: can a fake account be substituted?)
• Should this parameter be fixed for a period (e.g., per epoch, per cycle) rather than continuously refreshed?
• Which instructions update it? Which instructions SHOULD update it? Any mismatch?
• Is there a refresh or crank instruction? If yes, who calls it and when? Can staleness occur if the crank is not called?

Step 4: Retroactive Application Analysis

For fee/rate parameters that apply to existing state:

Solana retroactive patterns:

• Global config update: Authority changes fee_bps in a global config account. All pending claims calculated at completion time using new rate - retroactively changes expected returns.
• Epoch-based rate: Protocol sets rate per epoch. Users who entered mid-epoch may have their partial-epoch calculation affected by next-epoch rate change.
• Account closure incentive: If close_fee changes, users with pending close requests pay different amount than expected.

Rule 2 direction check: Can the authority's parameter change make a user-facing instruction behave unexpectedly? (e.g., setting cooldown_slots = 0 removes timing protection, setting max_deviation = 0 disables oracle bounds). Does the change retroactively affect users in active positions?