A contract that liquidates a position needs to know a price, and the chain it runs on has no way of finding one. Everything that has gone wrong in this part of the stack follows from that single limitation, and understanding it explains a category of losses that otherwise look like the market behaving impossibly.
A blockchain is deterministic by design: every participant running the software must arrive at exactly the same result from the same inputs, or consensus fails. That requirement rules out asking the outside world anything, because two participants querying an external source at slightly different moments would get different answers and disagree about the state of the ledger.
So a contract that needs to know what an asset is worth cannot look it up. The information has to be placed on the chain by somebody, in a transaction, becoming part of the ledger like any other data. From that moment the contract can read it deterministically, and everybody agrees, because they are all reading the same recorded number rather than each asking the world separately.
That is the whole of what an oracle is: a mechanism for writing external information onto a chain so that contracts can act on it. It is not a magic window onto reality. It is somebody typing a number in, with rules about who is allowed to type and what happens if they type the wrong one.
Contracts do not read the market. They read a number somebody wrote down, and every question about oracle risk is a question about who wrote it and how.
The differences reduce to the same question that governs bridges: how many parties would have to be wrong or dishonest at once for the recorded number to be false.
One party observes prices and writes them. It is cheap, fast, and its accuracy is exactly the accuracy of that party. This design still exists in production and it concentrates the entire integrity of everything downstream into one entity's key management and one entity's data feed.
Many independent parties each report, and the contract takes a median or a similar robust statistic. A single wrong or malicious reporter is discarded by the aggregation, which is a genuine improvement, and the design's weakness moves to whether the reporters are actually independent. Publishers that all read from the same handful of sources are one publisher wearing several coats, and the aggregation cannot detect that.
Rather than importing an external price, some systems compute one from trading that happened on the chain itself, which is visible and needs no reporter at all. This removes the human entirely and replaces the problem with a different one: the price now reflects a specific market rather than the market, and that market can be small enough to move.
Even a well-built oracle reports something slightly different from what you would see on a screen, and the gaps are structural rather than errors. It updates at intervals rather than continuously, so between updates the recorded price is stale by construction. It aggregates across sources, so it is a summary of several markets rather than the price on any one of them. And it usually applies smoothing, so a genuine sharp move arrives attenuated.
Each of those choices is defensible and each has a cost. Frequent updates cost transaction fees on every one, so the interval is an economic decision rather than a technical limit. Aggregation protects against one bad source and guarantees that the number never exactly matches the venue you are watching. Smoothing prevents manipulation through brief spikes and, by exactly the same mechanism, delays the recognition of real ones.
The practical consequence is that any position whose fate depends on an oracle is exposed to the oracle's configuration as well as to the market. Two identical positions on two platforms can survive and be liquidated on the same day, not because the market disagreed with itself but because the two oracles were configured differently.
Grouping the incidents shows a small number of repeated shapes, and none of them required breaking any cryptography.
If an oracle derives its price from a market that is thin relative to the value of the positions depending on it, an attacker can borrow capital, push that market a long way for a few seconds, and profit from contracts that act on the distorted number. The manipulation is expensive and it is bounded by the depth of the market being pushed, which is why oracles that read thin markets are the vulnerable ones.
Between two updates the recorded price is known to be stale, and if the real market has moved substantially in that window, anybody can transact against the contract at the old price. This is not manipulation, it is arbitrage against a known delay, and it has drained substantial value from systems whose update frequency was set for cost rather than for safety.
Where an aggregation has few genuinely independent inputs, disabling or degrading one or two of them can shift the aggregate enough to matter, without any of the remaining reporters doing anything wrong.
The standard defence against brief manipulation is to report an average over a window rather than the latest value. Pushing a price for a few seconds then barely moves a figure averaged over half an hour, and the cost of a manipulation rises with the duration required, which makes the attack uneconomic in most cases.
The cost is symmetrical and it is not always mentioned. An averaged price lags a genuine move by construction, which means the oracle reports that an asset is worth more than it is during a real decline. Positions that should have been liquidated are not, they continue falling, and the system can end up holding collateral worth less than the debt against it. The protection against fake moves is exactly the same mechanism as the delay on real ones.
Which failure a system prefers is a design choice with no correct answer. A short window resists lag and invites manipulation; a long one resists manipulation and invites bad debt during genuine crashes. Both have produced losses, and a system's choice is usually documented, rarely read, and directly relevant to anybody with a leveraged position on it.
Averaging defeats a fake spike and delays a real one, using the same mechanism. There is no setting that tells them apart.
Most production oracles update on two triggers. A heartbeat forces an update after a maximum interval regardless of what happened, guaranteeing the price is never older than that. A deviation threshold forces an early update when the price has moved more than a set amount since the last one, so that fast markets get more frequent updates than quiet ones.
Both parameters are public and both are worth knowing for any platform where you hold leverage. A long heartbeat with a wide deviation threshold means the recorded price can sit unchanged through a substantial move, and any liquidation logic reading it will act late. A short heartbeat costs more in fees and is usually reserved for the assets carrying the most value.
This is also why the same asset can have different oracle behaviour on different platforms even when the underlying feed is the same. The feed publishes; the platform chooses how it consumes, and that choice determines what your position experiences during the minutes that matter.
The most common confused complaint in leveraged trading is that a position was closed at a level the chart never reached. The chart shows one venue; the oracle reports a different number derived from several, possibly averaged, possibly stale, and the liquidation engine acts on the oracle rather than on the chart you were watching.
There is a second and less obvious contributor. Many platforms deliberately use a smoothed or index price for liquidations rather than the last trade on their own book, specifically so that a brief spike on their own venue cannot trigger a wave of closures. That is a protective choice and it produces the same experience: your position responded to a number you had no display of.
The remedy is not to argue with it but to watch the right number. Any platform offering leverage publishes which price its liquidation engine uses, and frequently displays it alongside the last trade. Traders who set their risk against the traded price while the engine reads a different one are managing a distance that is not the distance being measured.
Four things, all documented and none requiring technical skill. Which price the liquidation engine reads, and whether it is displayed anywhere you can see it. How that price is constructed, meaning how many sources and whether it is averaged over a window. How often it updates, through the heartbeat and the deviation threshold. And on the assets you actually trade, how deep the markets feeding it are, since an oracle reading thin markets is the one exposed to manipulation.
None of this prevents anything on its own, and it converts an entire category of surprise into a known parameter. A trader who knows their platform liquidates on a thirty-minute average understands in advance why a fast recovery will not save a position, and can size accordingly. A trader who does not know will experience the same event as the market behaving impossibly.
Because a blockchain must be deterministic: every participant has to reach the same result from the same inputs. Two participants querying an external source at slightly different moments would get different answers and disagree about the ledger. So external data has to be written onto the chain first, in a transaction, before any contract can read it.
A mechanism for writing outside information onto a chain so contracts can act on it deterministically. It is not a window onto reality; it is a rule about who may publish a number and what happens if they publish a wrong one. Every question about oracle risk reduces to those two things.
Because the liquidation engine reads the oracle, not the chart. That price is usually aggregated across several venues, frequently averaged over a window, and updated at intervals. Many platforms use a smoothed index deliberately, so that a brief spike on their own book cannot trigger a wave of closures.
An average over a window rather than the latest value. It makes brief manipulation uneconomic, because pushing a price for seconds barely moves a half-hour average. The cost is that it lags genuine moves by exactly the same mechanism, which can leave positions unliquidated during a real decline.
Usually by moving the market it reads. If the price is derived from a venue that is thin relative to the positions depending on it, an attacker can borrow capital, push that venue briefly, and profit from contracts acting on the distorted number. The attack is bounded by the depth of the market being pushed.
The two triggers that cause an update. The heartbeat forces one after a maximum interval regardless of movement, so the price is never older than that. The deviation threshold forces an early one when the price has moved more than a set amount. Both are public and both determine how late a liquidation engine can act.
Not necessarily, and even where the underlying feed is shared, each platform chooses how to consume it. Two identical positions on two platforms can therefore behave differently on the same day, because the configuration rather than the market decided the outcome.
Which price the liquidation engine reads and whether it is displayed, how that price is built and whether it is averaged, how often it updates, and how deep the markets feeding it are. All four are documented, and knowing them converts a category of surprise into a parameter you can size against.