YieldBlox Oracle Attack: Why Stellar Freeze Tools Matter

YieldBlox oracle attack was a price-feed failure, not a core-contract failure. On February 22, the community-managed YieldBlox pool on Blend V2 used a manipulable Reflector price path for USTRY, letting an attacker drain roughly $10.2 million by Halborn’s count; some secondary reports round the number to about $10.8 million.

The YieldBlox pool broke because one trade could define the oracle window

Halborn’s reconstruction says the attacker targeted the USTRY/USDC market on Stellar’s decentralized exchange at a moment when there had been no real trading in the prior 15 minutes because the pool’s only market maker had withdrawn liquidity. Reflector, the oracle used by the affected YieldBlox pool, was a volume-weighted average price feed for that pair, so one abnormal trade had outsized influence over the reported price. Halborn says the attacker posted an offer at 501 USDC per USTRY, then used a second account to buy 0.05 USTRY at roughly 106.7 USDC, pushing the oracle-marked USTRY price to about $106 from around $1.05.

BlockSec’s analysis lands on the same root cause and adds the pool-design angle. Blend V2 lets each isolated pool set its own collateral assets, borrow assets, and oracle settings. In this case, YieldBlox configured a Reflector path that sourced USTRY from a market thin enough to be moved by one hostile print. BlockSec is explicit that this was not a Blend V2 core-contract issue; it was a pool-operator configuration issue that accepted a manipulable market as valid collateral input. That distinction matters because it separates protocol-engine failure from market-parameter failure, even though users still lost money either way.

Once the manipulated price landed, the attacker’s existing USTRY collateral looked massively overcollateralized and unlocked borrowing power that did not reflect realizable market value. Halborn says the attacker borrowed 61.25 million XLM and 1 million USDC, effectively emptying the pool’s reserves. That is the central lesson of this exploit: lending protocols do not fail only when contracts miscompute. They also fail when they compute exactly what they were asked to compute using a market that should never have been trusted.

Halborn’s exploit reconstruction

Reflector appears to have worked as designed, which is the real problem

The most uncomfortable part of the post-mortem is that the oracle may have been technically correct. Halborn says Reflector “worked as designed,” quoting the price for the trading pair and window in question. Web3 Is Going Great separately summarizes Reflector’s position in similar terms: the oracle quoted correct prices for the selected market, but that market was too thin and too concentrated to produce an economically useful collateral signal. In other words, the data feed was mathematically faithful to a market that should not have been used for leverage.

That is why this incident should not be framed as a generic “oracle bug.” A volume-weighted average price feed is only as good as the market whose volume it is averaging. If a market has almost no depth, one trade can become the market. Halborn says minimum liquidity thresholds, volume requirements, circuit breakers, and multi-source aggregation could have prevented this specific exploit. Cryip’s follow-up report says the teams are now working on stronger oracle protections along those lines, including liquidity thresholds and multi-source price aggregation.

This puts the burden back on lenders and pool governors. “Decentralized oracle” is not a sufficient security property if the underlying market is economically unserious. Builders need a stricter question: can this price still be trusted after one hostile fill, one market maker exit, or one empty window? If the answer is no, then the feed is not safe collateral input, even if it is formally correct under its own methodology.

BlockSec’s incident analysis

Stellar Foundation account-control statement

Stellar’s validator quarantine changed the damage curve in a way Ethereum rarely can

Halborn says about $7.2 million of the stolen funds was frozen within the attacker’s accounts by Stellar Tier-1 validators. Public updates tied to Blend Capital say 48 million XLM was quarantined thanks to coordinated community response, and later updates say remediation for affected depositors was distributed. Protos reported the same 48 million XLM freeze at roughly $7.5 million on then-current pricing. That means the exploit’s gross extraction and its net escape value were not the same thing.

That response is unusual by DeFi standards because it was not just a protocol pause or a token-issuer blacklist. It was a validator-coordinated quarantine of native network assets. Public reporting confirms the outcome, but the exact mechanics of how validators implemented the quarantine have not been fully documented in the sources reviewed here. That gap matters. The fact of the freeze is clear; the detailed operating procedure is not.

Even with that caveat, the incident shows a different loss profile from what Ethereum users usually expect. On Ethereum, native ETH itself has no issuer with blacklist powers, and incident response generally happens through app-level pause rights, multisigs, centralized exchange alerts, or issuer controls over specific tokens such as USDC. In this case, the chain’s validator layer appears to have taken a more direct role in containing stolen XLM. That does not make Stellar “better” in the abstract. It means the chain offers a more interventionist incident-response envelope than many DeFi users assume when they hear the word decentralized.

The Stellar freeze story is not the same as a central admin freeze

That distinction matters because the Stellar Development Foundation itself says it does not control public usage of the network, does not control user accounts, and does not have the capability to freeze or return XLM held in a Stellar account. If that statement is taken at face value, then the YieldBlox response was not SDF pressing an admin button. It was an action by independent validators coordinating around identified attacker wallets.

That creates a different governance model from both Ethereum and from centrally issued stablecoins. With issuer-controlled stablecoins, freeze authority usually sits with the token issuer and is written into the token’s administration model. With Ethereum-native assets, there is normally no equivalent freeze function. With this Stellar incident, the practical stopgap came from validator coordination around the base asset. That makes the chain-level social layer part of the risk model in a way many EVM DeFi teams do not routinely price in.

There is a tradeoff here. Fast quarantine limited further loss and appears to have improved depositor recovery. It also demonstrates that, under pressure, a validator set can intervene against specific accounts or transactions. For regulated finance builders, that may look like a feature. For builders optimizing for censorship resistance, it is a meaningful architectural difference. YieldBlox turned that abstract debate into an operational one.

What Blend-style lenders and oracle designers should change now

The first fix is obvious: no isolated pool should be able to use a thin, single-venue market as sole collateral truth for leverage. Halborn and BlockSec both point back to the same control set: liquidity thresholds, volume floors, circuit breakers, and aggregation across more than one data source. Builders should add another requirement on top: if a market can go minutes without organic trades, it should not be accepted as primary collateral input at all.

The second fix is governance hygiene. Blend’s architecture gives pool creators real flexibility, which is useful for experimentation, but that flexibility pushes systemic risk into parameter selection. Pool-specific oracle choices, borrowable assets, and liquidation assumptions need stricter review than “the pool creator picked them.” A protocol can keep core contracts secure and still leave users exposed through market configuration. That is exactly what BlockSec says happened here.

The third fix is incident design. Halborn says the protocol offered a 10% bounty with a 72-hour deadline and the attacker ignored it. Blend-linked public updates indicate community remediation has since been distributed, but the exploit still left real lender damage and a live debate about what degree of validator intervention a chain should normalize. The next decision point is not whether YieldBlox was “hacked” in the generic sense. It is whether Stellar-native DeFi chooses to treat validator quarantine as an emergency exception or a standing part of its security model.

• Halborn — Explained: The YieldBlox Hack (February 2026) — https://www.halborn.com/blog/post/explained-the-yieldblox-hack-february-2026
• BlockSec — YieldBlox DAO Incident on Stellar: Oracle Misconfiguration Enabled a $10M+ Drain — https://blocksec.com/blog/yieldblox-dao-incident-on-stellar-oracle-misconfiguration-enabled-a-10m-drain