Oracles: The Eyes of DeFi, and also its Achilles' heel

By Zhang Qianwen

In November 2020, one person used borrowed money to pull nearly $1 million out of a DeFi protocol within 15 seconds.

First, he borrowed a large amount of ETH through a flash loan, then concentrated buys of sETH in a liquidity-thin pool, driving the price sharply higher in just a few seconds.

Next, he deposited these sETH as collateral into the bZx protocol. What the protocol “saw” was the price that had just been artificially pumped at that moment; it concluded that these sETH were extremely valuable, and therefore, according to the rules, it released WBTC loans far exceeding their true value.

After the attacker received the WBTC, he quickly repaid the flash loan, took the massive price difference, and walked away.

Throughout the entire process, there was no hacking, no code vulnerabilities, and no abuse of permissions. The contract strictly followed the rules to execute every step. The only problem was:

The world it “saw” was wrong.

This is one of DeFi’s most fundamental limitations—the fact that on-chain smart contracts are, in essence, a system that cannot see the real world.

01 On-chain smart contracts are “blind”

Smart contracts live in a closed world.

They can see everything happening on-chain—who transferred how much money to where, how many tokens an address holds, when and which transaction gets packed into a block—and these pieces of information they can read, and they are absolutely accurate.

But the world off-chain is completely invisible to them: what ETH’s price is today; whether Bitcoin has reached a new high; whether a certain stablecoin has lost its peg; whether the New York stock market is up or down today— the contract knows nothing.

In DeFi lending, this is a fatal contradiction.

Liquidations depend on the current price of the collateral assets; but the contract can’t see the price itself, so someone has to tell it.

That’s why oracles exist: they are the eyes of on-chain smart contracts, responsible for bringing real-world information onto the blockchain so that contracts can read and use it. But then the following problem arises:

Who guarantees that this information is real?

02 Oracles: messengers of the on-chain world

An oracle is, at its core, an infrastructure for transmitting information that writes real-world data (prices, interest rates, event results, etc.) into the blockchain in a contract-readable format.

The concept sounds simple, but the engineering challenge is that the core design principle of blockchains is “never trust any external input”—everything is based on on-chain data that can be verified. And what oracles introduce is precisely off-chain data, which naturally sits outside the boundaries of this trust model.

To solve this issue, two main approaches have emerged in the market.

The first is on-chain prices, which directly read trading prices from decentralized exchanges (DEXs). The most typical example is Uniswap’s Time-Weighted Average Price (TWAP)—it doesn’t use the instantaneous price at a single moment; instead, it uses the average price over a period in the past, diluting short-term price fluctuations over time.

The second approach is decentralized oracle networks, represented by Chainlink. Multiple independent data nodes obtain prices from different sources, aggregate them, and put the median on-chain—no single node can determine the final result on its own.

Both approaches have trade-offs, but they are all trying to answer the same question: how can on-chain smart contracts trust a numeric value coming from off-chain?

03 Why not just use real-time prices?

Most people, when they first encounter oracles, have an intuition: since prices come from the market, why not just read the exchanges’ real-time prices directly?

The problem is that real-time prices are not the same as real prices.

In markets with deep liquidity and active trading, they are usually fairly close; but in pools with weaker liquidity and insufficient depth, with enough capital, the price can be artificially pushed to far above true market levels in an extremely short time.

And smart contracts can’t determine whether this price was naturally formed or deliberately manipulated. They can only read that number and execute the rules accordingly—allowing borrowers to borrow more funds. When the price falls back, the collateral’s real value is fundamentally not enough to cover the loan, and the protocol ends up with bad debt.

This is exactly the reason the bZx protocol attack described at the beginning of the article happened—and it’s also the cost of using real-time prices: oracles treat “numbers that can be briefly manipulated” as if they were reality itself.

04 Chainlink’s solution: decentralize the price

If a system depends on only a single data source, then once that source is wrong or manipulated, the entire protocol will be thrown off course. The most direct way to reduce this risk is not to trust a stronger person, but to have multiple independent nodes report numbers separately, then extract a relatively robust result from them.

Chainlink’s solution follows exactly this idea: multiple independent data nodes obtain prices from different data sources, each reports individually, and the system takes the median as the final result. This way, even if a single node makes a mistake, or is influenced by an attacker, it can’t swing the final price. And for an attacker to control more than half of the nodes simultaneously is, economically, almost impossible.

This mechanism effectively mitigates the risk of single-point manipulation.

But it also introduces a new cost: delayed updates.

On-chain prices are not synchronized in real time; nodes collect data, reach consensus, and write it to the blockchain—this takes time. When the market is moving normally, this delay doesn’t matter. But during periods of dramatic volatility, oracle prices may not keep up with real price changes.

This is why, in why DeFi lending must overcollateralize, it says that DeFi lending protocols need to set an overcollateralization buffer: not only to withstand price volatility itself, but also to ensure that during the period before the oracle has had time to update, the system still has enough safety margin to trigger liquidations.

05 Oracle attacks: the most expensive trust crisis

Oracle problems don’t disappear completely with Chainlink’s emergence.

In DeFi history, oracle-related vulnerabilities are among the attack categories that caused the worst losses. Between 2021 and 2023, for only the oracle manipulation attacks that have been documented, the total losses already exceeded hundreds of millions of dollars.

These losses share a common characteristic: the attackers don’t need to find vulnerabilities in the code. They only need to find the gap between the oracle price and the true market price, then use capital to widen that gap so that the contract executes an operation in their favor according to the distorted price. This is a risk that’s harder to defend than code vulnerabilities—because you can’t write a rule in the code that says “whether this price is real.”

At its core, the oracle problem isn’t a vulnerability in a particular component; it’s a trade-off:

If you use more data sources to fight manipulation, you must accept higher latency;

If you seek prices closer to real time, you must take on the risk of being briefly manipulated.

There is no perfect solution to this trade-off.

And that’s also why the existence of oracles reveals a deeper reality about DeFi: on-chain smart contracts can achieve absolute transparency and absolute execution, but the prerequisite is always that the input information they rely on is real. Once the input is distorted, even perfect code will only more efficiently make wrong judgments and execute accordingly.