News
The YieldBlox Exploit — How a Dead Order Book Led to a $10M Drain
Feb 25, 2026
On February 23, an attacker placed a trade on a nearly empty order book, which inflated a token's reported price by 100x, and used that fabricated valuation to borrow approximately $10 million in real assets from a lending pool on the Stellar blockchain. Critically, the lending pool's smart contracts were not exploited.
What failed was price integrity; the system couldn’t distinguish a real price from a manufactured one.
Here’s how it worked, why it keeps happening, and what it takes to prevent it.
Four Components, One Dependency Chain
The exploit involved four components. Understanding how they connect is key to understanding why the attack worked.
If any link in that chain can be manipulated, the system risks being compromised.
Stellar and SDEX: Stellar has a native onchain orderbook exchange, the SDEX. This is where USTRY, the token at the center of this exploit, was priced.
USTRY: USTRY is a stablebond issued by Etherfuse, backed by U.S. Treasury debt. In normal conditions, it should trade around $1.05. The bond itself is a low-volatility asset but the market it traded on was the weak link. USTRY traded on SDEX with almost no activity, less than $1 per hour in volume.
Reflector (the Oracle): Reflector is Stellar's primary oracle provider, operated as a network of nodes run by ecosystem organizations. These nodes observe trading activity on SDEX, then aggregate and publish price feeds. The critical question for any oracle is how it filters raw trading data into a reliable price. An oracle that just reports the last trade price is trivial to manipulate on thin markets — time-weighted averaging, deviation bounds, or minimum volume thresholds make it significantly harder to manipulate.
Blend V2 and YieldBlox (the Lending Pool): Blend is a permissionless lending protocol on Stellar’s Soroban contracts. YieldBlox is a DAO-managed pool on Blend that accepts USTRY as collateral and uses Reflector for pricing.
How this works normally:
A borrower deposits USTRY tokens into the pool as collateral.
The pool asks Reflector: "What is USTRY worth?"
Reflector checks recent SDEX trades and responds with a price.
The pool multiplies deposited tokens by the oracle price to calculate collateral value.
The pool applies a loan-to-value ratio to determine borrowing limits.
The pool continuously monitors the health factor.
Every calculation downstream (collateral value, borrowing limits, health factor, liquidation triggers) is derived from the oracle. If the price is wrong, every safety mechanism built on top of it is meaningless.
The Attack
Step 1: Find a market that is cheap to manipulate
The attacker surveyed SDEX for collateral assets accepted by lending pools where the cost of moving the price was low relative to the borrowable value in the pool.
USTRY was the ideal target. The YieldBlox pool held millions of dollars in borrowable assets (XLM and USDC), but USTRY's market had no depth. Spending a small amount to move the price, then extracting millions, is entirely feasible.
This cost-benefit calculation is the first thing a sophisticated attacker evaluates.
Step 2: Spike the price 100x with one trade
The attacker placed a single trade on SDEX that moved USTRY from approximately $1.05 to over $106, roughly a 100x increase.
On a functioning market, this would require overwhelming capital. If the order book had even modest depth (say $100,000 of sell orders between $1.05 and $2.00), the attacker would need to buy through all of those orders before pushing the price higher. With depth, manipulation is expensive.
On USTRY's empty book, there were essentially no sell orders to absorb.
Step 3: Oracle ingests the manipulated price
Reflector observed the SDEX trade and updated its USTRY price feed to approximately $106.
Now the same amount of USTRY collateral could secure a far larger loan.
Step 4: Borrow real assets against fake collateral value
With the inflated health factor, the attacker borrowed approximately 61 million XLM and 1 million USDC, roughly $10 million in total.
The lending pool’s smart contracts executed these loans correctly, and that’s the point. The system couldn’t distinguish real collateral value from a fabricated one.
Post-borrow, the attacker moved quickly to disperse the stolen assets. Approximately 901,000 USDC was bridged from Stellar to Ethereum. XLM was split across multiple wallets.
Post-Mortem
The response was fast and effective. 48 million XLM (around $7.5 million at the time) was frozen in wallets associated with the attacker. The exact mechanism, whether through Stellar’s native asset-freezing capabilities, contract-level pauses, or exchange coordination, has not been publicly detailed.
YieldBlox's Security Council then sent a message to the attacker's Ethereum address offering a 10% bounty for returning the remaining funds. Reflector stated that it quoted correct prices, meaning it accurately reported what the SDEX market showed.
Why This Keeps Happening
The YieldBlox exploit is an example of oracle price manipulation on thin-liquidity markets.
Every lending protocol needs an accurate price for each collateral asset to enforce solvency. So the issue appears wherever the cost of manipulating that price is lower than the value that can be extracted.
If (cost to manipulate) < (value extractable) → the protocol is exploitable.
There are two ways to close this gap: make manipulation expensive, or limit the extractable value.
In this case, the USTRY market had near-zero liquidity, meaning the cost to move the price could have been as low as a few thousand dollars, against approximately $10 million in extractable value.
The historical pattern
This pattern has produced some of the largest losses in DeFi.
In October 2022, Mango Markets lost $117 million to an attacker who split $10 million across two accounts, used coordinated self-trading to inflate the MNGO governance token's price, and then borrowed against the inflated collateral. The mechanics were nearly identical to YieldBlox: thin market, manufactured price, massive borrow.
In fact, oracle manipulation was the second most critical attack vector in 2024. In early 2025, over 31% of DeFi losses were attributed to oracle-based attacks.
How could code audits miss this vulnerability?
Standard smart contract audits are scoped to catch code-level flaws — arithmetic errors, reentrancy, access control misconfigurations. Some audits also flag oracle-related risks at the code level, like missing staleness checks or reliance on spot prices. But this exploit didn't come from a bug in the code or a missing check. The lending pool's contracts executed exactly as designed.
The vulnerability lives in the relationship between the code, the oracle, and the market the oracle reads from. The code treats the oracle as a trusted input and builds every safety mechanism on top of it, but never validates whether that price reflects economic reality.
Catching this requires asking questions like: how deep is the order book for this collateral asset? What’s the capital required to move the price 100x? Is the pool’s total borrowable value proportional to the cost of manipulating its collateral prices? These aren’t questions a code audit is necessarily scoped to answer, but they’re exactly what an attacker evaluates before deciding whether a pool is worth hitting.
What It Takes To Catch This
Answering those questions requires modeling the economic environment a protocol operates in and simulating real attack paths against it.
This is the approach we’re taking at Shepherd. We run attack simulations against forked environments, assess market depth for every collateral asset, and estimate the actual cost of manipulation, so protocols can identify exposure before it becomes an exploit.
Shepherd tests assumptions before someone else does.