Skip to content

Handling Stale Oracle Data

Purpose

Prevent stale or conflicting observations from enabling deposits, rewards, or claims.

Detection

Staleness appears when the latest accepted risk observation exceeds riskFreshnessWindow, reserve proof is older than the deposit maximum, or backend sources disagree about epoch/finality.

Procedure

  1. Stop affected deposit and claim windows.
  2. Identify affected vaults and latest accepted epoch.
  3. Compare backend feed state against on-chain riskObservation, safe epoch, reserve proof timestamp, and claimability views.
  4. If source data is delayed but consistent, wait and communicate.
  5. If source data is wrong or conflicting, open an incident and prevent posting.
  6. Once finalized data is available, submit updateRiskObservationFinalModel with unique source ids.
  7. Recompute claimability and deposit readiness.

Abort Conditions

Do not widen riskFreshnessWindow to mask an outage without governance/risk approval. Do not post observations from unfinalized, conflicting, or untraceable sources.

Post-Checks

  • Risk state and freshness are current.
  • Pending claims invalidated by stale assumptions are cleared.
  • Deposit readiness reflects the restored evidence.
  • Monitoring alert is closed with archived proof.

Evidence To Archive

Feed logs, finalized epoch proof, source ids, submitted transaction, emitted risk/conflict events, and post-state reads.