Oracles

In one minute

• Why oracles? Blockchains can’t fetch web data by themselves. Oracles deliver external data (like prices) to smart contracts.
• What they provide: Price feeds, randomness (VRF), event results (sports/weather), and automation (call a function on a schedule).
• Key idea: An oracle’s job is to be accurate, timely, and hard to corrupt. Designs trade off cost, speed, and trust assumptions.

Note: Educational only — not financial advice. Always use official docs to verify oracle addresses and feeds.

What an oracle actually does (plain English)

Main oracle categories

Trust models (how secure is the feed?)

• Single-source oracle: One provider posts data. Cheap & simple, but a single point of failure.
• Multi-source aggregator: Many reporters sign values; a contract aggregates (e.g., median). Resilient to outliers but costs more gas.
• First-party vs third-party: Data creator posts directly (first-party) or a network of nodes fetches from public APIs (third-party).
• Economic security: Some designs use staking/slashing or reputation to punish bad data.
• Cryptographic proofs: Signed reports, merkle proofs, or zk-proofs to verify origin and integrity.

No oracle removes all trust. Good systems make cheating costly and easy to detect.

Update patterns

• Push: The oracle updates on-chain periodically or when price moves beyond a threshold.
• Pull: A contract/user requests an update; the oracle answers and posts the result.
• Heartbeat & deviation: Feeds refresh at least every X seconds and sooner if price moves Y%.
• Finality awareness: Good oracles consider L1/L2 finality to avoid reading stale/temporary values.

Common pitfalls & attacks

• Thin-liquidity manipulation: If a price feed relies on an exchange with low volume, attackers can move the price briefly to trigger liquidations.
• Stale data: If updates pause during congestion or outages, apps may act on old numbers.
• Single reporter failure: Downtime or compromise if only one source is used.
• Bridge/L2 issues: On L2s, ensure feeds handle settlement delays and sequencer downtime.
• API spoofing: If sources aren’t authenticated, man-in-the-middle or fake endpoints can inject bad data.

Practical examples

User checklist

• Does the dApp clearly state which oracle/feeds it uses?
• Are feeds aggregated from multiple sources? Is there a status page/explorer?
• For big actions (borrowing, leverage), consider waiting for several confirmations/finality around volatile events.
• Beware of apps that use a DEX’s spot price directly without time-weighting or aggregation.

Builder checklist

• Use aggregated, tamper-resistant feeds; avoid single points of failure.
• Set sensible staleness checks (max age) and circuit breakers for extreme moves.
• Document feed decimals, units, and update triggers; handle reverts & fallback logic.
• If on L2, plan for sequencer downtime and bridge delays; cache last-good values safely.
• Log feed versions and allow upgrades via multisig + timelock for transparency.

See also: DeFi, Smart contracts, and On-chain vs off-chain.

Quick glossary

• Oracle: A system that brings off-chain data on-chain for smart contracts.
• Data feed: A continuously updated value (e.g., ETH/USD) available to contracts.
• Aggregator: Combines multiple sources into one robust value (median/mean with filters).
• VRF: Verifiable Random Function — randomness with a cryptographic proof.
• Keeper/Automation: A service that triggers on-chain actions when conditions are met.
• Staleness check: A maximum allowed age for a feed before a contract refuses to use it.