Oracle Liveness

Overview

Oracle liveness means the reporting system continues making progress under its stated operating assumptions. A live feed delivers acceptable updates despite individual source failures, node outages, network delay, or temporary blockchain congestion. Liveness differs from correctness. A feed can update frequently with inaccurate values, or report correct values too late for a liquidation or settlement decision. It depends on available sources, reporter quorum, transmission paths, destination-chain progress, and update incentives.

Consumers should monitor heartbeat misses, observation age, publisher participation, failed transmissions, and destination inclusion. Contracts need explicit maximum-age checks and safe behavior when liveness fails. Redundant feeds can improve availability, but only when their data, infrastructure, and governance dependencies are genuinely independent. 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.

A cryptographically valid report may still contain old data, unexpected decimals, or values inappropriate for the intended decision. Oracle Liveness should specify the reported value or event, authorized sources, aggregation method, update trigger, timestamp, decimals, and validity conditions.

Trust assumptions include 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. Client software should enforce freshness and deviation limits, validate the expected feed or contract, and define fallback behavior for missing, disputed, or implausible data.