Oracle

What is a blockchain oracle?

Imagine a smart thermostat that adjusts your home’s temperature but doesn’t have access to the weather forecast. On its own, it has no idea whether it’s sunny, stormy, or snowing. To make appropriate decisions, it needs a reliable external information source.

That’s what an oracle does. It feeds real-world data to smart contracts that would otherwise be blind to external events.

A blockchain oracle connects blockchains to external data or systems. Since smart contracts operate in closed environments and can’t access information outside their chain, oracles act as trusted messengers that bring in real-world data or send on-chain data out.

Oracles fetch off-chain information (e.g., prices, temperature, identity data), verify it, and deliver it to smart contracts. This allows decentralized applications (dApps) to respond to real-world events and automate decisions.
‍

As blockchain adoption grows, the demand for real-time, trustworthy data increases. But with that need comes a essential problem known as the oracle problem.
‍

What is the oracle problem?

The oracle problem is a fundamental challenge in blockchain systems: smart contracts can’t access off-chain data on their own.
‍

• Root cause: Blockchains are deterministic. All nodes must reach identical conclusions from the same data. Without oracles, smart contracts risk inconsistencies.
  ‍
• Tradeoff: This ensures security and consensus but isolates blockchains from external data.
  ‍
• Why it matters: Many use cases, especially in decentralized finance (DeFi), gaming, and insurance, depend on real-world information.
  ‍
• The oracle challenge: Oracles bridge this gap, but they introduce trust assumptions. While blockchains are designed to be trustless, oracles must be trusted to deliver accurate, tamper-resistant data.
  ‍
• Decentralized solution: Modern oracles solve this by distributing trust across multiple nodes without compromising decentralization.

However, while these solutions reduce trust assumptions, they don't eliminate them entirely. The oracle problem remains an open challenge in blockchain design.
‍

Types of blockchain oracles

Oracles differ by data direction, scope, and function. Each supports specific smart contract use cases.
‍

Input oracles

• Function: Bring external data onto blockchains.
  ‍
• Example: Chainlink Price Feeds aggregate price data from exchanges for DeFi apps.

Output oracles

• Function: Sends blockchain data or triggers actions in external systems.
  ‍
• Example: Smart contract conditions can trigger payments, alerts, or Internet of Things (IoT) actions like Chainlink Automation. 

Cross-chain oracles

• Function: Enable data flow between different blockchains.
  ‍
• Example: Chainlink CCIP supports secure messaging between Ethereum, Avalanche, and others.

Compute-enabled oracles

• Function: Performs off-chain computation before returning results on-chain, which is useful for heavy or private processing.
  ‍
• Example: Chainlink Functions allow smart contracts to fetch data from an external API or execute computations off-chain and then return verified results on-chain.

Yet, using a single oracle or source introduces risk. To reduce it, developers rely on Decentralized Oracle Networks (DONs).
‍

What are DONs?

DONs distribute data tasks across multiple independent nodes, reducing reliance on a single oracle. These nodes operate in a peer-to-peer network, verifying off-chain data and reaching consensus before delivering it to smart contracts.

For example, Chainlink nodes pull price data from multiple APIs and aggregate it through smart contracts.

‍Benefits of DONs:

• Data redundancy and aggregation: DONs collect data from many nodes, filtering suspicious values and applying reputation-based weighting to sources based on their historical accuracy and reliability, resulting in more trusted, accurate results. 
   
• Reduced single points of failure: DONs minimize the risk that a single faulty node or malicious actor can compromise the system.
  ‍
• Incentives for accuracy: Node operators stake tokens as collateral, which are slashed for submitting false data, incentivizing honesty.
  ‍
• Reputation tracking: Nodes with higher accuracy and reliability build better reputations, increasing their probability of being selected for future jobs and earning fees.

Note: DONs are not perfectly trustless. While they distribute trust, they still rely on honest majority assumptions and incentives.
‍

Examples of DONs:

• Chainlink: price feeds, randomness, automation, and cross-chain messaging
  ‍
• Pyth: high-frequency data from first-party contributors
  ‍
• DIA: open-source price feeds
  ‍

Use cases of blockchain oracles

‍

‍

Security considerations and risks

While oracles empower smart contracts, they also expand the attack surface. Misconfigured oracles and/or reliance on centralized feeds have led to security incidents.  
‍

Real-world examples

‍Manipulation attacks: In 2020, the bZx hacks exploited a centralized price feed using flash loans, draining around $1 million USD in two attacks.

• Vulnerability: Dependence on a single, manipulable source of price data.
  ‍
• Mitigation: Use decentralized oracles (e.g., Chainlink) that aggregate data from multiple sources.

‍
‍Bad data sources: In 2019, a South Korean exchange fed incorrect prices to Synthetix, briefly allowing an attacker to trade in and out of sKRW (a synthetic stablecoin pegged to Korean Won), netting about $1 billion USD. Luckily, the bot owner reversed the trades in exchange for a bug bounty.

• Vulnerability: Blind reliance on third-party APIs.
  ‍
• Mitigation: Use multi-source aggregation, outlier filtering, and reputation scoring.
  ‍

Centralized price feed failure: In late 2020, Compound relied on the Coinbase oracle for DAI (a decentralized stablecoin soft pegged to USD, backed by cryptocurrency) prices. When Coinbase briefly reported DAI at $1.30, it triggered millions in liquidations despite no such price movement elsewhere.

• Vulnerability: Reliance on a single exchange exposed the protocol to isolated price anomalies.
  ‍
• Mitigation: Use decentralized oracles that aggregate from multiple high-liquidity sources.
  ‍

Additional oracle security risks

• Sybil attacks: Attackers control multiple oracle nodes to manipulate data. Mitigations include staking, reputation scoring, and node diversity to prevent majority control.
  ‍
• Data timestamping issues: Oracles may deliver outdated data due to latency or congestion. Fast updates, TWAPs, and freshness checks help prevent stale inputs.
  ‍
• Oracle front-running: When updates are delayed or predictable, attackers can execute trades before oracle data is processed on-chain. Mitigations include lowering latency, commit-reveal schemes, and anti-front-running protections.
  ‍

Emerging trends in oracle security

New technologies are advancing oracle design to offer stronger guarantees and reduce reliance on trust. Some systems are experimenting with and leveraging: 

• Zero-knowledge proofs (ZKPs): Oracles can use ZKPs to cryptographically prove data correctness without revealing the underlying data or requiring trust in the node.
  
  
• Trusted Execution Environments (TEEs): Secure hardware enclaves like Intel SGX allow oracle computations in isolated environments. This protects sensitive data and logic.