Oracle risk: how a bad price feed turns into real losses

Why DeFi needs oracles

A blockchain only knows what is recorded on it. A lending protocol that accepts a token as collateral needs a price for that token to decide how much can be borrowed and when a loan becomes unsafe. The component that supplies that price is called an oracle.

Every number a lending market shows you, from your borrowing limit to your health factor, is calculated from oracle prices. If the oracle is wrong, those numbers are wrong too, and the contract will act on them anyway.

Three common kinds of price feed

Oracles differ in where they read prices and how quickly they react. Each design trades speed against resistance to manipulation.

Many protocols combine designs, for example using an aggregated feed with a fallback, or rejecting prices that move too far from a reference. The walkthrough below uses the simplest and most fragile design to show why those safeguards exist.

Step 1: Find a thin market the oracle trusts

The attack starts with a mismatch. A lending protocol accepts a small-cap token as collateral and prices it from the spot rate in a single pool. That pool is shallow, so a large trade moves its price a long way.

In this illustration, the token trades at $100 in the wider market, and the lending protocol allows borrowing up to a 75% loan-to-value ratio against it.

Step 2: Borrow size for a few seconds

Moving a pool's price takes capital. A flash loan supplies it: a loan that must be borrowed and repaid within a single transaction, with no collateral, because the whole transaction is cancelled if repayment fails. The flash loan calculator shows the fees involved in legitimate uses.

Flash loans are not the flaw. They simply mean that the size of an attack is not limited by how much money the attacker owns, only by how much is available to borrow for a moment.

Step 3: Push the price and let the oracle read it

Inside the same transaction, the attacker buys the token in the shallow pool until its spot price reads $150. The lending protocol's oracle reads that price. The attacker deposits 1,000 tokens as collateral, which the protocol now values at 1,000 × $150 = $150,000.

At a 75% loan-to-value limit, the protocol allows a loan of $150,000 × 75% = $112,500 in stablecoins. At the true price of $100, the same collateral would support only $100,000 × 75% = $75,000. The difference, $37,500, is the over-lending created by one distorted reading, before the attacker's trading costs.

Step 4: Exit before the price snaps back

The attacker sells back into the pool, repays the flash loan and walks away with the borrowed stablecoins. The pool price returns toward $100. The protocol is left holding collateral worth about $100,000 against a loan of $112,500 that nobody intends to repay.

That $12,500 shortfall is bad debt. Depending on the protocol's rules, it may be absorbed by a reserve fund, by holders of a governance token, or by the people who supplied stablecoins to the lending market. In other words, depositors who never borrowed anything can bear the loss.

How a time-weighted average changes the arithmetic

Now suppose the protocol uses a 30-minute TWAP built from 30 one-minute observations. The attacker can hold the pool price at $150 for, say, 3 minutes before arbitrage traders and costs make it impractical. The average becomes (27 × $100 + 3 × $150) ÷ 30 = $105.

At $105, the 1,000 tokens support a loan of $105,000 × 75% = $78,750, only $3,750 more than at the true price, and the attacker had to fund the distortion across several blocks rather than within one transaction. Pushing the average all the way to $150 would mean holding the price there for the whole window.

Honest failures: stale, frozen and mis-scaled feeds

Not every oracle failure is an attack. A feed can stop updating during network congestion and report a stale price. An update can be published with the wrong number of decimal places. A protocol can hard-code a stablecoin at exactly $1, so it keeps valuing that coin at par after it has lost its peg, which is one reason stablecoin depeg risk and oracle risk often appear together.

Safeguards against honest failures include maximum-age checks that reject old prices, circuit breakers that pause markets after extreme moves, and comparisons against a second source. Each safeguard also creates a new question: who can trigger or lift the pause, and how quickly?

What this means for an ordinary depositor

If you supply assets to a lending market, the quality of its oracles affects you even if you never borrow. Your deposit is the money an attacker would borrow, and your share of any bad debt depends on how the protocol handles shortfalls.

Canadian securities regulators caution that crypto assets are risky and that you could lose some or all of your funds, and the Ontario Securities Commission's investor site lists hacks and the difficulty of recovering transferred crypto among the risks. Oracle design is one concrete place where those general warnings turn into specific, checkable details.

Questions to ask before you deposit

• Where does the protocol get the price for each collateral asset: one pool, an average, or an aggregated feed?
• How deep is the market behind each price, compared with the borrowing limits allowed?
• Does the protocol reject prices that are stale or move too far, too fast?
• Is any stablecoin priced at a fixed $1 rather than at its market price?
• Who can pause markets or change oracle settings, and is there a delay before changes apply?
• How is bad debt handled, and could suppliers share in a shortfall?