An oracle is the bridge between a blockchain and the outside world. Smart contracts can only read data that is already on-chain; they cannot directly call a web API or pull a stock price from an external server. If you want to build a DeFi protocol that pays out based on the price of ETH/USD, or a prediction market that settles based on an election result, or an insurance contract that triggers when a flight is delayed, you need some mechanism to get that external data onto the chain in a format the contract can consume. An oracle is whatever system does that job.
The challenge is that oracles are inherently a trust problem. The data a smart contract reads from an oracle is only as reliable as the oracle providing it, and if the oracle is wrong — whether through error or manipulation — the contracts depending on it will behave incorrectly. Every serious incident involving an oracle in DeFi has traced back to either a genuine data-feed failure or an intentional manipulation of the oracle’s inputs. Designing an oracle that is hard to corrupt and hard to take offline is a serious engineering problem, and most of the oracle ecosystem is various attempts at solving it.
Chainlink and the Decentralised Oracle Model
Chainlink is the dominant oracle provider in DeFi. Its model is to run a network of independent node operators who each fetch data from multiple sources, aggregate their responses, and publish a single median (or similarly aggregated) value on-chain. For widely-used price feeds like ETH/USD or BTC/USD, Chainlink typically uses 20-30 independent nodes pulling from a dozen or more exchanges and data providers, and updates the on-chain price whenever it deviates by a configured threshold or after a configured time interval. The security argument is that corrupting the feed requires corrupting a majority of those independent nodes simultaneously, which is much harder than corrupting any single data source.
Chainlink has been used as the price oracle for most of the major DeFi protocols — Aave, Synthetix, dYdX, GMX, Venus — and its data feeds have secured tens of billions in TVL across the ecosystem. There have been some incidents where downstream protocols blamed Chainlink for bad outcomes, but most of those turned out to be cases where a protocol was using a Chainlink feed in a way Chainlink had not designed it to be used, or where the underlying market data itself was wrong due to a real market dislocation rather than an oracle bug.
Competitors include Pyth Network (which uses a different model — data providers push prices directly to the chain with signatures from first-party sources like exchanges and market makers), API3 (which focuses on first-party oracles where the data provider runs their own node), RedStone, and UMA. Each has its own tradeoffs, and some protocols use multiple oracles as a check against any single one being compromised.
The On-Chain Price Manipulation Attack
Before good decentralised price oracles existed, a common pattern was for DeFi protocols to read prices directly from DEXes — for example, pulling the spot price from a Uniswap V2 pool. This turned out to be a catastrophically bad idea, because the spot price of a small pool could be manipulated trivially by anyone with enough capital. An attacker could take a flash loan, use it to push the pool’s price to whatever they wanted, exploit a downstream protocol that trusted the manipulated price, and repay the flash loan — all in a single transaction, risk-free.
This attack pattern hit multiple protocols between 2020 and 2022. bZx, Harvest Finance, Cheese Bank, and several others lost funds to variations of the same trick, collectively totaling hundreds of millions of dollars. The solution is to use a time-weighted average price (TWAP) from a DEX or, better, to use an independent oracle like Chainlink that is not directly manipulable by anyone trading on a particular venue. The lesson — “do not use spot prices from shallow pools as your oracle input” — is now standard, but it took a string of expensive exploits for the industry to internalise it.
Non-Price Oracle Use Cases
Oracles are not only for prices. Any off-chain data a contract needs is an oracle problem. Sports betting protocols use oracles to settle based on game results. Insurance protocols use oracles to verify that covered events (hurricane damage, flight delays) happened. Real-world asset platforms use oracles to attest to off-chain collateral positions and audit reports. Cross-chain bridges, in a sense, use each other’s state as oracles — a message from chain A arrives on chain B via an oracle that has verified the original event.
Non-price oracles are generally less mature than price oracles and most of them have less battle-tested security models. The “bring real-world data on-chain” problem is still an active area of development, and the more exotic the data source, the more you should assume that the oracle is a potential weak link in whatever contract is depending on it.