Oracle Staleness

Overview

Oracle staleness describes data that remains available but no longer represents a sufficiently recent observation. The relevant age is usually measured from the source or publication timestamp to the consumer’s current chain time. A value can become stale because markets are quiet, heartbeats are missed, reporters lose quorum, transmission fails, the destination chain halts, or the consumer reads an outdated round. Unchanged prices are not automatically fresh, and recent block inclusion does not prove recent observation.

Contracts should enforce a documented maximum age appropriate to the asset and action. They may pause, reduce limits, use an independent fallback, or require manual review when the threshold is exceeded. Monitoring must distinguish stale data from unavailable data and from a legitimately unchanged market. The trust model includes data providers, node operators, signers, transmitters, contracts, governance, and any emergency controls. Multiple reporters do not create independence when they rely on the same exchange, API, infrastructure provider, or market methodology.

High-value actions may require delayed execution, secondary evidence, or a circuit breaker rather than automatic acceptance. Integrations should enforce freshness and deviation limits, validate the expected feed or contract, and define fallback behavior for missing, disputed, or implausible data.

Review records should retain the exact report, block reference, source configuration, and rule that consumed it. This distinction is essential when a technically valid oracle message produces an economically incorrect payment, liquidation, or release decision. Risk-control point: A readable oracle value may still be unsafe when its observation age exceeds the application’s defined freshness limit.