Protocol: YieldBlox DAO (Blend V2 pool on Stellar)

Loss: ~$10.2M (~$3M unrecovered; ~$7.2M frozen by Stellar Tier-1 validators)

Attack Type: Price oracle manipulation via thin-liquidity market

Root Cause: Pool operator configured a VWAP oracle against a manipulable, near-zero-liquidity market with no circuit breakers or sanity checks

Overview

On February 22, 2026, a community-managed YieldBlox lending pool built on Blend V2 was drained of approximately $10.2M in USDC and XLM. The exploit did not require a smart contract bug. No reentrancy. No logic flaw. No vulnerability in Blend V2's core contracts.

This was a market design failure, and one that static analysis tooling flagged before it became a $10M incident.

Background

Blend V2 is a modular liquidity protocol on Stellar that allows operators to deploy isolated lending pools with custom asset configurations and oracle settings. YieldBlox DAO operated one such pool, accepting USTRY as collateral against borrowable USDC and XLM.

Collateral pricing for USTRY was sourced from the USTRY/USDC market on the Stellar DEX (SDEX) via Reflector, a VWAP-based oracle that calculates prices using recent trade data weighted by volume. This design works under normal conditions. In thin markets, it becomes an attack surface.

Attack Walkthrough

Step 1: Market Condition Setup

In the period immediately preceding the attack, the USTRY/USDC market on SDEX had effectively zero activity. The pool's sole market maker had withdrawn all liquidity, leaving the order book with less than $1 in hourly volume and no meaningful depth.

This created the necessary precondition: Reflector's VWAP calculation window was empty. Any trade placed would dominate the average.

Step 2: Oracle Manipulation (Tx 1–3)

The attacker operated across multiple accounts. Using one account, they placed a sell offer for USTRY at 501 USDC per USTRY, roughly 476x above fair value. Using a second account, they executed a buy against that offer, purchasing 0.05 USTRY for approximately 106.7 USDC.

This single micro-trade was enough. Because no other trades existed within the VWAP window, Reflector updated USTRY's price from ~$1.05 to ~$106.70, a 100x inflation.

The oracle was functioning exactly as designed. The problem was what it was pointed at.

Tx hashes:

• Manipulation: 09e1a9d1..., 60fe039e...
• Oracle update: 56466ad6...

Step 3: Collateral Inflation and Borrow Drain (Tx 4–7)

With USTRY now valued at ~$107 instead of ~$1, the attacker's holdings were treated as massively overcollateralized. They executed two borrow operations:

The inflated collateral valuation bypassed health factor checks. The attacker withdrew the entirety of the pool's borrowable reserves.

The borrowed amounts then triggered cascading liquidations across other pool participants, amplifying total damage.

Step 4: Cross-Chain Exfiltration (Tx 8–10)

The attacker bridged stolen assets from Stellar to Base (via Allbridge), BSC, and Ethereum (via Across and Relay), splitting across 31+ bridge transactions to fragment traceability.

Primary attacker addresses:

• Stellar: GBO7VUL2..., GCNF5GNR..., GDHRCQNC..., GATDQL76...
• EVM: 0x2d1ce29b..., 0x0b2b16e1..., 0xe69f6d77...

Root Cause Analysis

The root cause was not oracle infrastructure failure. Reflector reported accurate prices for the data it observed. The failure was a configuration decision made at the pool operator level: routing collateral pricing through a market with no liquidity floor, no depth requirements, and no manipulation resistance.

Three compounding factors made this exploitable:

1. Near-zero VWAP window volume. A single 0.05 USTRY trade dominated the entire price calculation.
2. No liquidity thresholds or sanity checks. The pool accepted oracle updates without validating underlying market depth or detecting price deviations beyond reasonable bounds.
3. No circuit breakers. A 100x price spike in a single update period triggered no alerts, no pauses, no fallback pricing.

This is the canonical thin-liquidity oracle attack pattern. It has appeared before. It will appear again.

Olympix Findings: What BugPocer Caught

We ran BugPocer, Olympix's internal auditor, against the Blend V2 source. Locating the repo required some additional work since Stellar explorers only expose compiled WASM bytecode. Once we had the source, BugPocer's results were unambiguous.

Direct Match — High Severity (Verified True Positive, PoC Confirmed):

Oracle Price Manipulation — bad_debt_auction.rs, line 136

External price and oracle data are trusted without validation. pool.load_price can be manipulated via low liquidity or stale data. Recommendation: implement TWAP or staleness checks and oracle confidence bounds.

This finding maps precisely to the exploit mechanism. The oracle call was the single point of trust, and that trust was unguarded.

Supporting Findings:

• Health check not enforced (actions.rs): The borrow and withdraw execution path does not internally enforce health factor validation. This is the mechanism that allowed the attacker to borrow against inflated collateral without triggering a revert.
• Hard-coded LP valuation heuristic (bad_debt_auction.rs): A * 5 multiplier for 80/20 USDC/BLND pool valuation is brittle and exploitable under price divergence conditions. This is a secondary manipulation surface in auction scenarios.
• Auction timing without bounds: Auction modifier logic depends solely on block difference with no upper bounds, creating additional manipulation exposure in adversarial conditions.

These findings were present in the codebase before the exploit occurred. BugPocer surfaced all of them in post-incident analysis. Had it been running in CI, it would have flagged them before a single dollar was at risk.

Recommendations

1. Replace or layer VWAP with TWAP and staleness validation. VWAP oracles are inherently manipulable in thin markets because a single high-volume trade dominates the average. TWAP (time-weighted average price) oracles spread weight over time rather than volume, making single-trade manipulation significantly more expensive. At minimum, VWAP-based oracles should be paired with staleness thresholds and cross-source validation.

2. Enforce liquidity floor requirements before accepting oracle updates. Price feeds sourced from on-chain DEX markets should validate minimum liquidity depth and minimum trade count before treating a price update as valid. A market with sub-$1 hourly volume should not be eligible as a collateral pricing source under any configuration.

3. Implement circuit breakers for price deviation. A 100x price move in a single oracle update window is not normal. Protocols should define acceptable price deviation bounds and automatically pause collateral operations when those bounds are breached, pending human review or multi-source confirmation.

4. Enforce health factor checks in execution paths, not just at entry. The finding in actions.rs points to a structural gap: borrow and withdraw paths that do not re-verify health factors internally can be exploited whenever upstream inputs (like oracle prices) are compromised. Health factor validation belongs in the execution layer, not just the entry layer.

5. Shift security left: catch vulnerabilities before deployment, not after. This attack was detectable. The oracle manipulation finding was a verified true positive with a working PoC. A system capable of catching it before deployment would have prevented the loss entirely.

Closing: Security Has to Be Continuous

The YieldBlox exploit cost $10.2M. It was not caused by an obscure zero-day or a novel attack vector. It was caused by a known class of vulnerability, thin-liquidity oracle manipulation, that static analysis tools can and do flag.

The audit-only model does not cover this gap. A point-in-time audit reviews code as it exists at one moment. Protocols evolve. Configurations change. Market conditions shift. The market maker that provided USTRY/USDC liquidity withdrew before the attack, a runtime condition no static audit could anticipate, but one that continuous monitoring can detect.

Security has to live inside the development lifecycle: in CI pipelines, in pre-deployment gates, in ongoing monitoring. Not just in a PDF delivered six weeks before launch.

Olympix: Your Partner in Secure Smart Contracts

Olympix provides advanced Solidity analysis tools to help developers identify and fix vulnerabilities before they become critical exploits.

Get started today to fortify your smart contracts and proactively shield them from exploits in the evolving Web3 security landscape.

Connect with us on:

Twitter | LinkedIn | Discord | Medium | Instagram | Telegram | Newsletter