Oracle Failure

Overview

Oracle failure can originate in source markets, APIs, node operators, aggregation, signatures, relayers, contracts, or the destination chain. A feed may keep returning data while its underlying market has become illiquid or disconnected.

Consequences include wrong liquidations, frozen lending, mispriced swaps, failed settlements, and bad debt. Decentralizing nodes does not remove correlated source failure or application mistakes such as incorrect decimals. Applications should validate freshness, confidence, bounds, and source status, then enter a documented safe mode when requirements fail. Fallback feeds need independent assumptions and tested switching logic. Incident recovery should identify the exact reports used, protect funds from repeated actions, and reconcile decisions made during degraded data. Integrations should enforce freshness and deviation limits, validate the expected feed or contract, and define fallback behavior for missing, disputed, or implausible data. High-value actions may require delayed execution, secondary evidence, or a circuit breaker rather than automatic acceptance.

This distinction is essential when a technically valid oracle message produces an economically incorrect payment, liquidation, or release decision. Review records should retain the exact report, block reference, source configuration, and rule that consumed it. Oracle Failure should specify the reported value or event, authorized sources, aggregation method, update trigger, timestamp, decimals, and validity conditions. Publication on-chain proves neither freshness nor business suitability; scale, timestamp, and intended use still require validation. Multiple reporters do not create independence when they rely on the same exchange, API, infrastructure provider, or market methodology. Trust assumptions include data providers, node operators, signers, transmitters, contracts, governance, and any emergency controls.