/temporal-parameter-staleness

name: "temporal-parameter-staleness"
description: "Trigger Pattern TEMPORAL flag (required) - Inject Into Breadth agents, depth-state-trace"

TEMPORAL_PARAMETER_STALENESS Skill

> **Trigger Pattern**: TEMPORAL flag (required) > **Inject Into**: Breadth agents, depth-state-trace > **Purpose**: Analyze cached parameters in multi-step operations that can become stale when admin/capability holders change them mid-operation, and external state stored and relied upon without re-verification

Trigger Patterns

epoch|period|duration|delay|cooldown|lock_period|timelock|
unbonding_period|claim_delay|withdraw_delay|maturity_time|
pending_|request_|fulfill_|complete_|finalize_

Reasoning Template

Step 1: Enumerate Multi-Step Operations

Find all operations that span multiple transactions:

| Operation | Step 1 (Initiate) | Wait Condition | Step N (Complete) | Resource Storing State | |-----------|-------------------|----------------|-------------------|-----------------------| | {op_name} | {initiate_fn}() | {wait_condition} | {complete_fn}() | {PendingRequest / similar} |

**Aptos multi-step patterns**:

• Request/fulfill patterns: `request_withdraw()` -> wait for epoch/time -> `fulfill_withdraw()`
• Lock/unlock patterns: `lock()` -> cooldown expires -> `unlock()`
• Proposal/execute patterns: `propose()` -> voting period -> `execute()`
• Unstaking: `request_unstake()` -> unbonding period -> `claim()`
• Pending operations stored in `Table<address, PendingRequest>` or `SmartTable` or per-user resource

For each multi-step operation:

• What parameters are read/cached at Step 1 (stored in the pending resource)?
• What parameters are re-read at Step N?
• What parameters are used but NOT re-read at Step N?

Step 2: Identify Cached Parameters

For each parameter used across steps:

| Parameter | Read At Step | Stored In | Admin-Changeable? | Re-Validated At Completion? | |-----------|-------------|-----------|-------------------|----------------------------| | {param} | initiate() L{N} | {PendingRequest.field} | YES/NO | YES/NO | | {param} | initiate() L{N} | Not stored (read at completion from resource) | YES/NO | YES (re-read) |

**Red flags**: Parameter is cached in pending resource at Step 1 AND admin-changeable AND NOT re-validated at Step N.

**Aptos-specific caching patterns**:

• Parameters stored in global resource (`move_to` at initiation, `move_from` at completion)
• Parameters stored in `Table` entries keyed by user address
• Parameters stored in Object resources
• Parameters read from a separate config resource (may change between steps)

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 with param = X (cached in PendingRequest)
2. Admin/capability holder changes param to X + delta in config resource
3. User completes at Step N
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 with param = X (cached in PendingRequest)
2. Admin/capability holder changes param to X - delta in config resource
3. User completes at Step N
4. Impact: {what happens with stale value X when current is X - delta}

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

**Common staleness impacts on Aptos**:

• Fee rate decreased after initiation -> user pays old (higher) fee at completion
• Withdrawal delay increased -> user can complete earlier than current policy allows
• Exchange rate changed -> user's pending operation uses outdated rate
• Collateral ratio changed -> user's pending position evaluated against stale threshold

Step 3b: Update Source Audit (External State Staleness)

For each parameter updated from an external source:

| Parameter | External Source | Read When | Stored Where | Re-Read At Use? | Staleness Window | |-----------|---------------|-----------|-------------|-----------------|-----------------| | {param} | {oracle / other module / timestamp} | {read_fn} | {resource.field} | YES/NO | {time between read and use} |

**Analysis questions**:

• Is the source (e.g., oracle price, external module state, `timestamp::now_seconds()`) the correct representation of what this parameter tracks?
• Should this parameter be fixed for a period (e.g., per epoch, per cycle) rather than continuously refreshed?
• Which functions update it? Which functions SHOULD update it? Any mismatch?
• If external state is validated at entry point A, stored, then relied upon at entry point B without re-verification -> FINDING (R8 attack vector 4)
• **Unit consistency**: Verify all timestamp arithmetic uses consistent units. `timestamp::now_seconds()` returns seconds; `timestamp::now_microseconds()` returns microseconds. Mixing these without ×1_000_000 conversion in comparisons, subtractions, or staleness checks → FINDING.

Step 4: Retroactive Application Analysis

For fee/rate parameters that apply to existing state:

| Parameter | Applies To | Retroactive? | Impact | |-----------|-----------|--------------|--------| | {fee_param} | {what it affects} | YES/NO | {if retroactive: who is harmed} |

**Pattern**: Fee changes that affect already-accrued rewards or already-initiated operations are retroactive.

**Aptos-specific retroactive risks**:

• Global fee rate stored in config resource, applied to ALL pending operations at completion
• Reward rate change affecting accumulated but unclaimed rewards
• Staking parameters changing for users already in unbonding period
• Exchange rate formula change applied to pending withdrawals

Step 5: Assess Severity

For each staleness issue:

| Factor | Assessment | |--------|-----------| | Who is affected? | {single user / all users with pending ops / protocol} | | Is the impact bounded? | {capped by fee range / max delay / parameter bounds} | | Can it be exploited intentionally? | {admin front-running / user t