Smart contracts cannot access external data on their own. They can only read data that exists on their own blockchain. This is a fundamental design constraint, not a bug. If smart contracts could reach out to arbitrary APIs, their execution would be non-deterministic, since different nodes might get different responses, which would break consensus.
Oracles solve this by bringing external data on-chain in a way that the network can agree on. For DeFi, the most critical external data is asset prices. When a lending protocol needs to know if a position is undercollateralized, it queries an oracle for the current price. When a perpetual futures platform calculates funding rates, it uses oracle prices. Oracles are the foundation that most of DeFi financial logic sits on.
Chainlink is the dominant oracle network, securing tens of billions of dollars across hundreds of protocols. Its architecture uses a decentralized network of node operators who independently fetch prices from multiple data sources, then aggregate them on-chain. The aggregation typically uses a median, which is resistant to any single data source being manipulated. Nodes are incentivized through LINK token payments and penalized for providing inaccurate data.
Pyth Network takes a different approach, particularly for high-frequency price feeds. Instead of having oracle nodes scrape public APIs, Pyth receives price data directly from first-party sources like exchanges, market makers, and trading firms. This reduces the data supply chain and can provide faster updates. Pyth pull oracle model also means consumers request prices when they need them rather than having prices pushed on-chain at fixed intervals.
The update frequency of oracle prices is a critical design parameter. Chainlink standard price feeds update based on either a deviation threshold (typically 0.5-1%) or a heartbeat interval (usually 1 hour). This means that during periods of rapid price movement, the on-chain price can lag the true market price. This lag creates opportunities for MEV extraction and can cause liquidations to occur at stale prices.
Oracle manipulation attacks have caused hundreds of millions in losses. The basic attack pattern involves manipulating the price sources that an oracle reads from, then using the manipulated on-chain price to extract value from a protocol. Flash loan attacks often use this approach: borrow a large amount, manipulate a thinly traded market to move the oracle price, exploit the manipulated price in a lending protocol, then repay the loan, all in a single transaction.
TWAP (time-weighted average price) oracles, like those built into Uniswap V3, offer manipulation resistance by averaging prices over time. Manipulating a TWAP requires sustaining a distorted price for the entire averaging period, which is expensive. The tradeoff is that TWAP prices are inherently lagged, making them unsuitable for applications that need real-time pricing.
The oracle trilemma suggests that oracle designs must trade off among three properties: freshness (how current the data is), cost (how expensive it is to maintain), and security (how resistant it is to manipulation). Push oracles with frequent updates are fresh but expensive. TWAP oracles are secure but lagged. Pull oracles can be fresh and cheaper but require more trust in the data providers.
For traders and DeFi users, oracle design has direct practical implications. If you are using a lending protocol, understanding its oracle update mechanism tells you about liquidation risk during volatile periods. If you are trading perpetual futures, the oracle freshness affects how closely the contract price tracks spot. Checking what oracle a protocol uses, and how it is configured, is a basic due diligence step that most users skip.