Temporal Parameter Staleness

TEMPORAL_PARAMETER_STALENESS Skill (DAML)

Trigger Pattern: interval|period|duration|delay|cooldown|lock_period|timelock|deadline|maturity|expiry|valid_until|getTime Inject Into: Breadth agents, depth-state-trace Finding prefix: [DML-TPS-N] Rules referenced: R2, R8, R10, R13, R14

Cached parameters in multi-step (multi-transaction) operations become stale when an authority changes the source between steps. On DAML, time is read with getTime : Update Time inside a choice, returning ledger time (a record time the submitter does NOT choose; it is bounded by the transaction's ledger-time window). A deadline/duration is a template field (Time or a RelTime/Int of seconds); a value is "cached" when a choice copies a config field into a successor contract at Step 1, and Step N reads the cached copy instead of re-fetching the live config. There are no slots/epochs/blocks — time is the ledger Time value. This skill is the staleness/cross-transaction lens; ENSURE_INVARIANTS §4 is the single-choice deadline-enforcement boundary lens — cross-reference, do not duplicate.

Step 1: Enumerate Multi-Step (Multi-Transaction) Operations

Find all operations that span multiple transactions, typically a Propose/Accept or initiate/complete pattern:

For each multi-step operation:

• What parameters/fields are read and copied into a successor contract at Step 1?
• What fields are re-fetched from the live config at Step N?
• What fields are USED at Step N but NOT re-fetched (cached, possibly stale)?
• Is time read via getTime (ledger time) or taken from a caller-supplied Time argument? A caller-supplied time lets the caller choose "now" — always a finding.

DAML Time Semantics

Critical property: within a single transaction (one choice and its consequences), all getTime calls return the same Time — there is no intra-transaction time variation. Multi-step time attacks require separate transactions.

Step 2: Identify Cached Parameters

For each parameter used across steps:

DAML caching patterns:

• Snapshot into successor: a Propose choice copies config.feeRate/config.deadline into the Proposal contract; Accept reads the Proposal's copy, not the live config.
• Cached deadline: a Proposal stores deadline = addRelTime now period computed at Step 1; if period later changes in config, the Proposal's deadline is stale.
• Re-fetch pattern: Step N does cfg <- fetchByKey @Config ... and reads live values — no staleness for those fields.

Red flags: a field is copied into the Step-1 successor AND an authority can change the source config AND Step N does NOT re-fetch the source.

Step 3: Model Staleness Impact

For each cached parameter that can become stale:

Scenario A: Parameter INCREASES between steps
1. Party initiates at Step 1 — successor contract stores param = X
2. Authority exercises a setter choice: config param = X + delta
3. Party completes at Step N — uses cached X from the successor
4. Impact: {what happens with stale X when live config is X + delta}

Scenario B: Parameter DECREASES between steps
1. Party initiates at Step 1 — successor stores param = X
2. Authority setter: config param = X - delta
3. Party completes at Step N — uses cached X
4. Impact: {what happens with stale X when live config is X - delta}

BOTH directions are mandatory — increase and decrease often differ.

DAML-Specific Staleness Vectors

Step 3b: Update-Source Audit

For each parameter updated from another contract (a price/rate feed contract fetched in a choice):

• Is the source the correct representation of what this parameter tracks?
• Is the source contract's identity validated? Can a forged config/feed ContractId be substituted via a caller-supplied argument (cross-reference CID_CAPABILITY_SAFETY)?
• Should the parameter be fixed for a period (per epoch) rather than re-read every completion?
• Which choice updates it, who controls that choice, and what is the protocol state if it is never exercised (no refresh)?

Step 4: Retroactive Application Analysis

For fee/rate/deadline fields that apply to existing in-flight state:

DAML retroactive patterns:

• Config setter: an authority archives+recreates the config with a new feeRate. All pending completions that re-fetch the live config now use the new rate — retroactively changes returns for parties who initiated under the old rate.
• Cooldown/period setter: changing cooldownPeriod in config makes parties who already initiated wait longer/shorter — retroactive on in-flight Proposals (if Step N recomputes from live period).
• Rate-at-complete pattern: if Step N reads the live config field (not the Step-1 snapshot), any authority change between steps applies retroactively.

Rule 2 direction check: can the authority's change make a party-facing choice behave unexpectedly (e.g. setting cooldownPeriod = 0 removes a withdrawal-delay protection; setting maxWithdrawal = 0 blocks all withdrawals)? Does the change retroactively affect parties in active operations?