Skip to content
Financial Context Wiki

Blockchain oracle

A blockchain oracle supplies contracts with authenticated claims about data they cannot derive from deterministic chain state; safe use depends on the full source, reporting, transport, verification, and consumer path.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A blockchain oracle is a system that gives a contract an authenticated claim about data the chain’s deterministic state transition cannot derive by itself. A price feed may report a market reference, a pull oracle may verify a user-relayed signed update, and an optimistic oracle may accept a bonded assertion unless disputed. Verifiable randomness and cross-chain messages are related external-input systems, but their claims and security models are not interchangeable with price feeds.

Putting a value onchain proves that a transaction, signature, quorum, proof, or dispute outcome satisfied specified rules. It does not cryptographically prove that an external market, weather event, or human judgment is objectively true. The complete trust path is the observed phenomenon, sources and venues, publishers, aggregation, report authentication, transport, onchain proxy or verifier, consumer validation, and the business action that moves value.

Decentralization must be assessed separately at each layer. Many signers can share one API, exchange, cloud provider, operator, or administrator. A fresh signed median can still use the wrong pair or decimals, reflect an illiquid market, or be unsafe at the consumer’s trade size. The consumer remains responsible for identity, units, status, timestamps, L2 availability, exposure limits, fallback behavior, and recovery.

How it works

  1. Pin the chain and block, consumer contract and action, exact feed or proxy address and feed ID, implementation version, base/quote pair, decimals or exponent, market hours, and value at risk.
  2. Trace the full trust path from phenomenon and venues through publishers, source aggregation, signer or quorum aggregation, transport, onchain verification, proxy controls and consumer logic; test source, operator, infrastructure and administrator independence separately.
  3. Decode the deployed interface and report. Validate feed identity, signature or proof and domain, sequence or round, signed answer, status or confidence, source timestamp, onchain update time, replay behavior, revert behavior and upgrade state.
  4. Normalize units once and apply explicit range, sign and timestamp checks. Distinguish source observation or publication time, report creation, source-chain inclusion, relay finality, target-chain update and consumer block time.
  5. Apply action-specific maxAge, deviation, confidence and cross-source rules. On supported L2 deployments, check sequencer status and recovery grace separately; for composite values, constrain freshness by the oldest required dependency.
  6. Compare the reference with executable market depth and estimate manipulation or corruption cost against the consumer’s borrow, mint, liquidation, trade or settlement exposure. Treat AMM spot and TWAP construction as pool- and version-specific.
  7. Define normal, degraded, paused and recovery states per action; preserve safe debt repayment or collateral addition where possible, monitor sources and configuration, rehearse missing, stale, wrong and manipulated reports, and reconcile every affected balance and action after recovery.

Push and pull describe delivery patterns, not one universal payment or trust model. A publisher may create a signed report while an arbitrary user relays it and pays the update fee. Heartbeat and deviation settings can trigger publication but are not a delivery guarantee or consumer freshness limit. A fallback or last-good value is a controlled degradation mode whose direction, units, age, independence and allowed actions must be validated again.

Worked examples

  • Lending threshold. A position has 10 ETH collateral, an oracle price of 3,000 USD/ETH, debt of 18,000 USD, and a 75% liquidation threshold. Collateral is 30,000 USD, LTV is 60%, and healthFactor = 10 * 3,000 * 0.75 / 18,000 = 1.25. The trigger price is 18,000 / (10 * 0.75) = 2,400 USD/ETH. At 2,300 USD/ETH, health factor is 0.9583333333 and debt/collateral is 78.2608695652%: liquidation is eligible, but nominal collateral of 23,000 USD still exceeds debt before bonus, fees and execution effects.
  • Unit failure. A raw answer of 250,000,000,000 with 8 decimals means 2,500 USD. Dividing it by 10^18 instead produces 0.00000025 USD, understating the price by 10^10. A valid signature and recent timestamp do not repair a consumer’s unit error.
  • Aggregation choice. Observations [99, 100, 100, 101, 160] have median 100 and arithmetic mean 112, a 12% difference relative to the median. The median resists one high outlier in this teaching set, but if all five reporters depend on one compromised API and report 130, the median is also 130.
  • Freshness by action. At consumerClock = 1,800,000,000, a report with sourceTimestamp = 1,799,998,200 has age = 1,800 seconds. New borrowing with maxAge = 900 seconds rejects it by 900 seconds; a repayment path with maxAge = 3,600 seconds accepts it with 1,800 seconds of headroom. One report can be unsafe for increasing exposure yet acceptable for reducing it.

Risks

  • Wrong chain, deployment, implementation, or network environment.
  • Wrong proxy, aggregator, feed ID, asset, or contract version.
  • Reversed base/quote direction or inconsistent denomination.
  • Decimal, exponent, fixed-point, sign, rounding, or unit mismatch.
  • Zero, negative, out-of-domain, overflowed, or truncated answer is accepted.
  • Missing, zero, future, carried-forward, or misidentified timestamp is accepted.
  • Consumer freshness limit is too loose for the asset and action.
  • Consumer freshness limit is too tight and creates denial of service or blocks risk reduction.
  • Heartbeat or deviation configuration is treated as a service-level guarantee.
  • Market closure, corporate action, depeg, venue outage, or carried-forward data semantics are ignored.
  • Multiple publishers share one API, exchange, cloud, operator, key path, or methodology.
  • Signer threshold, quorum, key custody, report authentication, domain, or replay controls fail.
  • Aggregation, weighting, outlier, confidence, or source-selection rules are unsuitable.
  • Source liquidity is thin, wash-traded, fragmented, stale, or manipulable at the protected size.
  • Spot or short-window TWAP manipulation, multi-block control, ordering, censorship, or MEV changes the input.
  • Publisher, relay, gas, congestion, reorg, or chain outage prevents timely delivery.
  • L2 sequencer status, recovery grace, cross-chain relay clock, or finality dependency is omitted.
  • Proxy, administrator, signer set, configuration, migration, pause, or feed deprecation changes unnoticed.
  • Fallback is stale, correlated, differently scaled, circular, or activates through an unsafe fail-open or blanket fail-closed path.
  • Consumer exposure exceeds manipulation or corruption cost, while monitoring, caps, pause, recovery, liquidation and bad-debt reconciliation fail.

Common misconceptions

  • “An oracle predicts the future.” Most oracles authenticate observations, reports, proofs or resolved assertions about a defined time and object.
  • “Signed or onchain data is therefore objectively true.” Authentication and consensus prove rule compliance, not the external fact’s economic correctness.
  • “More nodes automatically mean independent decentralization.” Sources, operators, infrastructure, keys and governance can remain correlated.
  • “The latest fresh value is a fair executable price.” Freshness does not establish direction, units, confidence, liquidity or executable depth.
  • “A reputable provider removes consumer integration risk.” The application still owns deployment identity, decoding, freshness, L2 gates, exposure, fail modes and recovery.

Sources

Navigation

Search the wiki...