Oracle Deviation

Overview

Oracle systems calculate deviation to detect market movement, faulty sources, or the need for an on-chain update. The comparison can use percentage change, basis points, absolute units, or statistical distance. Meaning depends on the reference and calculation direction. A small percentage can be material for stable assets, while a larger move may be ordinary for volatile markets. Outliers can indicate manipulation, stale sources, or legitimate price discovery. Implementers should define formula, denominator, precision, source timestamp, and sign handling. Monitoring should preserve both compared values rather than only the resulting percentage. Applications must not confuse an oracle‘s deviation trigger with acceptable trading slippage or confidence around the reported price.

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 Deviation 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. Client software 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.