After the crash, what kind of oracle do we need?
TechFlow Selected TechFlow Selected
After the crash, what kind of oracle do we need?
When the oracle develops cracks, all upper structures will collapse.
Navigating Web3 tides with focused insightsAuthor: YQ
Translation: TechFlow
On October 10–11, 2025, a $60 million market sell-off destroyed $19.3 billion in value. This was not due to a market crash or cascading liquidations from genuinely impaired positions, but rather stemmed from an oracle failure.
This is nothing new. Since February 2020, the same attack pattern has been successfully exploited multiple times, resulting in dozens of incidents across the industry with hundreds of millions of dollars lost. The October 2025 event, however, scaled the largest prior oracle attack by 160x—not due to increased technical complexity, but because underlying systems expanded while retaining the same fundamental vulnerabilities.
Over five years, we've paid dearly for our education, yet failed to learn. This article analyzes why.
The Oracle Dilemma: Sensitivity vs. Stability
Every platform using leverage faces a fundamental challenge: how to accurately price collateral while preventing price manipulation?
-
Too sensitive → Vulnerable to manipulation attacks
-
Too stable → Fails to reflect real losses promptly
The October 2025 event chose "sensitivity." Oracles faithfully tracked spot market prices. When $60 million worth of assets were sold off, oracles immediately marked down collateral values, triggering mass liquidations. The system operated exactly as designed.
Yet this design was catastrophic.
A Pattern Ignored for Five Years
Before analyzing the October 2025 event, we must understand: this situation has happened before.
Historical Recap (2020–2022)
February 2020: bZx ($350K + $630K lost) Used oracle relying on a single data source. Manipulated WBTC price on Uniswap via flash loans. 14.6% of total supply moved to manipulate price data relied upon by bZx.
October 2020: Harvest Finance ($24M stolen, $570M bank run) In just 7 minutes, used $50M flash loan to manipulate stablecoin prices on Curve. Triggered infrastructure collapse and massive liquidity withdrawal, losses far exceeding initial theft.
November 2020: Compound ($89M in liquidations) DAI briefly spiked to $1.30 on Coinbase Pro—only that exchange. Compound’s oracle used Coinbase’s price, leading users to be liquidated due to temporary price anomaly. Only $100K needed to manipulate order book depth of $300K.
October 2022: Mango Markets ($117M lost) Used $5M initial capital to inflate MNGO token price by 2394% across multiple exchanges. Then borrowed $117M against inflated collateral and voted themselves a $47M “bug bounty” using stolen governance tokens. First enforcement action by U.S. CFTC against oracle manipulation.
Commonality
Each attack followed the same logic:
-
Identify manipulatable data source relied upon by oracle
-
Calculate: manipulation cost < extractable value
-
Execute attack
-
Profit
2020 to 2022: 41 oracle manipulation attacks resulted in $403.2M stolen.
Industry response: fragmented, slow, and incomplete. Most platforms still use insufficiently redundant, spot-market-heavy oracles.
Then came the October 2025 event.
Anatomy of Oracle Failure: 2025 Edition
October 10, 2025, 5:43 AM: $60M worth of USDe dumped into spot markets.
In a well-designed oracle: multiple independent data sources absorb the shock, impact negligible.
In this oracle: disaster unfolded.
$60M spot sell-off → oracle marks down collateral prices (wBETH, BNSOL, USDe) → mass liquidations triggered → infrastructure overload → liquidity vacuum → $19.3B in assets erased
Amplification Effect
-
Mango Markets (2022): $5M manipulated → $117M extracted (23x)
-
October 2025: $60M manipulated → $19.3B destroyed (322x)
This wasn't due to greater technical sophistication, but because the same vulnerability was scaled to institutional magnitude.
Weighting Problem
This oracle heavily relied on spot prices from major exchanges. When one exchange dominates trading volume:
-
High volume superficially suggests credible price discovery (seemingly reasonable)
-
Centralization increases manipulation risk (fatal flaw)
-
Single internal pricing creates self-reinforcing loops (exacerbating problem)
A commentator revealed the flawed logic: "Because [this exchange] has the highest usde/bnsol/wbeth trading volume, according to oracle weighting, it should reference spot price."
This intuition—trusting the largest market—has cost billions over five years. Volume concentration isn't evidence of price accuracy; it's a signal of manipulation opportunity.
Pre-Announced Vulnerability Window
The oracle methodology update was publicly announced eight days prior. Attackers thus gained access to:
-
Oracle dependencies
-
Predictable transition timing
-
Eight days of preparation time
Past oracle attacks exploited existing vulnerabilities. The October 2025 attack exploited a vulnerability during oracle method transition—one that existed solely because improvements were announced in advance.
Venue Isolation Test
The clearest evidence this was an oracle failure, not asset impairment:
-
Main exchange: USDe at $0.6567, wBETH at $430
-
Other trading platforms: Price deviation under 30 basis points
-
On-chain liquidity pools: Negligible impact
As Ethena's Guy noted: "During the event, over $9B in stablecoin collateral remained available for immediate redemption."
Prices fluctuated wildly only on exchanges serving as oracle data sources, while remaining stable elsewhere. Yet the oracle reported manipulated prices, and the system triggered liquidations based on prices that didn’t exist in other markets.
This mirrors the 2020 Compound incident: isolated venue price manipulation, faithfully recorded by oracles, causing systemic damage.
Infrastructure Cascading Effects
Analyst agintender identified the amplification mechanism:
"Cascading liquidations overloaded servers with millions of requests. Market makers couldn't bid fast enough, creating a liquidity vacuum."
This is a magnified version of the 2020 Harvest Finance incident. Liquidations triggered faster than infrastructure could process them. Market makers couldn't respond, liquidity vanished, and the cascade reinforced itself.
After Harvest Finance’s infrastructure collapsed in October 2020 (TVL dropped from $1B to $599M amid user withdrawals), the lesson was clear: oracle systems must account for infrastructure capacity during stress events.
Yet the October 2025 event proves we haven’t learned.
Sensitivity Trade-Off: Two Approaches, One Disaster
Ethena’s Guy clarified the core design challenge: oracles must distinguish short-term temporary deviations (market noise) from long-term asset impairment (real loss).
October 2025 demonstrated two responses:
High-sensitivity approach (failed exchanges)
-
Real-time tracking of spot prices
-
Rapid response to market changes
-
Result: $19.3B cascading effect
This is the bZx/Harvest approach: trust spot markets, get destroyed by manipulation.
High-stability approach (surviving DeFi platforms)
-
Hard-code USDe = USDT
-
Ignore short-term market noise
-
Result: No liquidations
This is an overcorrection—better than failure, but still suboptimal.
The industry had five years to develop nuanced solutions. We found neither optimal nor acceptable alternatives—we remain stuck between two extremes, and institutional scale ultimately picked the disastrous one.
Oracle Attack Theorem: Now Empirically Proven
Theorem: In any leveraged system where:
-
Oracle prices primarily rely on manipulatable spot markets
-
Liquidation triggers are deterministic
-
Infrastructure has capacity limits
Then: manipulation cost < extractable value via cascading effects
Proven through repeated practice:
-
bZx (Feb 2020): Uniswap manipulation → extracted $350K + $630K
-
Harvest (Oct 2020): Curve manipulation → $24M stolen + $570M bank run triggered
-
Compound (Nov 2020): Coinbase manipulation → $89M liquidated
-
Mango (Oct 2022): Multi-venue manipulation → $117M extracted
-
October 2025: Major exchange manipulation → $19.3B lost
As system size grows linearly, damage scales exponentially. Manipulation cost remains largely unchanged (determined by liquidity), while extractable value increases with total system leverage.
The October 2025 event validated this theorem at unprecedented scale.
Oracle Design Principles: Lessons We Should Have Learned
-
Multi-source validation
Never rely on a single exchange price, especially one derived from your own order book. This was the lesson from bZx in February 2020. A sound oracle design requires:
Oracle price = weighted average of data sources:
-
Multiple exchange prices (40%)
-
On-chain liquidity pools (30%)
-
Wrapped asset conversion ratios (20%)
-
Time-weighted historical prices (10%)
Data source independence matters more than weight allocation. If all sources can be simultaneously manipulated with feasible capital, you effectively have one source, not many.
-
Adaptive sensitivity
Oracles should adjust sensitivity based on market conditions:
-
Normal markets: More responsive to price changes
-
Volatile markets: Increase stability via time weighting
-
Extreme volatility: Circuit breakers and sanity checks
Time-weighted average price (TWAP) oracles became widely adopted after 2020 flash loan attacks, specifically to prevent manipulation via single trades. Yet the October 2025 oracle responded in real-time to spot prices, as if no such events had occurred in the past five years.
-
Infrastructure resilience
Oracle systems must remain functional during cascades:
-
Independent price data infrastructure
-
Capacity to support millions of concurrent queries
-
Graceful degradation mechanisms under high load
Harvest Finance’s infrastructure collapse in October 2020 already revealed the importance of system capacity under stress. Cascading liquidations generate exponentially increasing load. Your infrastructure must handle not just the first liquidation, but the thousandth when market makers can’t keep up and users panic.
-
Transparent but not vulnerable
An 8-day window between announcement and implementation created a known attack vector. Better approaches include:
-
Implement changes immediately after announcement
-
Use rolling updates without fixed dates
-
Maintain audit logs but avoid preview periods
This is a new lesson, but logically consistent with game theory: never pre-announce exploitable changes. The October 2025 attackers had 8 full days to plan, position, and prepare. They knew exactly when the vulnerability window would open.
Systemic Implications: Lessons Still Not Learned
This wasn't just a single platform failure—it exposed a widespread industry vulnerability that persists despite five years of costly education:
-
Overreliance on spot prices
Despite every major attack since 2020 exploiting this weakness, most platforms still use spot-market-heavy oracle designs. The industry knows spot prices are manipulatable and that TWAP and multi-source oracles offer better protection, yet implementation remains incomplete.
Speed and sensitivity are advantages in normal conditions, but become fatal flaws under manipulation. Real-time price updates seem more accurate—until someone manipulates them.
-
Concentration risk
Dominant trading venues become single points of failure. This manifested when bZx relied on Uniswap, Compound on Coinbase, and the October 2025 platform on its own order book. Exchanges differ, but the vulnerability remains identical.
When one exchange dominates volume, using it as the primary oracle data source seems logical. But concentration risk in price data is like any systemic concentration risk: seemingly harmless until exploited, then devastating.
-
Infrastructure assumptions
Systems designed for normal markets completely collapse under stress. Harvest Finance proved this in 2020, and October 2025 proved again that we still design for normalcy and hope stress never occurs.
Hope is not a strategy.
-
Transparency paradox
Announcing improvements creates attack windows. The 8-day gap between oracle change announcement and implementation gave attackers a clear roadmap and timeline. They knew exactly when and how to strike.
This is a new failure mode, yet fundamentally unresolved. Previous oracle attacks exploited existing vulnerabilities; the October 2025 attack exploited a vulnerability during oracle method transition—one that existed solely because improvements were announced in advance.
Way Forward: Have We Finally Learned?
Immediate Improvements
-
Mixed oracle design combining multiple price sources with effective sanity checks:
-
CeFi exchange prices (volume-weighted)
-
DeFi exchange prices (only high-liquidity pools)
-
On-chain reserve proofs
-
Cross-venue deviation limits
Each data source must be independent. If manipulating one affects others, redundancy fails.
-
Dynamic weight adjustment adapting oracle sensitivity to market conditions:
-
Normal volatility: standard weights
-
High volatility: increase TWAP window, reduce spot impact
-
Extreme volatility: pause liquidations, investigate before acting
Compound’s attack showed that a “correct” price on one exchange might be wrong for the broader market. Your oracle should be smart enough to recognize this.
-
Circuit breakers pausing liquidations during extreme price swings—not to prevent legitimate deleveraging, but to distinguish manipulation from genuine market moves:
-
If prices converge across venues within minutes: likely genuine
-
If volatility is isolated to one venue: likely manipulation
-
If infrastructure is overloaded: pause liquidations until capacity recovers
Goal isn’t to prevent all liquidations, but to stop cascading liquidations triggered by manipulated prices.
-
Infrastructure scaling designing systems for 100x normal capacity, because cascades generate such loads:
-
Independent price data infrastructure
-
Independent liquidation engine
-
Rate limiting per address
-
Graceful degradation protocols
If your system can’t handle cascade-level loads, it will amplify the cascade. This is a design requirement, not an optimization.
Long-Term Solutions
-
Decentralized oracle networks adopt mature oracle solutions like Chainlink, Pyth, or UMA, which aggregate multiple data sources and include built-in anti-manipulation mechanisms. These aren’t perfect, but they’re better than spot-reliant oracles exploited every 18 months.
bZx integrated Chainlink after being attacked in 2020. They haven’t suffered oracle manipulation since. That’s no coincidence.
-
Reserve proof integration: For wrapped assets and stablecoins, verify collateral value on-chain. USDe should be priced based on verifiable reserves, not order book dynamics. Technology exists, implementation lags.
-
Staged liquidations preventing cascade amplification via phased liquidations:
-
Phase 1: Warning, allow time to add collateral
-
Phase 2: Partial liquidation (25%)
-
Phase 3: Larger liquidation (50%)
-
Final phase: Full liquidation
This gives users response time and reduces systemic shock from mass simultaneous liquidations.
-
Real-time auditing monitoring for oracle manipulation:
-
Cross-exchange price deviations
-
Abnormal volumes on low-liquidity pairs
-
Rapid position buildup before oracle updates
-
Pattern matching against known attack signatures
The October 2025 attack likely showed warning signs. Someone dumping $60M in USDe at 5:43 AM should have triggered alerts. If your monitoring system missed it, it’s inadequate.
Conclusion: A $19 Billion Reminder
The liquidation cascade of October 10–11, 2025 wasn’t caused by excessive leverage or market panic, but by a massive oracle design failure. A $60M market move was amplified into $19.3B in destruction because the pricing system couldn’t distinguish manipulation from genuine price discovery.
But this isn’t a new failure mode. It’s the same recurring failure that destroyed bZx in February 2020, Harvest in October 2020, Compound in November 2020, and Mango in October 2022.
The industry has now received this lesson five times, at ever-increasing cost:
-
2020: Individual protocols learned, implemented fixes
-
2022: Regulators learned, began enforcement
-
2025: Entire market learned, paid $19.3B tuition
The only question is whether we’ve finally remembered.
Every platform handling leveraged positions must now ask:
-
Is our oracle robust enough to withstand known attack vectors from 2020–2022?
-
Can our infrastructure handle the cascading scenarios we’ve already witnessed?
-
Have we correctly balanced sensitivity and stability?
-
Are we repeating the same mistakes that cost the industry hundreds of millions?
Five years of history prove oracle manipulation isn’t a hypothetical risk or edge case—it’s a documented, repeatable, and profitable attack strategy that scales with market growth.
October 2025 showed what happens when these lessons aren’t learned at institutional scale. The attack wasn’t complex or novel—just the same script replayed on a larger system, exploiting a known vulnerability window.
Oracles are the foundation of the system. When they crack, everything above collapses.
In modern interconnected markets, oracle design isn’t just about data transmission—it’s about systemic stability.
Poor design, $60M can destroy $19.3B.
Repeated failures mean you're not learning—you're repeating errors at higher cost.
Analysis based on public market data, platform statements, and five years of oracle manipulation case studies. Views expressed are my own, not representing any entity.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
