Oracle Feed

Overview

Oracle feeds commonly publish asset prices, exchange rates, reserves, weather, rates, or other measurements. A feed has an identifier, source methodology, aggregation process, units, decimals, update conditions, and supported networks.

The same named feed can use different contracts, node sets, thresholds, or timing on separate chains. A latest value is not necessarily fresh, sufficiently liquid, or appropriate for an application’s market. Historical access can also differ from current-value interfaces. Developers should verify official addresses, read timestamps and round metadata, normalize decimals, and reject stale or incomplete reports. Risk teams need monitoring for deviations, heartbeat misses, and source concentration. Applications should document why the chosen feed matches the asset and settlement logic. High-value actions may require delayed execution, secondary evidence, or a circuit breaker rather than automatic acceptance. Client software should enforce freshness and deviation limits, validate the expected feed or contract, and define fallback behavior for missing, disputed, or implausible data.

Audit 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. A report can be validly published on-chain while still being stale, mis-scaled, or unsuitable for the decision that consumes it. Oracle Feed should specify the reported value or event, authorized sources, aggregation method, update trigger, timestamp, decimals, and validity conditions. The assurance 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.