temporal-parameter-staleness

name	temporal-parameter-staleness
description	Trigger Pattern interval|epoch|period|duration|delay|cooldown|lock_period|timelock|unbonding|claim_delay|withdraw_delay|maturity - Inject Into Breadth agents, depth-state-trace

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:

Operation	Step 1 (Initiate)	Wait Condition	Step N (Complete)	Clock Source
{op_name}	{initiate_ix}()	{wait_condition}	{complete_ix}()	slot / unix_timestamp / epoch

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

Clock Field	Resolution	Monotonicity	Accuracy	Use Case
slot	~400ms	Strictly increasing	Exact (validator-produced)	Short-duration timing, cooldowns
unix_timestamp	~400ms	Mostly increasing (can drift +-1-2s)	+/- 1-2 seconds (estimated by validator)	Human-readable delays, longer durations
epoch	~2-3 days (432k slots)	Strictly increasing	Exact	Staking epoch boundaries, long cycles

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:

Parameter	Account Stored In	Read At Step	Cached in User Account?	Authority-Changeable?	Re-Validated At Completion?
{param}	{config_account}	initiate()	YES/NO	YES/NO (which authority)	YES/NO

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

Vector	Description	Severity Modifier
Epoch boundary crossing	Operation initiated in epoch N, completed in epoch N+1. Staking yields, validator rewards, inflation rate change at epoch boundary.	Higher if protocol depends on epoch-specific rates
Slot leader timing	Leader schedule known ~2 epochs ahead. Authority can time parameter changes to specific slots with high precision.	Increases likelihood for timing-sensitive parameters
Same-tx guarantee	Within one tx, Clock is constant. Cannot have intra-tx staleness. Multi-instruction composition is safe from timing drift.	Reduces severity for single-tx operations
Clock drift	unix_timestamp can drift +-1-2s from wall clock. If protocol uses tight timestamp comparisons (<5s), drift can cause unexpected behavior.	Medium if tight comparisons used

---

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:

Parameter	Stored In	Applies To	Retroactive?	Impact
{fee_param}	{config PDA}	{what it affects}	YES/NO	{if retroactive: who is harmed}

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?

---

Step 5: Assess Severity

For each staleness issue:

• Who is affected? (single user, all users with pending operations, protocol)
• Is the impact bounded? (capped by fee range, max delay, etc.)
• Can it be exploited intentionally? (authority front-running via leader schedule knowledge)
• Is there a recovery path? (re-initiate, cancel instruction, admin override)
• Slot-level precision: Given Solana's ~400ms slots and predictable leader schedule, how precisely can an attacker time the exploitation?

Severity Assessment (Rule 10 - Worst-State)

Use worst realistic operational state, not current on-chain snapshot:

Severity assessed at: pending_claims=MAX_USERS, fee_delta=MAX_FEE-MIN_FEE, tvl=$XXM
Rationale: Protocol designed for up to {N} concurrent pending operations per documentation

---

Key Questions (must answer all)

1. What multi-step operations exist? (request/claim, stake/cooldown/unstake, propose/vote/execute)
2. For each cached parameter: can authority change it between steps?
3. What happens if a delay DECREASES after initiation? (users locked longer than necessary vs original expectation)
4. What happens if a delay INCREASES after initiation? (users can claim too early relative to new policy)
5. Are fees applied retroactively to existing positions or only to new ones?
6. Is there a maximum parameter range that bounds the staleness impact?
7. Solana-specific: Does the protocol use slot or unix_timestamp for timing? If unix_timestamp, is the +-1-2s drift handled?
8. Solana-specific: Do any operations span Solana epoch boundaries? If so, what changes at the boundary?
9. Solana-specific: Is there a crank/refresh instruction? What happens if it is never called?

---

Common False Positives

• Immutable config: If the config account has no update instruction or authority is revoked, no staleness
• Bounded ranges: If min/max bounds limit the change magnitude (enforced on-chain), impact may be Low
• User can cancel: If users can cancel pending operations and re-initiate with new parameters, reduced severity
• Timelock protection: If parameter changes require a Clockwork/Squads timelock, users have time to react
• Same-transaction operations: Operations that complete within a single transaction cannot have Clock staleness between steps
• Re-read at completion: If Step N re-reads the parameter from the source config account (not a cached copy), no staleness for that parameter

---

Instantiation Parameters

{CONTRACTS}           - Programs to analyze
{MULTI_STEP_OPS}      - Identified multi-step operations
{CACHED_PARAMS}       - Parameters cached at initiation (stored in user PDAs/accounts)
{AUTHORITY_PARAMS}    - Authority-changeable parameters
{DELAY_PARAMS}        - Delay/cooldown parameters (in slots, timestamps, or epochs)
{FEE_PARAMS}          - Fee/rate parameters that may apply retroactively
{CLOCK_SOURCE}        - Clock field used (slot/unix_timestamp/epoch)

---

Output Schema

Field	Required	Description
multi_step_ops	yes	List of multi-step operations found
cached_params	yes	Parameters cached across steps (stored in which account)
staleness_vectors	yes	How cached params can become stale
retroactive_fees	yes	Fees applied retroactively
clock_source_audit	yes	Which Clock field is used and whether appropriate
epoch_boundary_effects	yes	Operations spanning epoch boundaries
finding	yes	CONFIRMED / REFUTED / CONTESTED
evidence	yes	Code locations with line numbers
step_execution	yes	Status for each step

---

Step Execution Checklist (MANDATORY)

Step	Required	Completed?	Notes
1. Enumerate Multi-Step Operations	YES
2. Identify Cached Parameters	YES
3. Model Staleness Impact (both directions)	YES
3b. Update Source Audit	YES
4. Retroactive Application Analysis	YES
5. Assess Severity	YES

Cross-Reference Markers

After Step 2: If cached parameters are authority-changeable -> MUST complete Step 3 with BOTH increase and decrease scenarios.

After Step 4: Cross-reference with SEMI_TRUSTED_ROLES (Solana version) for authority functions that change these parameters.

After Step 3: If protocol uses unix_timestamp for comparisons tighter than 5 seconds -> FLAG clock drift concern.

After Step 1: If any operation spans Solana epoch boundaries -> cross-reference with staking/inflation rate changes.