How a Dead Market Let an Attacker Drain $10.97M From YieldBlox's Blend V2 Pool
YieldBlox's community-managed pool on Blend V2 lost $10.97 million to an attacker who needed no smart-contract exploit at all — just a single trade in the USTRY/USDC market, a pair that was averaging less than a dollar of trading volume per hour.
There was no novel bug and no contract-level trickery involved. The liquidity was simply drained through old-fashioned price manipulation. Someone identified a collateral asset so illiquid that fewer than five tokens sat on the ask side of its order book, then inflated its price 100-fold with one transaction.

From there, each system component simply did its job: the Reflector oracle reported the new, inflated price, Blend V2 accepted that valuation for the collateral, and the attacker borrowed $10.97 million worth of XLM and USDC against it before walking away.
YieldBlox has operated on Stellar since 2022, built by the team Script3, which runs a community-managed pool on Blend V2.
Among the assets approved as collateral was USTRY, a yield-bearing US Treasury stablebond issued by Etherfuse. The attacker deposited roughly 153,000 USTRY across two rounds — worth about $160,000 at actual market prices — then borrowed against it as if it were valued at $16 million. The USTRY itself was never taken; it functioned only as the key. The XLM and USDC sitting in the pool were the actual target.
Nothing in the system had ever established a minimum standard for the market conditions a piece of collateral needed to meet before its price could be trusted.
In response, Tier 1 Validators moved to freeze roughly 48 million XLM — about 80% of the stolen native token — while the Security Council issued an on-chain bounty offer. The attacker kept moving funds regardless.
Given that the USTRY/USDC market on the SDEX was running under a dollar of hourly volume while YieldBlox's oracle treated its spot price as reliable, the accountability question is less about who broke in and more about who signed off on trusting that market in the first place.
Credit: DK27ss, Defimon Alerts, PR Newswire, QuillAudits, Script3, Reflector, saariuslystoned, Code4rena, Certora
01Two Transactions, Two Blocks, $10.97 Million
At 00:25 UTC on February 22, 2026, two transactions struck the YieldBlox DAO Pool on Blend V2. The first drew out 1,000,196 USDC; the second pulled 61,249,278 XLM. Together, that's $10.97 million removed in roughly the time needed to confirm two blocks.
On-chain monitoring services flagged the movement almost immediately — DefimonAlerts published the attacker's addresses and related transaction links while the funds were still in motion.
Script3, the team behind both YieldBlox and Blend, was the first to issue a named response:
"At 00:25:00 UTC the Reflector USTRY oracle was manipulated, misreporting a significantly higher price. This resulted in a loss of ~10 million USD in a mixture of USDC and XLM from the Blend YieldBlox pool. NO OTHER BLEND POOLS WERE AFFECTED. NO OTHER POOLS ARE VULNERABLE."
The statement was brief and specific, particularly about limiting the scope of the damage to a single pool.
Reflector, the oracle provider, issued its own thread afterward, waiting until most of the stolen assets had already been frozen before commenting. Its position was carefully worded: the oracle infrastructure had not been compromised, it had simply reported the price the SDEX was actually displaying, and the underlying cause was a market too illiquid to be priced accurately at all.
As Reflector put it: "it's impossible to quote adequate prices for a market fully handled by a single market-maker with almost zero trading activity."
In other words, the oracle behaved exactly as the market instructed it to — the unresolved issue is whether that market should have been relied upon in the first place.
Script3 provided further clarification on February 23, stating the incident was confined to one asset in one community-managed pool and that Blend's contracts themselves contained no vulnerability. A subsequent announcement committed to fully reimbursing all depositors — across USDC, XLM, and EURC — for losses tied to the resulting bad debt.
Separately, a proof-of-concept detailing the exploit's full mechanics — complete with on-chain evidence, the poisoned oracle entries, and health factor math — was published on GitHub by DK27ss, laying out exactly how the attack had been engineered.
YieldBloxDAO's own X account offered only a repost of Script3's compensation announcement — no independent statement, no explanation of the incident.
Two organizations tied to a single exploit produced two distinct accounts of where responsibility lay: the oracle team said it reported accurately, the protocol team said it had been manipulated — leaving open the question of which party actually held the ability to have prevented the loss.
02How a Single Trade Broke Four Layers of Defense
USTRY was designed to be low-risk collateral: a yield-bearing stablebond backed by US Treasuries, intended to trade around $1.06 — an unremarkable asset, the sort that typically belongs in a lending pool.
What was actually risky was the market it traded in. The USTRY/USDC pair on the SDEX saw less than $1 in hourly volume, and fewer than five USTRY tokens were available on the sell side of the book. There was effectively no depth and a single active market maker — nothing else trading to anchor the price. For at least ten minutes prior to the attack, there were zero recorded trades — this wasn't merely thin liquidity, it was an inactive market still carrying a live price feed.
Reflector's oracle relies on a VWAP methodology — volume-weighted average price — sourced directly from SDEX activity. That approach holds up fine in a liquid market, where any single manipulated trade gets diluted by the surrounding volume. But in an illiquid one, a single oversized trade can dominate the calculation entirely, and when there's no other activity at all, that one trade simply becomes the VWAP.
That's what happened here: the attacker posted a sell order at 100 times the genuine price and traded against it themselves, moving USTRY's reported value from roughly $1.06 to about $106.74 in a single transaction, with nothing else in the sampling window to offset it.
The published PoC's decoded on-chain data captured the sequence as it unfolded: four separate price readings came back for USTRY — two marked by the researcher as SDEX-poisoned at $106.74, and two normal readings at $1.06.
The failure compounded from there. The Oracle Adapter — the contract bridging Reflector and Blend — applied no median calculation and flagged no deviation; it simply forwarded the most recent price, passing the full 100x distortion straight into the pool. Blend V2's health factor check then performed its intended function, confirming that collateral value exceeded the liability before allowing the borrow.
Using the $106.74 USTRY price, the pool calculated the attacker's collateral position at $1.37 million — versus an actual value of roughly $13,654, which still produced a health factor of 1.35, clearing the borrow.
The attacker then repeated the maneuver, adding another 140,000 USTRY as collateral. Under the same poisoned price feed, total collateral was valued at roughly $15.99 million, versus an actual value of about $158,500 and a health factor of 1.47. On that basis, the pool released 61,249,278 XLM without objection.
No circuit breaker activated, no price-deviation check triggered, and no staleness warning fired despite the market having gone quiet for ten straight minutes. The system had no way to tell the difference between a price that was genuinely accurate and one that only appeared accurate because no one had traded recently enough to correct it.
Four separate failure points had to line up for this to work: an illiquid asset approved as collateral, a single-source VWAP oracle, an adapter that forwarded raw prices without sanity checks, and a protocol lacking any anomaly detection. Take away any one of the four and the exploit fails — yet all four coexisted without anyone testing whether they could fail in combination.
This was not a smart-contract bug, a flash loan attack, or a bridge compromise — just a stablebond with no real market, an oracle without safeguards, and a lending pool that trusted both without question.
03Following the Money On-Chain
Every wallet, transaction, and token in this exploit is traceable — the attacker's own on-chain footprint tells most of the story.
Preparation began eight days before the borrow itself. The attacker's primary Stellar wallet was set up on February 14 with a 56.32 XLM seed balance, followed by several days of low-key reconnaissance — small USTRY purchases at normal prices near $1.058 to study the market before manipulating it.
The manipulation itself ran through a separate, purpose-built burner wallet, created on February 21 at 23:35 UTC with a 15 XLM balance:
SDEX Manipulation Burner: GCNF5GNRIT6VWYZ7LXUZ33Q3SR2NUGO32F5X65VVKAEWWIQCKGYN75HB
At 23:38 UTC, this account placed a sell order for 1.2185 USTRY priced at 107 USDC — roughly 100 times the real market rate, recorded in this offer transaction: 09e1a9d1197c9bf0af4e87da328c4f2d5eb49b487630aa61991fb5c1c4637cdb.
An open offer alone wouldn't move the oracle — a trade needed to actually settle against it. A third wallet under the attacker's control handled that step:
Price-Setting Trade Trigger: GDHRCQNC64UVL27EXSC6OG6I2FCT4NWM72KNHLHKEB3LK4MEEYYWETN3
At 00:10:21 UTC on February 22, this wallet bought 0.05 USTRY against the burner's inflated offer. That roughly 50-cent trade became the price Reflector's oracle ingested at both 00:15 and 00:20 UTC, recorded in this price-setting transaction: 60fe039e96e88402d175c8de68e80651874ab125880dd384a1636914ba95bef1.
With the price feed poisoned across two consecutive reporting windows, the borrow went through at 00:24:27 UTC across two transactions:
USDC Borrow (1,000,196 USDC): ae721cacee382bdecac8d2c47286ecd42cb4711f658bb2aec7cba60dc64a31ff
XLM Borrow (61,249,278 XLM): 3e81a3f7b6e17cc22d0a1f33e9dcf90e5664b125b9e61f108b8d2f082f2d4657
From there, the stolen assets were converted to USDC and bridged off Stellar to Base via Allbridge, then moved again from Base to Ethereum using Across and Relay. The proceeds ultimately surfaced across Ethereum, Base, and BNB Chain in wallets tied to the attacker, while roughly 48 million XLM was frozen across the attacker's Stellar accounts by Tier 1 Validators before it could be moved further.
On the EVM side, three wallets received the bridged funds, each flagged by Etherscan:
YieldBlox Exploiter 1: 0xE69f6d77DB6Ff493FDD15D8A0B390c36E18E5b21 — holding 363.98 ETH plus 12.78 ETH on Base (roughly $729K combined). This wallet was funded from a Binance hot wallet, suggesting either a KYC'd withdrawal or a Binance-routed bridge conversion — a potentially traceable link.
YieldBlox Exploiter 2: 0x2D1CE29b4aF15fb6E76Ba9995BbE1421E8546482 — holding 357.28 ETH on Ethereum, 19.23 ETH on Base, and 38,746 USDC left untouched on BSC (roughly $769K). This wallet was funded via the Allbridge Core Bridge.
YieldBlox Exploiter 3: 0x0b2B16E1a9E2e9b15027AE46Fa5eC547f5ef3eC6 — holding roughly 300 ETH on Ethereum (about $583K), a child wallet funded directly by Exploiter 2.
On February 27, Exploiter 2 moved 100 ETH to 0xFC51b5cD07E73020bE902A5b00902f329b083eaB, which then forwarded the funds to Tornado Cash in this transaction.
Earlier, between 09:17 and 09:26 UTC on February 23, 23 separate transactions moved roughly 380 ETH from Base back to Exploiter 2 on Ethereum mainnet, split across two bridge protocols run in parallel — twelve Relay settlements of about 19.99 ETH each, and ten Across Protocol transfers ranging from 10 to 50 ETH, all executed in consecutive blocks with uniform batch sizes. The pattern reads as consolidation, not evasion by scattering.
That activity took place roughly 12 hours after the Security Council issued its 72-hour white-hat bounty ultimatum — the attacker's reply, in effect, was to keep moving funds.
Tracing the gas funding on the EVM side points toward the operators behind the wallets: several addresses across both vanity-address clusters were funded by wallets Etherscan has already flagged for phishing.
Most active gas supplier (labeled Fake_Phishing1701177): 0xd7e42d9502fbd66d90750e544e05c2b3ca7cbd22 — this address supplied gas three separate times across both exploit wallet clusters, with three additional flagged phishing addresses rounding out the funding network. This points to an organized operation rather than a single individual.
The Security Council subsequently sent on-chain negotiation messages simultaneously to all three EVM wallets, delivered from a Coinbase-funded messenger address:

Security Council Messenger: 0x456c2F5F3536b1D9238F4654D5242B0dF8f978AF
Bounty Message TX (to Exploiter 1): 0x7979c9faa2eba7afa29702382205930f77a461174d4eeeb3382e22bb7177171e
The message read: "If you return 90% of the stolen funds within 72 hours, we will stop pursuing legal action. Your 3 Stellar accounts have been frozen by the Tier 1 Validators. If you contact us, we can provide instructions on how to return the 48M XLM those accounts hold on the Stellar network so it is included in the 90%."
The attacker never replied, and no funds were returned. Twelve hours later, another consolidation batch went through on Relay.
A week of setup, three bridge protocols in use, and a phishing-linked gas network — none of it required finding a single flaw in the code. That raises the question of what, exactly, prior security reviews had been checking for.
04The Audits That Missed the Real Risk
Blend V2 was far from unaudited — if anything, it had an unusually thorough security history.
Exactly one year before the exploit, in February 2025, Blend V2 ran a $125,000 Code4rena contest paired with Certora Formal Verification — described at the time as a landmark event: the first Rust/Soroban formal verification contest in DeFi's history. The contest centered on the Backstop contract, given its role in maintaining protocol solvency, and drew 21 participating security researchers who collectively authored close to a thousand verification rules. A follow-up $20,000 mitigation review ran that April — a substantial cumulative security spend.
What that spend actually covered was pool logic, backstop mechanics, fee vaults, auction systems, and flash loan endpoints. The contest's central invariant was stated plainly: "Users cannot extract funds from a pool if they do not meet or exceed the minimum health factor." Researcher attention was steered toward auctions and flash loans — the oracle itself, Reflector's integration, and the possibility of an approved collateral asset lacking a functioning market were never part of the scope. Similarly, Certora's formal verification work was narrowly focused on the Backstop contract's solvency guarantees — rigorous and provably correct, but only for the code it actually examined.
The health factor logic the attacker bypassed had, in fact, performed exactly as verified: it compared the oracle-reported price against the liability, the oracle said $106.74, the health factor check passed, the mathematical proof held — and the pool was drained anyway.
This mirrors the failure pattern seen at Makina Finance a month earlier, where six separate audits confirmed the contracts behaved as written, yet the exploit occurred in the gap between the verified code and the external data it relied on. At Makina, that gap was a permissionless AUM update function pulling spot prices from Curve pools that could be manipulated. At YieldBlox, the equivalent gap was a VWAP oracle drawing from a market that had, in practice, stopped functioning. In both cases, the audits were technically accurate — the code ran as intended — but neither one questioned whether the data feeding that code could be trusted.
Script3 has confirmed that all EURC, USDC, and XLM depositors in the affected pool will be made whole for losses stemming from the bad debt. Reflector has stated its infrastructure was never compromised and that assets with genuine liquidity and multiple active traders remain unaffected; the incident was contained to the single community-managed pool, and no other Blend pools were impacted or at risk.
QuillAudits summarized the missing safeguards this way: "This incident highlights the critical importance of liquidity thresholds, market depth validation, and circuit breakers when relying on on-chain DEX pricing. Even mathematically sound oracle systems can fail if underlying market conditions are economically unsound. Robust oracle design must account not just for price accuracy, but for market quality and resilience."
A $125,000 formal verification contest, the first of its kind for a Rust codebase, still couldn't catch a vulnerability rooted in a market condition that simply didn't exist at the time the audit was signed off.
05Closing Note
No lock was picked here — the attacker simply walked through an entry point the audits never examined. The oracle relayed what the market showed it; the adapter passed along the price it received; the pool released $10.97 million. Every individual component functioned as designed, and the pool was still emptied — which is less a bug than evidence that the system was never built to question whether the data source itself deserved trust.
Script3 has committed to compensating depositors, and Stellar's validator set managed to freeze most of the stolen XLM before it left the network. Even so, the attacker still holds millions across EVM wallets — one with a traceable Binance KYC link — all documented in a public forensic dashboard tracking every move made so far. The remediation is real; the accountability, so far, is only partial.
The underlying lesson — that a lending protocol is only as secure as the weakest market it accepts as collateral — isn't a new one. It has already cost the industry eight-figure sums across a string of protocols before YieldBlox. DeFi continues to build faster than it absorbs these lessons: audits scope the contracts, but nobody scopes the real-world conditions those contracts depend on.
Formal verification on a protocol is little protection if it can still be drained by one trade in a market trading less than a dollar a day — which leaves an open question about what exactly that security spend was meant to guarantee.
Get new scam files the moment we publish them — usually 2–3 emails a week.