Vesu Oracle Incident Wipes Out $3M in Starknet Liquidations

12h ago•

bullish:

bearish:

A two-minute glitch in a price feed was enough to trigger millions of dollars in unwanted liquidations on Starknet. Vesu, a lending protocol built on the network, disclosed on Sept. 5 that the Vesu oracle incident stemmed from faulty data supplied by Pragma, an upstream price provider, and that the error wiped out 47 borrowing positions holding $3 million in collateral on Sept. 4. The episode is now forcing a familiar question in decentralized finance: how much should a lending market trust a single external data source?

Key takeaways

A faulty Pragma price feed caused Vesu to liquidate 47 positions worth $3 million in collateral on Sept. 4, between 04:08 and 04:10 UTC.
The bad data lasted roughly two minutes before Pragma’s feed corrected itself and resumed normal operation.
Vesu says its smart contracts had no vulnerability — the liquidation engine simply executed correctly on incorrect price inputs.
Pragma has deployed a fix, and pool curators suspended affected markets as a precaution while reviewing it.
Vesu, Pragma, StarkWare, the Starknet Foundation and pool curators are coordinating a recovery effort, but no reimbursement amount or timeline has been confirmed.

Faulty Pragma Price Feed Causes $3M Liquidations on Vesu

The trouble began in the early hours of Sept. 4, when an upstream feed operated by Pragma began reporting incorrect prices to several Vesu liquidity pools. In a Sept. 5 disclosure, Vesu wrote: “A faulty upstream Pragma price feed caused 47 positions and $3M of collateral to be irregularly liquidated across several Vesu pools between 04:08 and 04:10 UTC.” The protocol added that “the feed corrected itself within two minutes, and nothing has been…” — the statement was cut short in the original post, but the timeline it describes is clear.

Incident timeframe and scale

The window was brief but damaging. Automated liquidators, reacting to the bad data, moved fast enough to strip roughly $3 million in collateral from 47 positions before the feed snapped back to accurate values. Vesu confirmed that the source corrected itself within two minutes and has behaved normally since, though the company has not named the specific assets or pools hit, nor how far the faulty prices strayed from real market rates.

Impact on borrowing positions and collateral

Because the feed briefly reported distorted values, positions that were healthy under normal market conditions suddenly looked undercollateralized to the protocol’s liquidation engine. That triggered automatic liquidations that would not have happened under accurate pricing. Vesu has not disclosed how much debt was tied to the affected positions or how much of the seized collateral liquidators actually kept — details the company says will surface in a forthcoming technical report.

Vesu Contract Integrity and Oracle Dependency Explained

Vesu’s contracts worked exactly as intended — the problem was the information they were fed, not the code that processed it. This distinction matters for anyone trying to gauge whether the incident points to a deeper security flaw or simply a data-quality failure upstream.

No protocol vulnerability found in Vesu contracts

Vesu explicitly separated this event from a smart contract exploit, stating its contracts were “operating as designed” and contained no vulnerability. There was no patch to deploy on Vesu’s side because the liquidation engine had simply responded correctly to the prices it received — prices that happened to be wrong.

How oracle failures affect liquidation engines

In an overcollateralized lending market like Vesu’s, a borrower must deposit assets worth more than the loan itself. The protocol relies on an external price feed to track that collateral ratio continuously, and liquidation kicks in automatically once the ratio drops below a pool’s required threshold. When the price feed itself is wrong, even for a couple of minutes, the math behind that safety mechanism breaks down — and healthy loans can suddenly look unsafe.

Role of external price feeds in DeFi collateral assessment

This is why oracle dependence is one of the most persistent risk points across decentralized finance. Blockchain smart contracts cannot read off-chain market prices on their own; they depend entirely on outside oracle systems to source, aggregate and deliver that data on-chain. A failure at any single stage of that pipeline can pass a faulty number into an otherwise functioning contract, which then executes a liquidation or trade based on information that was never accurate to begin with. Why this matters: as more capital flows into DeFi lending, the reliability of the oracle layer becomes just as critical to user safety as the smart contract code itself.

Recovery Efforts and Precautionary Measures

Fixing the immediate technical problem was the easy part; recovering the collateral already taken is proving more complicated. Pragma has deployed a fix targeting the root cause of the price error, and the affected liquidity pools remain paused while curators review that fix before deciding to reopen.

Fix deployment by Pragma

According to Vesu, Pragma worked with the relevant organizations to address the source of the faulty feed once the incident was identified. Because Vesu runs isolated, curator-managed pools, the decision to lift suspensions ultimately sits with each pool’s curator rather than with Vesu itself — and the company has not named which curators paused their markets or given an exact timetable for restoring activity.

Suspension of liquidity pools by curators

Curators moved to suspend the affected pools as a precaution immediately after the anomaly surfaced, a standard defensive step meant to prevent further irregular activity while the underlying fix is verified. Vesu says it expects those restrictions to lift once the review confirms the fix is holding.

Collaboration among Vesu, Pragma, StarkWare, Starknet Foundation, and pool curators

Beyond the technical patch, Vesu started working together with Pragma, StarkWare, the Starknet Foundation and those managing the impacted pools to try to recover the funds collected through the abnormal liquidations. That’s a notable detail: it shows the incident escalated beyond a single protocol’s internal matter into a coordinated response involving core Starknet infrastructure players. Still, Vesu has not explained exactly how the recovery mechanism will work, how much of the $3 million might realistically be recouped, or whether the liquidators who profited from the event have agreed to return any assets.

User guidance for Earn product holders

For depositors in Vesu’s Earn product, the protocol issued a specific instruction: keep positions open. Closing an Earn position before the recovery process wraps up could strip a user of eligibility for a potential refund. Borrowers whose positions were liquidated during the two-minute window were told to open a support ticket through Vesu’s Discord server, though the protocol has not detailed exactly what records — beyond wallet addresses and transaction data — users need to submit.

Outstanding Questions and Future Disclosures

The biggest unanswered question is simple: will affected users actually get their money back, and when? Vesu’s statement stopped short of promising a specific reimbursement figure or payment date, leaving borrowers and Earn depositors in a holding pattern.

Uncertain reimbursement details

Because blockchain transactions are generally final once confirmed, Vesu’s response cannot simply reverse the liquidations. Any restitution would have to come from recovered assets, voluntary returns by the liquidators who benefited, protocol-controlled funds, or some other negotiated arrangement between the parties involved — and Vesu has not indicated which of those paths it intends to pursue.

Technical report forthcoming

Vesu has committed to publishing a full technical report once its investigation wraps up, which is expected to clarify which assets and pools were affected and lay out the sequence of on-chain transactions tied to the incident. That report should also shed light on details still missing from the initial disclosure, including the size of the price deviation and how much collateral liquidators ultimately retained.

User support process

In the meantime, affected borrowers are limited to Vesu’s own Discord-based support channel — there is no government-backed insurance covering losses in a permissionless DeFi product like this one, unlike deposits at FDIC-insured banks. Vesu has also not clarified whether its recovery process applies differently based on a user’s location or nationality.

This is not the first time an oracle hiccup has rattled a DeFi lender. A comparable episode hit Aave in March 2026, when a stale parameter triggered an estimated $26 million to $27 million in unintended wstETH liquidations, prompting that protocol to review its oracle update rates and fallback systems. Vesu has not yet announced similar structural changes to its own oracle setup — for now, Pragma’s fix to the root cause is the only confirmed technical measure. Vesu remains part of Starknet’s broader DeFi stack, having been named among the protocols supporting the network’s STRK20 privacy rollout in June 2026 alongside exchanges avnu and Ekubo and staking provider Endur — a reminder that oracle reliability isn’t just Vesu’s problem, but a shared dependency across the ecosystem it operates in.

FAQ

What caused the $3 million liquidation event on Vesu?

A faulty Pragma price feed supplied incorrect data that triggered abnormal liquidation of 47 positions holding $3 million in collateral.

Did Vesu’s smart contracts have any vulnerabilities during the incident?

No, Vesu’s contracts operated as designed, with liquidations triggered by incorrect price inputs rather than contract vulnerabilities.

How is the recovery process being managed?

Recovery involves coordination between Vesu, Pragma, StarkWare, the Starknet Foundation, and liquidity pool curators, but reimbursement amounts and timing remain unconfirmed.