Temporal Parameter Staleness

Skill: Temporal Parameter Staleness Analysis (Sui)

Trigger Pattern: TEMPORAL flag (required) Inject Into: Breadth agents, depth-state-trace Purpose: Analyze cached parameters in multi-step operations on Sui for staleness when capability holders change them mid-operation. Time source on Sui is the shared Clock object at address 0x6.

Trigger Patterns

epoch|period|duration|delay|cooldown|lock_period|timelock|
unbonding_period|claim_delay|withdraw_delay|maturity_time|
clock::timestamp_ms|tx_context::epoch

Reasoning Template

Step 1: Enumerate Multi-Step Operations

Find all operations that span multiple transactions:

Sui-specific multi-step patterns:

• Unstaking: request_withdraw() -> wait epochs -> complete_withdraw()
• Governance: propose() -> wait voting period -> execute()
• Vesting: create_vest() -> wait lock period -> claim()
• Cooldowns: initiate_action() -> wait cooldown (clock-based) -> finalize_action()

Time sources on Sui:

• clock::timestamp_ms(clock: &Clock): Real-time milliseconds. Shared object at 0x6. Monotonically increasing. Used for time-based delays.
• tx_context::epoch(ctx: &TxContext): Epoch number. Incremented roughly every 24 hours. Used for epoch-based staking/unstaking.

For each multi-step operation:

• What parameters are read/cached at Step 1?
• What parameters are re-read at Step N?
• What parameters are used but NOT re-read at Step N? (stored in user's owned object or shared object field)

Step 2: Identify Cached Parameters

For each parameter used across steps:

Sui caching patterns:

• Parameter stored in shared config object: read at initiation, may change before completion
• Parameter stored in user's receipt/ticket object (owned): cached at initiation, immutable until completion
• Parameter in dynamic field: may be updated independently of the operation

Red flags: Parameter is cached at Step 1 AND changeable via admin capability AND NOT re-validated at Step N.

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 (stored in receipt)
2. Admin (via AdminCap) changes param to X + delta in shared config
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
2. Admin changes param to X - delta
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.

Sui-specific staleness vectors:

• Epoch-based operations: If unstaking delay is cached as "epoch + N" and N is changed, the cached deadline may be too early or too late
• Clock-based cooldowns: If cooldown duration changes, users with in-flight operations may bypass or be locked longer
• Fee parameters: If fee rate changes between request and execution, user pays stale rate

PTB bypass check (CRITICAL): Can Steps 1 and N both be executed within a single PTB?

• If YES with time-based waits (clock::timestamp_ms comparisons): bypassed -- same Clock timestamp within a PTB
• If YES with epoch-based waits (tx_context::epoch comparisons): bypassed -- same epoch within a PTB
• Only hot-potato receipts (zero-ability structs) or consumed/destroyed objects can enforce multi-transaction separation
• If PTB bypass is possible -> escalate severity (time controls are ineffective)

Step 3b: Update Source Audit

For each parameter updated from an external source:

• Is the source (e.g., oracle, clock, epoch) 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?
• Sui-specific: Does the parameter depend on clock::timestamp_ms (continuous) vs tx_context::epoch (discrete)? Is the choice appropriate?
• Unit consistency: Verify all timestamp arithmetic uses consistent units. clock::timestamp_ms() returns milliseconds; external sources (Pyth publish_time, cross-chain timestamps) typically use seconds. Any comparison or subtraction without ×1000 conversion → FINDING.

Step 4: Retroactive Application Analysis

For fee/rate parameters that apply to existing state:

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

Sui-specific retroactive patterns:

• Staking reward rate changed -> applies to already-staked positions?
• Fee rate changed -> applies to in-flight withdrawals?
• Slippage tolerance changed -> applies to pending swap requests?