When oracles show cracks, all upper structures will collapse.
Author: YQ
Compiled by: Deep Tide TechFlow
From October 10 to 11, 2025, a market sell-off worth $60 million destroyed $19.3 billion in value. This was not due to a market crash or a series of real liquidations of damaged positions, but rather a failure of the oracle.
This is not a new phenomenon. Since February 2020, the same attack pattern has been successfully exploited multiple times, leading to dozens of incidents in the industry with total losses amounting to hundreds of millions of dollars. However, the October 2025 incident magnified the scale of previous oracle attacks by 160 times—not due to increased technical complexity, but because the underlying systems expanded while maintaining the same fundamental vulnerabilities.
Over the past five years, we have paid a high tuition but have never learned the lesson. This article will analyze the reasons behind this.
The Oracle Dilemma: Sensitivity vs. Stability
Every platform faces a fundamental challenge when using leverage: how to accurately price collateral while preventing price manipulation?
Too Sensitive → Vulnerable to manipulation attacks
Too Stable → Unable to reflect real losses in a timely manner
The October 2025 incident chose "sensitivity." The oracle faithfully tracked spot market prices, and when $60 million worth of assets were sold off, the oracle real-time adjusted the collateral prices (wBETH, BNSOL, USDe), triggering large-scale liquidations. The system operated exactly as designed.
However, this design was catastrophic.
Patterns Ignored for Five Years
Before analyzing the October 2025 incident, we need to understand: this is not the first time this has happened.
Past Review (2020-2022)
February 2020: bZx (Loss of $350,000 + $630,000) used a single data source oracle. Manipulated the WBTC price on Uniswap through a flash loan. 14.6% of the total supply was moved to manipulate the price data relied upon by bZx.
October 2020: Harvest Finance ($24 million stolen, $570 million in withdrawals) manipulated the price of Curve's stablecoin using a $50 million flash loan in just 7 minutes. This triggered infrastructure collapse and massive liquidity withdrawals, with losses far exceeding the initial theft amount.
November 2020: Compound (Liquidation amount reached $89 million) DAI on Coinbase Pro spiked to $1.30 in a short time, only on that exchange. Compound's oracle used Coinbase's price as a benchmark, leading to user liquidations due to temporary price anomalies. Manipulation required only $100,000 to leverage a $300,000 order book.
October 2022: Mango Markets (Loss of $117 million) used $5 million in initial capital to push the MNGO token price up by 2394% across multiple trading platforms. Subsequently borrowed $117 million with high collateral and used stolen governance tokens to vote for a $47 million "bug bounty." This was the first enforcement action by the U.S. Commodity Futures Trading Commission (CFTC) against oracle manipulation.
Commonality
Each attack followed the same logic:
Identify the manipulable data source relied upon by the oracle
Calculate: Manipulation cost vs. extractable value
Execute the attack
Obtain profit
From 2020 to 2022: 41 oracle manipulation attacks resulted in $403.2 million stolen.
Industry response: scattered, slow, and incomplete. Most platforms still use insufficiently redundant, spot-based oracles.
Then, the October 2025 incident occurred.
Dissection of Oracle Failure: 2025 Edition
On October 10, 2025, at 5:43 AM: $60 million worth of USDe was sold into the spot market.
In a well-designed oracle: multiple independent data sources would absorb the shock, with minimal impact.
In this oracle: disaster struck.
$60 million spot sell-off → Oracle adjusts collateral prices (wBETH, BNSOL, USDe) downward → Large-scale liquidation triggered → Infrastructure overload → Liquidity vacuum → $19.3 billion in assets evaporated
Amplification Effect
Mango Markets (2022): Manipulated $5 million → Extracted $117 million (23 times)
October 2025: Manipulated $60 million → Destroyed $19.3 billion (322 times)
This was not due to increased technical complexity, but because the same vulnerabilities were amplified to an institutional scale.
Weight Distribution Problem
The oracle heavily relied on the spot prices from major exchanges. When one exchange dominates trading volume:
High trading volume superficially seems to indicate the credibility of price discovery (seemingly reasonable)
Centralization increases the risk of manipulation (fatal weakness)
Single internal price creates a self-reinforcing cycle (problem exacerbated)
A comment from an analyst revealed the flaw in this logic: “Because [that exchange] has the highest trading volume for usde/bnsol/wbeth, it should reference the spot price according to the oracle's weight distribution.”
This intuition—trusting the largest market—has led to billions of dollars in losses over the past five years. Concentrated trading volume is not evidence of price accuracy, but a signal of manipulation opportunity.
Scheduled Vulnerability Window
The update to the oracle method was announced eight days before implementation. Attackers thus gained:
The oracle's dependencies
Predictable transition time points
Eight days of preparation time
Previous oracle attacks exploited existing vulnerabilities, while the October 2025 attack exploited vulnerabilities during the transition period of the oracle method switch—vulnerabilities that existed solely because the improvements were announced in advance.
Venue Isolation Testing
The clearest evidence indicates that this incident was due to oracle failure, not asset impairment:
Major exchanges: USDe price was $0.6567, wBETH price was $430
Other trading platforms: Price deviations were less than 30 basis points
On-chain liquidity pools: Minimal impact
As pointed out by Guy from Ethena: “During the event, there were still over $9 billion in stablecoin collateral available for immediate redemption.”
Prices fluctuated wildly on the exchanges that provided oracle data, while remaining stable in other markets. The oracle reported manipulated prices, and the system triggered liquidations based on prices that did not exist elsewhere in the market.
This mirrored the pattern of the 2020 Compound incident: isolated venue price manipulation, accurately recorded by the oracle, leading to systemic destruction.
Chain Reaction of Infrastructure
Analyst agintender pointed out the amplification mechanism:
“Chain liquidations caused the servers to overload due to millions of requests. Market makers could not quote in time, creating a liquidity vacuum.”
This was a magnified version of the 2020 Harvest Finance incident. The attack triggered liquidations faster than the infrastructure could process, market makers could not respond, liquidity vanished, and the chain reaction self-reinforced.
After the infrastructure collapse at Harvest Finance in October 2020 (TVL dropped from $1 billion to $599 million as users withdrew), the lesson was clear: oracle systems must consider infrastructure capacity during stress events.
However, the October 2025 incident proved that we did not learn the lesson.
Sensitivity Trade-off: Two Approaches, One Disaster
Guy from Ethena clarified the core design challenge: oracles must distinguish between short-term temporary deviations (market noise) and long-term asset impairment (real losses).
The October 2025 incident showcased two approaches:
High Sensitivity Approach (Failed Exchanges)
Real-time tracking of spot prices
Rapid response to market changes
Result: $19.3 billion chain effect
This is the approach of bZx/Harvest: trusting the spot market, but destroyed by manipulation.
High Stability Approach (Surviving DeFi Platforms)
Hard-coded USDe = USDT
Ignore short-term market noise
Result: No liquidations
This is an overcorrection; while better than failure, it is still not optimal.
The industry has had five years to develop detailed solutions. We have found neither the optimal solution nor an acceptable one—we have fallen into two extremes, and the institutional scale ultimately chose a disastrous solution.
Oracle Attack Theorem: Now Proven by Experiment
Theorem: In any leveraged system, if the following conditions are met:
The oracle price primarily relies on manipulable spot markets
Liquidation trigger conditions are deterministic
Infrastructure has capacity limitations
Then: Manipulation cost can extract value through chain reactions
Proof validated by repeated practice:
bZx (February 2020): Uniswap manipulation → Extracted $350,000 + $630,000
Harvest (October 2020): Curve manipulation → Stolen $24 million + triggered $570 million bank run
Compound (November 2020): Coinbase manipulation → Liquidated $89 million
Mango (October 2022): Multi-platform manipulation → Extracted $117 million
October 2025: Major exchange manipulation → Loss of $19.3 billion
As the system scale grows linearly, the scale of damage grows exponentially. Manipulation costs remain relatively constant (determined by liquidity), but extractable value increases with the total leverage in the system.
The October 2025 incident validated this theorem on an unprecedented scale.
Oracle Design Principles: Lessons We Should Have Learned
- Multi-Source Verification
Never rely on a single exchange price, especially prices from your own order book. This is the lesson from the bZx incident in February 2020. A reasonable oracle design requires:
Oracle Price = Weighted Average of Various Data Sources:
Prices from multiple exchanges (40%)
On-chain liquidity pools (30%)
Conversion rates of wrapped assets (20%)
Time-weighted historical prices (10%)
The independence of data sources is more important than weight distribution. If all data sources can be reasonably manipulated by capital simultaneously, then you effectively have only one data source, not multiple.
- Adaptive Sensitivity
Oracles should adjust sensitivity based on market conditions:
Normal Market: More sensitive to price changes
Volatile Market: Increase stability through time-weighting
Extreme Volatility: Circuit breaker mechanisms and integrity checks
Time-weighted average price (TWAP) oracles were widely adopted after the 2020 flash loan attacks, specifically to prevent manipulation from single trades. However, the October 2025 oracle responded in real-time to spot prices as if nothing similar had happened in the past five years.
- Infrastructure Resilience
Oracle systems must remain functional during chain events:
Independent price data infrastructure
Capacity to support millions of concurrent queries
Smooth degradation mechanisms under high load
The infrastructure collapse of Harvest Finance in October 2020 already revealed the importance of system capacity under stress. Liquidation chain reactions generate exponentially increasing loads. Your infrastructure must not only handle the first liquidation but also the 1000th liquidation when market makers cannot keep up and users panic.
- Transparency Without Vulnerabilities
The 8-day window between announcement and implementation created a known attack vector. Better approaches include:
Implementing changes immediately after announcement
Using rolling updates without fixed dates
Maintaining audit trails but avoiding preview periods
This is a new lesson, but from a game theory perspective, it makes sense: Never announce changes that can be exploited in advance. The attackers in October 2025 had 8 days to plan, layout, and prepare. They knew exactly when the vulnerability window would open.
Systemic Impact: Lessons Not Yet Learned
This is not just a failure of a single platform, but exposes a widespread vulnerability in the entire industry that remains unresolved after five years of costly education:
- Over-Reliance on Spot Prices
Despite every major attack since 2020 exploiting this vulnerability, most platforms still use spot-based oracle designs. The industry knows that spot prices are easily manipulated and that time-weighted average prices (TWAP) and multi-source oracles can provide better protection, yet implementation remains incomplete.
Speed and sensitivity are advantages under normal circumstances, but become fatal flaws when faced with manipulation. Real-time price updates seem more accurate until someone manipulates them.
- Concentration Risk
Dominant trading venues become single points of failure. This was evident when bZx relied on Uniswap, Compound relied on Coinbase, and the platforms in October 2025 relied on their own order books. The exchanges may differ, but the vulnerabilities remain consistent.
When one exchange dominates trading volume, it seems logical to use it as the primary oracle data source. However, the concentration risk of price data is like any system's concentration risk: it appears harmless until exploited, but the consequences are severe once it is.
- Infrastructure Assumptions
Systems designed for normal markets can completely collapse under stress. Harvest Finance proved this in 2020, and the October 2025 incident reaffirmed that we are still designing systems for normal conditions, hoping that stress will never occur.
Hope is not a strategy.
- Transparency Paradox
Announcing improvements creates attack windows. The 8-day interval between oracle changes from announcement to implementation provided attackers with a clear roadmap and timeline. They knew exactly when to launch their attack and how to exploit the vulnerabilities.
This is a new failure mode, but fundamentally, the problem remains unsolved. Previous oracle attacks exploited existing vulnerabilities, while the October 2025 attack exploited vulnerabilities during the transition period of the oracle method switch—vulnerabilities that existed solely because the improvements were announced in advance.
Moving Forward: Have We Really Learned Our Lesson This Time?
Immediate Improvements
- Hybrid Oracle Design combines multiple price sources with effective integrity checks:
Centralized exchange prices (weighted by exchange trading volume)
Decentralized exchange prices (limited to high liquidity pools)
On-chain proof of reserves
Cross-exchange deviation limits
Each data source should be independent of one another. If manipulating one data source affects others, then redundancy does not exist.
- Dynamic Weight Adjustment adjusts oracle sensitivity based on market conditions:
Normal fluctuations: Standard weights
High volatility: Increase TWAP window, reduce spot impact
Extreme volatility: Pause liquidations, investigate before taking action
The Compound attack showed that sometimes the "correct" price from a single exchange can be wrong for the entire market. Your oracle should be smart enough to recognize this.
- Circuit Breaker Mechanisms pause liquidations during extreme price fluctuations—not to prevent legitimate deleveraging, but to distinguish between manipulation and real market conditions:
If prices converge across venues within minutes: it may be a real situation
If price fluctuations are limited to one venue: it may be manipulation
If infrastructure is overloaded: pause liquidations until capacity is restored
The goal is not to prevent all liquidations but to prevent chain liquidations triggered by manipulated prices.
- Infrastructure Scaling designs should account for systems that can handle 100 times normal capacity, as chain reactions can generate loads of this level:
Independent price data infrastructure
Independent liquidation engines
Rate limits on individual addresses
Smooth degradation protocols
If your system cannot withstand the load during a chain reaction, it will amplify the chain reaction. This is a design requirement, not an optimization option.
Long-Term Solutions
- Decentralized Oracle Networks adopt mature oracle solutions like Chainlink, Pyth, or UMA, which aggregate multiple data sources and have built-in resistance to manipulation. These solutions are not perfect, but they are better than spot-based oracles that get exploited every 18 months.
bZx integrated Chainlink after being attacked in 2020. They are no longer vulnerable to attacks through oracles. This is not a coincidence.
Proof of Reserves Integration: For wrapped assets and stablecoins, verify collateral value on-chain. USDe should be priced based on verifiable reserves rather than order book dynamics. The technology exists, but implementation lags behind.
Phased Liquidations prevent chain reactions from amplifying through staged liquidations:
Phase One: Warning and time to add collateral
Phase Two: Partial liquidation (25%)
Phase Three: Larger-scale liquidation (50%)
Final Phase: Complete liquidation
This provides users with time to respond and reduces the impact of large-scale simultaneous liquidations on the system.
- Real-Time Auditing monitors for oracle manipulation behaviors:
Cross-exchange price deviations
Abnormal trading volumes on low liquidity trading pairs
Rapidly increasing position sizes before oracle updates
Pattern matching against known attack characteristics
The October 2025 attack likely showed warning signals. Someone selling $60 million of USDe at 5:43 AM should have triggered alarms. If your monitoring system did not capture these signals, it indicates that your monitoring system is inadequate.
Conclusion: A $19 Billion Reminder
The chain reaction of liquidations from October 10 to 11, 2025, was not triggered by excessive leverage or market panic, but by a massive failure in oracle design. A $60 million market action was amplified to a $19.3 billion destruction because the price data system could not distinguish between manipulation and real price discovery.
But this is not a new failure mode. It is a recurring failure mode that has 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, and the cost has only increased:
2020: Individual protocols learned the lesson and implemented fixes
2022: Regulators learned the lesson and began enforcement
2025: The entire market learned the lesson, paying a $19.3 billion tuition
The only question is whether we have finally remembered this lesson.
Every platform handling leveraged positions must now ask:
Are our oracles robust enough to withstand the known attack vectors from 2020-2022?
Can our infrastructure handle the chain reaction venues we have already witnessed?
Are we correctly balancing 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 edge case—it is a documented, repeatable, and profitable attack strategy that amplifies with the growth of market scale.
The October 2025 incident demonstrated what happens when these lessons are not learned at an institutional scale. The attack was neither complex nor novel; it was merely the same script run on a larger system, exploiting known vulnerability windows.
Oracles are the cornerstone of the system. When they show cracks, all upper structures will collapse.
In modern interconnected markets, oracle design is not just about data transmission; it is about system stability.
Design flaws can destroy $19.3 billion from a $60 million mistake.
Repeated errors mean you are not learning lessons but are instead repeating mistakes at a higher cost.
Analysis based on public market data, platform statements, and case studies of oracle manipulation over the past five years. The views expressed in this article are solely my own and do not represent any entity.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
