What Is a Blockchain Oracle?
A blockchain oracle feeds outside data, like prices or results, into smart contracts. Learn how oracles work, the oracle problem and how they fail.
A blockchain oracle is a service that feeds information from outside the blockchain, such as an asset price, a sports result or the weather, into smart contracts. Blockchains cannot fetch outside data on their own, so any application that depends on real-world facts needs an oracle. Whoever controls that data feed has real influence over the contracts that use it.
Why blockchains need oracles
Every node on a blockchain has to reach the same result when it processes the same transaction. If a smart contract called a website for the price of ETH, different nodes might get different answers at slightly different times, and consensus would break. So smart contracts can only read data that is already on the chain.
Oracles solve that by putting outside data on-chain in a transaction, where every node sees exactly the same value. Our guide to Web3 shows how oracles fit alongside wallets, tokens and bridges.
What oracles are used for
- Lending and borrowing. Protocols need asset prices to decide when a loan is undercollateralized and should be liquidated.
- Derivatives and stablecoins. Synthetic assets and crypto-backed stablecoins need prices to stay on target.
- Prediction markets. A contract that pays out on an event, such as an election result, needs an oracle to report the outcome.
- Insurance. A crop insurance contract might pay out when oracles report that a certain weather event occurred.
- Cross-chain messages. Some bridges use oracle networks to confirm what happened on another chain. Our guide to cross-chain bridges explains why that confirmation step is so sensitive.
How oracles work
Oracles differ in a few key ways:
Figure: A typical decentralized price oracle. Wrong or stale data at the start flows straight into the contract.
| Choice | Options |
|---|---|
| Data sources | One source, or many sources aggregated |
| Trust model | A single centralized operator, or a decentralized network of independent node operators |
| Delivery | Data pushed on a schedule, or delivered on request |
| Direction | Bringing data on-chain, sending data off-chain, or performing computation off-chain |
A common design for price feeds uses many independent operators, each pulling prices from multiple sources. Their reports are combined, often by taking a median, and the result is posted on-chain when the price moves beyond a threshold or after a set time.
Oracles beyond prices
Price feeds are the best-known use, but oracles deliver other kinds of information too. Games and NFT launches need random numbers that no participant can predict or manipulate, so some oracle networks supply randomness along with a proof that it was generated fairly. Issuers of wrapped tokens and stablecoins use oracles to publish proof of reserves, regularly reporting the assets held in custody so that anyone can compare them with the tokens in circulation. And some oracle networks carry messages between blockchains, which puts them in the same high-stakes position as bridges.
The oracle problem
Smart contracts are often described as “trustless,” but a contract that relies on an oracle is only as trustworthy as that oracle. If the data is wrong, the contract will execute the wrong outcome perfectly. This is known as the oracle problem.
Decentralizing the oracle reduces the risk of a single operator lying or failing, but it cannot fully remove it. Someone still has to choose the sources, and those sources can be wrong too.
A bad price in action
Suppose you deposit 5 ETH into a lending protocol when ETH trades at $2,000, giving $10,000 of collateral, and borrow $6,000 of stablecoins. The protocol liquidates any loan once it exceeds 80% of the collateral’s value, which in this case happens if ETH falls to $1,500. (Illustrative figures.)
Now suppose the protocol’s oracle reads its price from a single, thinly traded market. An attacker briefly pushes the price there down to $1,450 with a few large sales. The oracle reports $1,450, the protocol treats your loan as unsafe and liquidates it, even though ETH is still trading near $2,000 everywhere else. You lose your collateral to the liquidation, and the attacker may profit by buying it at a discount. Nothing in the smart contract malfunctioned; it acted perfectly on bad data.
How oracles fail
Manipulated sources. If an oracle reads its price from a thin market, an attacker can push that market’s price for a few moments, trigger liquidations or borrow against inflated collateral, and walk away with the difference.
Stale or slow data. In fast markets, prices can move faster than oracles update. On Black Thursday in March 2020, analysts at Glassnode noted that slow oracle updates contributed to a wave of liquidations in the MakerDAO system as ETH crashed. Our article on Black Thursday tells that story.
Operator failures. A centralized oracle can go offline, be hacked or be pressured into posting false data.
Network congestion. If the blockchain is congested, oracle updates may be delayed just when they are needed most.
Push, pull and other design choices
Push oracles post new prices on-chain on a schedule, or whenever the price moves by more than a set percentage. Applications simply read the latest value. The cost is that every update is a transaction someone must pay for, and between updates the on-chain price can lag the market.
Pull oracles keep signed prices off-chain and let users include the latest one in their own transaction when they need it. Data can be fresher and cheaper, but the application must verify that the price is recent and genuine.
Time-weighted averages use the average price over a period, often from on-chain trading pools, rather than the latest trade. They are much harder to manipulate with a single burst of trading, but they react slowly, which can be a problem in a fast crash. Many protocols combine sources, add circuit breakers that pause activity when prices jump, or set limits on how far a price can move between updates.
What to look for as a user
If you use a decentralized application that depends on prices, it is worth knowing:
- which oracle it uses, and whether it is a single source or a network
- how often prices update and what triggers an update
- whether there are safeguards, such as circuit breakers or delays, when prices move sharply
- whether the protocol has had oracle-related incidents before, and how losses were handled
These details are usually in a protocol’s documentation or audit reports. If you cannot find them, treat that as a risk in itself, especially before borrowing against volatile collateral.
Most users never interact with an oracle directly, but oracles sit underneath much of decentralized finance. Our comparison of centralized vs decentralized exchanges shows where these risks appear in practice.
This article is educational content and does not constitute financial, investment, legal or tax advice. Digital assets are volatile and you may lose the amount you invest.