Black Swan Repeats: Five-Year Cycle of Oracle Vulnerabilities

A $60 million market sell-off led to the evaporation of $19.3 billion in market capitalization.

Written by: YQ

Compiled and translated by: Saoirse, Foresight News

(The original content has been adjusted and abridged)

From October 10 to 11, 2025, a $60 million market sell-off resulted in the evaporation of $19.3 billion in market capitalization. This was not caused by a market crash, nor by a cascade of margin calls triggered by legitimately impaired positions, but rather by an oracle failure.

This is nothing new. Since February 2020, the same attack pattern has been successfully exploited, causing hundreds of millions of dollars in losses to the industry across dozens of incidents. The October 2025 attack was 160 times larger than the previous largest oracle attack—not because the technology was more complex, but because the underlying systems, while scaling up, retained the same fundamental vulnerabilities.

Five years of painful lessons have been ignored. This analysis will explore the reasons why.

2020-2022: The "Fixed Script" of Oracle Attacks

Before dissecting the October 2025 incident, it must be made clear: similar situations have occurred before.

February 2020: bZx Incident (Losses of $350,000 + $630,000)

Using a single-source oracle, attackers manipulated the price of WBTC on Uniswap via flash loans, moving 14.6% of the token’s total supply to manipulate the price feed data that bZx relied on entirely.

October 2020: Harvest Finance Incident ($24 million stolen, triggering a $570 million run)

In just seven minutes, attackers used a $50 million flash loan to manipulate stablecoin prices on Curve, resulting not only in stolen funds but also in infrastructure collapse and liquidity flight, with the impact far exceeding the initial theft amount.

November 2020: Compound Incident ($89 million in assets liquidated)

The DAI stablecoin soared to $1.30 on Coinbase Pro, while other platforms did not experience this. Because Compound’s oracle used Coinbase as its pricing benchmark, users were forcibly liquidated due to this one-hour price anomaly. At the time, it took only $100,000 to manipulate an order book with $300,000 depth.

October 2022: Mango Markets Incident (Losses of $117 million)

Attackers used $5 million in initial capital to pump the price of MNGO tokens by 2,394% across multiple platforms, then borrowed $117 million using the overvalued collateral, and used the stolen governance tokens to vote themselves a $47 million "bug bounty." This was the first time the U.S. Commodity Futures Trading Commission (CFTC) took enforcement action against oracle manipulation.

All attacks followed the same process:

1. Identify the oracle’s reliance on "manipulable data sources";
2. Calculate and verify: cost of manipulation < extractable value;
3. Execute the manipulation;
4. Exit with profits.

Between 2020 and 2022, 41 oracle manipulation attacks resulted in $403.2 million being stolen. The industry’s response was scattered, slow, and incomplete—most platforms still use oracles based primarily on spot prices with insufficient redundancy.

Then, the disaster of October 2025 struck.

Analysis of the "10.11" Vulnerability

At 5:43 a.m. on October 10, 2025, a concentrated $60 million USDe sell-off triggered a fatal chain reaction:

$60 million spot sell-off → Oracle downgrades collateral (wBETH, BNSOL, USDe) valuations → Large-scale forced liquidations → Infrastructure overload → Liquidity vacuum → $19.3 billion in market cap evaporated

This was not the failure of a single platform, but rather the exposure of a long-standing industry-wide vulnerability—even after five years of costly lessons, these vulnerabilities remain unaddressed:

1. Overreliance on Spot Prices

Despite every major attack since 2020 exploiting the "manipulable spot price" vulnerability, most platforms still use spot-centric oracle designs. The industry is well aware of the manipulation risk in spot prices and knows that "time-weighted average price (TWAP)" and "multi-source oracles" offer better protection, yet these solutions have never been fully implemented.

The root cause: "Speed and sensitivity" were seen as advantages before they became vulnerabilities. Real-time price updates seem more accurate—until someone tampers with them.

2. Centralization Risk

Dominant trading platforms create "single points of failure": bZx relied on Uniswap, Compound relied on Coinbase, and the platforms in January and October 2025 relied on their own order books—essentially the same problem. The platforms change, but the vulnerability remains.

When a particular exchange dominates trading volume, using it as the main oracle data source seems reasonable. But the centralization risk in price feeds is the same as in any system: everything seems fine until it’s exploited.

3. Infrastructure Assumption Bias

Systems designed for "normal markets" will fail catastrophically under stress. Harvest Finance proved this in 2020, but the October 2025 incident shows the industry is still "designing for normalcy and hoping stress events never occur."

But "hope" is not a strategy.

4. Transparency Paradox

Announcing technical improvements can actually create attack windows. The eight-day gap between announcing and implementing an oracle algorithm update gave professional attackers a clear roadmap and timeline—they knew exactly when to strike and which vulnerability to exploit.

This is a "new failure mode for an old problem": previous attacks exploited "existing vulnerabilities," while the October 2025 attack exploited the "transition period during oracle algorithm switching"—a vulnerability that existed only because the improvement plan was announced in advance.

Breaking the Deadlock

Immediate Improvement Measures

1. Hybrid Oracle Design

Integrate multiple price sources and add effective rationality checks:

• Centralized exchange (CEX) prices (cross-platform volume-weighted, 40%);
• Decentralized exchange (DEX) prices (only high-liquidity pools, 30%);
• On-chain proof of reserves (20%);
• Conversion ratios for wrapped assets (10%).

The key is "data source independence": if all sources can be manipulated at reasonable cost, then "multi-source" is essentially still "single-source."

2. Dynamic Weight Adjustment

Adjust oracle sensitivity based on market conditions:

• Normal volatility: use standard weights;
• High volatility: extend the TWAP calculation window, reduce spot price impact;
• Extreme volatility: trigger circuit breakers and initiate rationality checks.

The 2020 Compound incident proved: sometimes the "correct price" on one exchange is the wrong price for the entire market. Oracles need the intelligence to recognize such deviations.

3. Circuit Breaker Mechanism

Pause liquidations during extreme price swings—not to prevent "reasonable deleveraging," but to distinguish "manipulation" from "real market conditions":

• If prices converge across multiple platforms within minutes: likely real market volatility;
• If only one platform shows abnormal prices: likely manipulation;
• If infrastructure is overloaded: pause liquidations until capacity recovers.

The core goal is not to "ban all liquidations," but to "avoid chain liquidations triggered by manipulated prices."

4. Infrastructure Scaling

Design systems for "100x normal capacity"—because chain reactions create exponential loads:

• Build dedicated infrastructure for price feeds;
• Deploy independent liquidation engines;
• Set request rate limits for individual addresses;
• Establish "graceful degradation" protocols (prioritize core functions during overload).

If the system cannot withstand the load from chain reactions, it will only worsen the disaster. This is a design necessity, not an optimization option.

Long-Term Solutions

1. Decentralized Oracle Networks

Adopt mature oracle solutions (such as Chainlink, Pyth, UMA), which achieve built-in anti-manipulation by aggregating across data sources. They are not perfect, but far superior to spot-dependent oracles that "get attacked every 18 months."

bZx integrated Chainlink after the 2020 attack and has not suffered another oracle manipulation attack since—this is no coincidence.

2. Proof of Reserves Integration

For wrapped assets and stablecoins, collateral value must be verified on-chain. For example, USDe’s pricing should be based on "verifiable reserves," not "order book dynamics." The technology exists; only implementation lags behind.

3. Gradual Liquidation

Use phased liquidations to prevent chain reactions from escalating:

• First threshold: issue a warning, giving users time to add collateral;
• Second threshold: partial liquidation (25%);
• Third threshold: larger-scale liquidation (50%);
• Final threshold: full liquidation.

This gives users time to respond and reduces the impact of "large-scale simultaneous liquidations" on the system.

4. Real-Time Audit Monitoring

Monitor oracle manipulation in real time:

• Cross-platform price deviations;
• Abnormal trading volume in low-liquidity pairs;
• Rapid growth in position sizes before oracle updates;
• Pattern matching with known attack signatures.

The October 2025 attack should have triggered warning signals: a $60 million USDe sell-off at 5:43 a.m. must trigger an alert. If the monitoring system failed to catch it, it is seriously deficient.

Conclusion: The $19 Billion Warning

The chain liquidations of October 10-11, 2025, were not triggered by "excessive leverage" or "market panic," but by "large-scale oracle design failure." The reason a $60 million market operation turned into a $19.3 billion loss was that the price feed system could not distinguish "manipulation" from "legitimate price discovery."

But this is not a new problem—the same type of failure destroyed bZx in February 2020, Harvest in October 2020, Compound in November 2020, and Mango Markets in October 2022.

In five years, the industry has learned the same lesson five times, each time at a higher cost:

• 2020: Individual protocols learned and implemented fixes;
• 2022: Regulators intervened and began enforcement;
• 2025: The entire market paid $19.3 billion in "tuition."

The only question now is: will we finally remember this lesson?

All platforms handling leveraged positions must face the following questions:

• Can our oracles withstand the attack vectors clearly identified in 2020-2022?
• Can our infrastructure handle chain liquidation scenarios that have already occurred?
• Have we achieved a reasonable balance between "sensitivity" and "stability"?
• Are we repeating the same mistakes that have cost the industry hundreds of millions of dollars?

Five years of history have proven: oracle manipulation is not a "hypothetical risk" or "edge case," but a "documented, repeatable, highly profitable" attack strategy whose scale grows with the market.

The October 2025 incident shows what disasters can occur when these lessons are ignored at an institutional scale. This attack was neither complex nor novel—it was simply the same playbook, executed against a larger system during a "known vulnerability window."

The oracle is the cornerstone of the entire system. When the cornerstone cracks, everything built on it collapses. Since February 2020, we have understood this and have spent billions of dollars repeatedly proving it. The only question now is whether the costly lesson of October 2025 will finally prompt us to turn known lessons into action.

In today’s highly interconnected markets, oracle design is far more than just "data feeds"—it concerns the stability of the entire system. If the design is wrong, $60 million can destroy $19 billion in value.

If we keep making the same mistakes, it’s not that we haven’t learned from history, but that the cost of repeating those mistakes keeps getting higher.

This analysis is based on public market data, platform statements, and five years of oracle manipulation case studies.