Price Oracles and the Oracle Problem
A smart contract can see everything on its own chain and nothing outside it. It cannot look up the price of Bitcoin, or of anything else, because that number does not exist on-chain.
Yet almost every DeFi protocol needs one. A lending market must know when a loan is under-collateralised. A perpetual must know the index price to settle funding against. A liquidation engine must know when to fire. All of them depend on something external telling the contract what the price is, and that something is an oracle.
The oracle problem
The difficulty is not technical, it is structural. You have built a trust-minimised system and then handed one input to a party you must trust.
A protocol is only as sound as its price feed. Perfect contract code fed a wrong price produces perfectly executed wrong liquidations, and most large DeFi losses are this failure rather than a bug in the lending logic itself.
The three designs
Single source. One provider signs a price and posts it. Cheap, fast, and a single point of failure that also has to be honest. Rare now outside small protocols.
Median of many. Independent node operators each report, and the contract takes the median. Corrupting the feed means corrupting a majority of reporters simultaneously, which is the design most major protocols settled on. The residual weakness is correlation: if every reporter reads the same two exchanges, the feed inherits whatever happens on those two exchanges.
On-chain time-weighted average. Rather than importing a price, read one from an on-chain AMM pool and average it over a window. Nothing external is trusted at all. The cost is lag, and lag is its own exposure.
Why manipulation is the central risk
An oracle reading spot from a venue with thin liquidity can be moved by trading on that venue. In crypto this is unusually cheap, because a flash loan lets an attacker borrow an enormous amount with no collateral provided everything is repaid inside a single transaction.
The pattern is consistent across the incidents: borrow, push the pool price hard in one direction, let the protocol read the distorted number, extract value against it by borrowing against inflated collateral or triggering liquidations, then unwind and repay. The whole sequence is atomic, so it either completes profitably or reverts as though it never happened.
Time-weighted averaging raises the cost, since an attacker must now hold the price away from fair value for the whole window rather than for one block. It does not remove the risk, and it introduces a different one: during a genuine fast move, a lagging oracle reports a price the market has already left.
When evaluating any DeFi protocol, find the oracle before reading anything else. Ask what it reads, how many independent sources feed it, and what a manipulation of the thinnest of those sources would cost. That number is an upper bound on the protocol's security.
What this means for a trader
You are trading the oracle, not the market. Liquidations, funding and settlement fire off the oracle price. If the oracle updates on a deviation threshold or a heartbeat rather than continuously, there are stretches where the protocol's price and the market's price genuinely differ, and positions are marked against the former.
Lag is an arbitrage. A feed that updates only when spot moves by some threshold is stale between updates. Trading against a stale on-chain price using a live off-exchange one is the on-chain version of latency arbitrage, and the reason it persists is that closing it requires paying network fees.
Oracle risk is correlated with everything else. Feeds are most likely to be stale, disputed or manipulated during volatile periods, which is exactly when liquidations are firing and your positions most need accurate marks.