Oracle Aggregation

Overview

Oracle aggregation may occur across exchanges within one node, across independent node observations, or at both levels. Common methods include median, weighted median, trimmed mean, volume weighting, and outlier rejection.

The algorithm should reflect the data type and attack model. A median resists some extreme values but cannot fix correlated sources or a stale majority. Weighting can improve market representation while concentrating influence in a few venues. Integrators should document source eligibility, timestamps, weights, minimum quorum, decimal normalization, and treatment of missing values. Contracts need confidence and freshness checks after aggregation. Monitoring should compare the final result with constituent observations so source failures do not remain hidden behind a plausible combined value.

Operational 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 Aggregation should specify the reported value or event, authorized sources, aggregation method, update trigger, timestamp, decimals, and validity conditions.

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.