Blockchain Oracle

A blockchain oracle is a service that brings information from outside a blockchain onto it, so that a smart contract can use that information. Blockchains can only check data that already lives on their own ledger: balances, signatures and transactions. They cannot see an exchange rate, a sports result, a shipment's arrival or a bank transfer. Oracles fetch such facts, sign them and post them on-chain, where contracts read them to decide whether to lend, liquidate, pay out or release funds.

Oracles are a core part of decentralized finance (DeFi), where lending and derivatives protocols depend on price feeds, and of any design that links on-chain money to off-chain events. The best-known provider is the network behind Chainlink (LINK). The difficulty of trusting outside data, known as the oracle problem, is one reason no blockchain application that touches the real world is a fully trustless system.

Picture a vending machine that only accepts tokens and cannot read a newspaper. If you want it to hand out a prize when it rains tomorrow, someone has to come along and press a button marked "it rained". The machine will believe whoever presses the button.

A blockchain oracle is that button-presser. The contract is honest and exact, but it is only as good as the information it receives. Good oracle designs make sure the button can only be pressed by several independent reporters who have to agree, and who lose money if they lie.

1. A contract needs a value, such as the ETH/USD price or confirmation that a payment arrived.
2. One or more oracle nodes collect that value from data sources such as exchanges, data vendors or an application programming interface (API).
3. The nodes sign their reports with a private key, and the network combines them, for example by taking a median.
4. The result is written to the chain, where any contract can read it, either on a schedule, when the price moves by a set amount, or when a contract requests it.

Oracles can also work in the other direction, sending on-chain events out to banks, payment systems or other networks; these are sometimes called outbound oracles.

• Centralized oracles. A single company or server reports the data. Simple and cheap, but a single point of failure.
• Decentralized oracle networks. Many independent node operators report and their answers are aggregated, often backed by staking and reputation.
• Price feeds. Continuous market prices used by lending protocols, stablecoins and derivatives; some use time-weighted averages to blunt short spikes.
• Attestation and reserve feeds. Data confirming that off-chain assets exist, used for proof of reserves (PoR) and tokenized assets.
• Human or evidence-based oracles. People or appointed adjudicators who confirm events code cannot check, such as whether a bank transfer was received, linking oracles to arbitration and dispute resolution.

Lending protocols rely on oracles to know when a position falls below its required level of overcollateralization and should face forced liquidation. Crypto-backed stablecoins use them to value their collateral. In trade finance, an oracle can confirm a proof of delivery before a stablecoin escrow pays a seller. In proposals for bilateral collateral escrow, an oracle or adjudicator must confirm that two off-chain bank transfers happened before stablecoin collateral is released. Cross-chain messaging between networks, including the crypto bridge, uses oracle-like relayers.

• Manipulation. If a contract reads the price from one thin market, an attacker can move that price briefly, often with a flash loan, and borrow against inflated collateral. The bZx attacks of February 2020 and the October 2022 Mango Markets exploit, in which more than 100 million dollars was drained after a token price was pushed up, were both widely analysed as oracle manipulation; see market manipulation.
• Stale or wrong data. Outages, delays or bad source data can trigger liquidations that should not happen.
• Concentration. A protocol that depends on one oracle network, or on a feed controlled by an admin key, inherits that network's failures.
• Real-world limits. Some facts, such as whether a payment receipt is genuine, cannot be verified by any data feed and still need human judgment.

Oracle security is therefore treated as part of a protocol's overall counterparty risk, and auditors review oracle design as closely as the contract code. Common defences include drawing prices from many exchanges, rejecting values that move too far in one update, pausing a market when feeds disagree, and using several independent oracle networks for the same value.

• Ethereum.org: Oracles
• Chainlink