Original author: YQ

Original translation: TechFlow

On October 10-11, 2025, a $60 million market sell-off destroyed $19.3 billion in value. This was not caused by a market crash or a cascading liquidation of truly damaged positions, but rather by an oracle failure.

This isn't new. The same attack model has been successfully exploited numerous times since February 2020, resulting in dozens of incidents across the industry totaling hundreds of millions of dollars in losses. However, the October 2025 incident amplified the scale of the previous largest oracle attack by 160 times—not due to increased technical sophistication, but rather to the expansion of the underlying system while maintaining the same fundamental vulnerability.

Over the past five years, we have paid a high price, yet we have failed to learn our lesson. This article will analyze the reasons.

The Oracle Dilemma: Sensitivity vs. Stability

Every platform faces a fundamental challenge when using leverage: how to accurately price collateral while preventing price manipulation?

• Overly sensitive → vulnerable to manipulation attacks
• Too stable → unable to reflect real losses in a timely manner

The October 2025 event selected "Sensitivity." The oracle faithfully tracked the spot market price, and when $60 million worth of assets were sold off, the oracle adjusted the collateral price downward in real time, triggering a mass liquidation. The system performed exactly as designed.

However, this design was disastrous.

A model that has been ignored for five years

Before analyzing the events of October 2025, we need to understand that this is not the first time this has happened.

Previous Periods (2020-2022)

February 2020: bZx ($350,000 + $630,000 lost) uses a single-source oracle. Flash loans manipulate the price of WBTC on Uniswap. 14.6% of the total supply was moved to manipulate the price data bZx relies on.

October 2020: Harvest Finance ($24 million stolen, $570 million run) manipulated the price of Curve's stablecoin using a $50 million flash loan in just seven minutes. This triggered an infrastructure collapse and a massive liquidity withdrawal, resulting in losses far exceeding the initial theft amount.

November 2020: Compound ($89 million in liquidations) saw DAI on Coinbase Pro briefly spike to $1.30, a phenomenon unseen on this exchange. Compound's oracle, which uses Coinbase's price as a benchmark, led to users being liquidated due to a brief price anomaly. Manipulation required $100,000 to leverage an order book with a depth of $300,000.

October 2022: Mango Markets ($117 million loss) leveraged its initial $5 million capital to drive the price of the MNGO token up 2,394% across multiple trading platforms. It subsequently borrowed $117 million against high collateral and used the stolen governance tokens to vote for itself, earning $47 million in "bug bounties." This marked the first enforcement action by the U.S. Commodity Futures Trading Commission (CFTC) against oracle manipulation.

Commonalities

Each attack follows the same logic:

1. Identify the manipulated data sources the oracle relies on
2. Calculation: Manipulation cost < Extractable value
3. Carrying out the attack
4. Profit

2020-2022: 41 oracle manipulation attacks resulted in $403.2 million stolen.

Industry Response: Responses have been fragmented, slow, and incomplete. Most platforms are still using spot-based oracles with insufficient redundancy.

Then, the events of October 2025 occurred.

The Anatomy of an Oracle Failure: 2025 Edition

October 10, 2025, 5:43 AM: $60 million worth of USDe is sold into the spot market.

In a properly designed oracle: multiple independent data sources will absorb the shock and the impact will be minimal.

In this oracle: Disaster happens.

$60 million in spot sell-off → Oracles lower collateral prices (wBETH, BNSOL, USDe) → Mass liquidation triggered → Infrastructure overload → Liquidity vacuum → $19.3 billion in assets evaporated

Amplification effect

• Mango Markets (2022) : $5 million manipulated → $117 million withdrawn (23x)
• October 2025 : $60 million manipulated → $19.3 billion destroyed (322x)

This is not due to increased technological complexity, but rather to the same vulnerabilities being magnified to an institutional scale.

Weight distribution problem

This oracle relies heavily on spot prices from major exchanges. When a single exchange dominates the trading volume:

• High trading volume appears to indicate reliable price discovery (seemingly reasonable)
• Centralization increases the risk of manipulation (an Achilles' heel)
• A single internal price creates a self-perpetuating cycle (exacerbating the problem)

One analyst’s comment reveals the flaw in this logic: “Because [the exchange] has the largest trading volume for usde/bnsol/wbeth, according to the oracle weight distribution, it should refer to the spot price.”

This instinct—believing in the largest market—has led to billions of dollars in losses over five years. Concentrated trading volume is not evidence of accurate prices; it signals an opportunity for manipulation.

Scheduled vulnerability window

The oracle method update was announced eight days before implementation. This gave the attackers:

• Oracle Dependencies
• Predictable transition timing
• Eight days of preparation

While previous oracle attacks exploited existing vulnerabilities, the October 2025 attack exploited a vulnerability during the oracle method switch—a vulnerability that existed only because the improvement was announced early.

Site isolation testing

The clearest evidence suggests that this incident was caused by oracle failure, not asset loss:

• Major exchanges : USDe price is $0.6567, wBETH price is $430
• Other trading platforms : price deviation is less than 30 basis points
• On-chain liquidity pool : minimal impact

As Ethena’s Guy noted: “During the event, over $9 billion in stablecoin collateral remained available for immediate redemption.”

Prices fluctuated wildly on the exchanges the oracle sourced its data from, while remaining stable elsewhere. The oracle reported manipulated prices, triggering liquidations based on prices that didn’t exist elsewhere in the market.

This is exactly the same pattern as the Compound incident in 2020: price manipulation in isolated trading venues was recorded by oracles, causing systemic damage.

The ripple effect of infrastructure

Analyst agintender points out the amplification mechanism:

“Chained liquidations caused servers to be overloaded with millions of requests. Market makers were unable to bid in a timely manner, creating a liquidity vacuum.”

This is exactly the amplified version of the Harvest Finance incident in 2020. The attack triggered liquidations faster than the infrastructure could process, market makers were unable to respond, liquidity disappeared, and the chain reaction became self-reinforcing.

After Harvest Finance’s infrastructure collapse in October 2020 (TVL dropped from $1 billion to $599 million as users withdrew their funds), the lesson was clear: oracle systems must account for infrastructure capacity during stress events.

However, the events of October 2025 proved that we had not learned our lesson.

Sensitivity Tradeoffs: Two Approaches, One Disaster

Guy from Ethena articulated the core design challenge: the oracle must distinguish between short-term temporary deviations (market noise) and long-term asset impairment (true losses).

October 2025 shows two possible responses:

High sensitivity method (failed exchanges)

• Track spot prices in real time
• Quickly respond to market changes
• The result : a $19.3 billion ripple effect

This is the bZx/Harvest approach: trusting the spot market, only to be destroyed by manipulation.

High Stability Method (Surviving DeFi Platform)

• Hard-written USDe = USDT
• Ignore short-term market noise
• Result : No liquidation

This is an overcorrection, which is better than failure, but still not optimal.

The industry had five years to develop a nuanced solution. We found neither an optimal solution nor an acceptable solution—we fell into two extremes, and institutional scale ultimately chose the catastrophic solution.

Oracle Attack Theorem: Now Experimentally Proven

Theorem : In any lever system, if the following conditions are met:

1. Oracle prices rely heavily on the manipulable spot market
2. Liquidation trigger conditions are deterministic
3. Infrastructure has capacity limitations

Then: manipulation cost < value that can be extracted through chain reaction

Proof verified by repeated practice:

• bZx (February 2020) : Uniswap manipulation → $350,000 + $630,000 withdrawn
• Harvest (October 2020) : Curve manipulation → $24 million stolen + triggered a $570 million bank run
• Compound (November 2020) : Coinbase manipulation → $89 million liquidated
• Mango (October 2022) : Multi-platform manipulation → Withdrawal of $117 million
• October 2025 : Major exchange manipulation → $19.3 billion lost

As the system scales linearly, the scale of damage increases exponentially. The cost of manipulation remains roughly constant (determined by liquidity), but the extractable value increases as the total amount of leverage in the system grows.

October 2025 verified this theorem on an unprecedented scale.

Oracle Design Principles: Lessons We Should Have Learned

1. Multi-source verification

Never rely on a single exchange price, especially one from its own order book. This was the lesson of the bZx incident in February 2020. A sound oracle design requires:

Oracle price = weighted average of various data sources:

• Prices on multiple exchanges (40%)
• On-chain liquidity pool (30%)
• Conversion rate of packaging assets (20%)
• Time-weighted historical prices (10%)

Weight distribution is not as important as data source independence. If all data sources can be manipulated simultaneously by reasonable capital, then you actually have only one data source, not multiple.

1. Adaptive sensitivity

Oracles should adjust their sensitivity based on market conditions:

• Normal market : more sensitive to price changes
• Volatile Markets : Adding Stability Through Time Weighting
• Extreme Volatility: Circuit Breakers and Sanity Checks

Time-weighted average price (TWAP) oracles were widely adopted after the 2020 flash loan attacks, specifically to prevent manipulation of a single transaction. However, the oracle in October 2025 responded to the spot price in real time, as if no such incident had occurred in the past five years.

1. Infrastructure resilience

The oracle system must remain functional across chain events:

• Independent price data infrastructure
• Capacity to support millions of concurrent queries
• Graceful degradation mechanism under high load

The October 2020 Harvest Finance infrastructure collapse highlighted the importance of system capacity under stress. Liquidation chain reactions generate exponentially increasing load. Your infrastructure must handle not only the first liquidation, but also the 1,000th liquidation when market makers can't keep up and users panic.

1. Transparent but without loopholes

The 8-day window between announcement and implementation created a known attack vector. Better approaches include:

• Implement changes immediately after publication
• Use rolling updates without fixed dates
• Keep audit records but avoid preview periods

This is a new lesson, but one that makes sense from a game theory perspective: Never announce exploitable changes in advance . The attackers in October 2025 had eight days to plan, lay out, and prepare. They knew precisely when the window of vulnerability would open.

Systemic impacts: lessons unlearned

This isn’t just a failure of a single platform, but rather exposes widespread vulnerabilities that the entire industry hasn’t addressed even after five years of expensive education:

1. Over-reliance on spot prices

Despite exploiting this vulnerability in every major attack since 2020, most platforms still use oracle designs that primarily focus on spot prices. The industry knows that spot prices are susceptible to manipulation, and that time-weighted average prices (TWAP) and multi-source oracles offer better protection, but implementation remains incomplete.

Speed and sensitivity are advantages in normal circumstances, but become fatal flaws when it comes to manipulation. Real-time price updates appear more accurate until someone manipulates them.

1. Concentration risk

Dominant trading venues become single points of failure. This was evident with bZx’s reliance on Uniswap, Compound’s reliance on Coinbase, and, in October 2025, the platform’s reliance on its own order book. Exchanges may differ, but the vulnerabilities remain the same.

When a single exchange accounts for the majority of trading volume, it seems logical to use it as the primary oracle data source. However, the risk of price data concentration is like the risk of concentration in any system: it may seem harmless until exploited, but once exploited, the consequences can be severe.

1. Infrastructure assumptions

Systems designed for normal markets will completely break down under stress. Harvest Finance proved this in 2020, and October 2025 proved it again. We’re still designing systems for normal conditions and hoping that stress never happens.

Hope is not a strategy.

1. The transparency paradox

Publicizing improvements creates an attack window. The eight-day gap between the announcement and implementation of the oracle change provided attackers with a clear roadmap and timeline. They knew exactly when to launch their attack and how to exploit the vulnerability.

This is a new failure mode, but the problem remains essentially unsolved. While previous oracle attacks exploited existing vulnerabilities, the October 2025 attack exploited a vulnerability during the oracle method switch—a vulnerability that existed only because the change was announced early.

Way forward: Have we really learned our lesson this time?

Improve now

1. The hybrid oracle design combines multiple price sources with practical and efficient sanity checks:

• Centralized exchange prices (weighted by exchange trading volume)
• Decentralized exchange prices (high liquidity pools only)
• On-chain Proof of Reserves
• Cross-exchange deviation limits

Each data source should be independent of each other. If manipulating one data source affects other data sources, there is no redundancy.

1. Dynamic weight adjustment adjusts the oracle sensitivity according to market conditions:

• Normal Fluctuation: Standard Weight
• High volatility: Increase TWAP window to reduce spot impact
• Extreme volatility: Liquidations suspended pending investigation and subsequent action

The Compound attack demonstrated that sometimes the “correct” price on a single exchange can be wrong for the entire market. Your oracle should be smart enough to recognize this.

1. Circuit breakers suspend liquidations during periods of extreme price volatility — not to prevent legitimate deleveraging, but to distinguish manipulation from market reality:

• If prices converge across venues within a few minutes: it could be real
• If price fluctuations are limited to one venue: Possible manipulation
• If infrastructure is overloaded: suspend liquidation until capacity is restored

The goal is not to prevent all liquidations, but to prevent cascading liquidations triggered by price manipulation.

1. The infrastructure expansion was designed to handle 100 times the normal system capacity, as the chain reaction would create this level of load:

• Independent price data infrastructure
• Independent liquidation engine
• Rate limiting for a single address
• Graceful degradation protocol

If your system can't handle the load during a chain reaction, it will amplify the chain reaction. This is a design requirement, not an optimization option.

Long-term solution

1. Decentralized oracle networks use mature oracle solutions like Chainlink, Python, or UMA, which aggregate multiple data sources and have built-in manipulation resistance. These solutions are not perfect, but they are better than relying on spot oracles that are exploited every 18 months.

bZx integrated Chainlink after the 2020 attack. They are no longer vulnerable to oracle manipulation attacks. This is no coincidence.

1. Proof of Reserves Integration: For wrapped assets and stablecoins, collateral value is verified on-chain. USDE should be priced based on verifiable reserves, not order book dynamics. The technology exists, but implementation lags.
2. Gradual liquidation prevents chain reactions from amplifying by liquidating in stages:

• Phase 1: Warning and time to add collateral
• Phase 2: Partial Liquidation (25%)
• Phase 3: Larger Liquidation (50%)
• Final stage: Complete liquidation

This provides users with time to respond and reduces the impact of large simultaneous liquidations on the system.

1. Real-time audit monitoring of oracle manipulation behavior:

• Cross-exchange price deviation
• Unusual trading volume on low-liquidity trading pairs
• Rapidly increasing position size before an oracle update
• Pattern matching against known attack signatures

The October 2025 attack likely displayed warning signs. Someone selling $60 million in USDe at 5:43 AM should have set off alarms. If your monitoring system didn't pick up on these signals, then your monitoring system wasn't adequate.

Conclusion: A $19 Billion Reminder

The liquidation chain reaction of October 10-11, 2025, was not caused by excessive leverage or market panic, but rather by a massive oracle design failure. $60 million in market action was amplified into $19.3 billion in damage because the price data system was unable to distinguish between manipulation and genuine price discovery.

But this isn’t a new failure mode. It’s the same failure mode that destroyed bZx in February 2020, Harvest in October 2020, Compound in November 2020, and Mango in October 2022.

The industry has learned this lesson five times, with increasing cost:

• 2020 : Individual protocols learn lessons and implement fixes
• 2022 : Regulators learn lessons and begin enforcement
• 2025 : The entire market has learned its lesson and paid $19.3 billion in tuition fees

The only question is whether we have finally learned this lesson.

Every platform that handles leveraged positions must now ask:

• Are our oracles robust enough to protect against known attack vectors in 2020-2022?
• Can our infrastructure cope with the ripple effects we’ve already witnessed?
• Have we struck the right balance between sensitivity and stability?
• Are we repeating the mistakes that have cost the industry hundreds of millions of dollars?

Five years of history have proven that oracle manipulation is not a hypothetical risk or an edge case—it is a documented, repeatable, and highly profitable attack strategy that continues to amplify as the market grows.

October 2025 demonstrates what happens when these lessons are not learned at an institutional scale. The attack was neither sophisticated nor novel, it was simply the same playbook being run again on a larger system, exploiting a known vulnerability window.

The oracle is the cornerstone of the system. When it cracks, all the superstructures collapse.

In the modern connected market, oracle design is not only about data transmission but also about system stability.

A design error of $60 million can destroy $19.3 billion.

If you make the same mistake over and over again, you’re not learning from it; instead, you’re repeating it at a higher cost.

Analysis based on public market data, platform statements, and five years of case studies of oracle manipulation. The opinions expressed are my own and do not represent those of any entity.