An oracle brings off-chain information onto a blockchain so smart contracts can act on it. Price feeds are the classic case. Lending markets, perpetual DEXs, stablecoin pegs, and prediction markets need external data that does not live natively on-chain. The oracle is the pipe that delivers that data under some trust and update model.
Why it matters
Bad oracle data breaks good protocols. If a lending market marks collateral from a manipulated tick, it can liquidate healthy positions or fail to liquidate underwater ones. Oracle design is therefore core protocol risk, not a side detail. Sources, aggregation, update frequency, circuit breakers, and fallback logic all matter.
Decentralized oracle networks reduce single-feed failure. They do not remove risk. Latency during volatility, wrong asset mapping, and governance capture still appear. Thin secondary markets used as price inputs are especially dangerous. Desks reading DeFi risk should ask which oracle a market uses and what happens when the feed stalls.
Oracles also power cross-chain messaging and real-world data beyond spot prices. The broader the dependency, the larger the blast radius when the feed is wrong. Treat oracle choice like custody choice: invisible when calm, decisive when stressed.
Simple example
A lending pool prices a thinly traded token from one exchange print. An attacker pushes that print down for a moment. The oracle reports the low print. The protocol treats the collateral as worthless and liquidates borrowers who were solvent on any reasonable average price. The bug was not the loan math. It was the price pipe.
When evaluating a new market, ask how stale a feed can become before trading pauses, and whether a secondary oracle can take over. Those boring parameters often decide whether a volatility spike becomes a solvency event.
Related terms
See smart contract, DeFi, liquidation, bridge, and Chainlink history. Browse more in the crypto glossary.