# Temporal Parameter Staleness

> Trigger Pattern TEMPORAL flag (required) - Inject Into Breadth agents, depth-state-trace

- Skill: `plamentsv/temporal-parameter-staleness-4` (Agent Skill)
- Install (CLI): `npx skillmds@latest add plamentsv/temporal-parameter-staleness-4`
- Raw SKILL.md: https://api.skillmd.com/api/skills/plamentsv/temporal-parameter-staleness-4/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: plamentsv (https://skillmd.com/u/plamentsv)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/plamentsv/temporal-parameter-staleness-4

---


# 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 timing manipulation} |
| Is there a recovery path? | {re-initiate / admin override / cancel pending} |
| Worst-case fund impact? | {quantified amount or percentage} |

## Key Questions (must answer ALL)

1. What multi-step operations exist? (request/claim, deposit/lock/withdraw, propose/vote/execute)
2. For each cached parameter: can admin change it between steps?
3. What happens if a delay DECREASES after initiation? (users locked longer than necessary with old delay)
4. What happens if a delay INCREASES after initiation? (users can claim too early with old delay)
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?

## Common False Positives

- **Immutable parameters**: If the parameter is set once at initialization and never changed, no staleness
- **Bounded ranges**: If min/max bounds limit the change magnitude, impact may be Low
- **User can re-initiate**: If users can cancel and restart with new parameters, reduced severity
- **Timelock protection**: If parameter changes require timelock, users have time to react
- **Epoch-bound parameters**: If parameters only change at epoch boundaries and operations complete within an epoch, no mid-operation staleness

## Instantiation Parameters
```
{CONTRACTS}           -- Move modules to analyze
{MULTI_STEP_OPS}      -- Identified multi-step operations
{CACHED_PARAMS}       -- Parameters cached at initiation (stored in pending resources)
{ADMIN_PARAMS}        -- Admin-changeable parameters (in config resources)
{DELAY_PARAMS}        -- Delay/cooldown parameters
{FEE_PARAMS}          -- Fee/rate parameters that may apply retroactively
```

## Output Schema

| Field | Required | Description |
|-------|----------|-------------|
| multi_step_ops | yes | List of multi-step operations found |
| cached_params | yes | Parameters cached across steps |
| staleness_vectors | yes | How cached params can become stale |
| external_staleness | yes | External state stored and relied upon without re-verification |
| retroactive_fees | yes | Fees applied retroactively |
| 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 (external state) | YES | | |
| 4. Retroactive Application Analysis | YES | | |
| 5. Assess Severity | YES | | |

### Cross-Reference Markers

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

**After Step 3b**: If external state is stored and re-used without re-verification -> cross-reference with ORACLE_ANALYSIS.md for oracle-sourced state.

**After Step 4**: Cross-reference with SEMI_TRUSTED_ROLES.md for admin functions that change these parameters and whether users can grief the parameter update mechanism.