AnswersPublished22 sources
How a Two-Minute Pragma Oracle Error Triggered $3M in Vesu Liquidations
Between 04:08 and 04:10 UTC on Sept. 4, 2026, an incorrect upstream Pragma price feed made 47 Vesu borrowing positions appear liquidatable, leading to about $3 million in collateral being irregularly liquidated.
Published byEdited with GPT-5.6 TerraImages generated with GPT Image 2
Research answer
Key takeaways
- Between 04:08 and 04:10 UTC on Sept. 4, 2026, an incorrect upstream Pragma price feed made 47 Vesu borrowing positions appear liquidatable, leading to about $3 million in collateral being irregularly liquidated.
- Pragma and relevant parties deployed a root cause fix, while affected pools were paused pending curator action.
- The episode echoes Aave’s March 2026 oracle misalignment and Switchboard’s later precautionary halt on four Move based networks: deterministic smart contracts still depend on reliable external data.
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: How did a faulty Pragma price feed cause the liquidation of 47 Vesu borrowing positions on Starknet between 04:08 and 04:10 UTC on Sept. 4,. Article summary: The Vesu event was an oracle-input failure, not a smart-contract exploit: for roughly two minutes, Vesu’s liquidation logic received incorrect prices from an upstream Pragma feed and therefore treated 47 otherwise-valid . Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fak
A two-minute price-data failure was enough to trigger roughly $3 million in abnormal liquidations on Starknet lending protocol Vesu. On Sept. 4, 2026, a faulty upstream Pragma feed supplied incorrect prices from 04:08 to 04:10 UTC, causing 47 borrowing positions across several Vesu pools to appear eligible for liquidation. 32
The important distinction is that Vesu describes this as an oracle-input failure, not a vulnerability in its smart contracts. The liquidation engine followed the rules it had been given—but the price premise behind those rules was wrong. 32
What happened during the two-minute window
DeFi lending markets continuously compare the reported value of a borrower’s collateral with the value of their debt. When the position falls below the protocol’s required threshold, a liquidator can invoke the liquidation mechanism and take collateral according to the market’s rules.
In Vesu’s case, the faulty Pragma prices made 47 positions look undercollateralized even though the issue was not attributed to a flaw in Vesu’s contracts. Automated liquidations then removed approximately $3 million in collateral before the feed corrected itself. 20
32
That is why “the contracts worked as designed” is not the same as “the outcome was economically correct.” Smart contracts can verify and execute on the data made available to them; they cannot inherently tell whether an oracle’s reported price reflects the market.
Why an oracle error can liquidate healthy borrowers
A lending protocol’s liquidation logic is deliberately mechanical. It needs to act quickly when collateral genuinely falls in value, otherwise lenders can be exposed to bad debt. But that same automation means an erroneous price can cross a liquidation threshold just as effectively as a real market move.
The sequence is straightforward:
- An oracle posts a price used by the lending market.
- The protocol recalculates collateral and debt health using that price.
- A position appears to breach its required collateral threshold.
- Liquidators execute the protocol’s ordinary liquidation path.
The Vesu incident occurred because step one was wrong, not because the liquidation path was bypassed or exploited. Vesu said no protocol-side contract fix was required. 32
Vesu’s recovery effort, pauses, and guidance
Vesu said Pragma, working with relevant parties, had deployed a fix for the underlying cause and that the price feed had corrected within the two-minute incident window. It expected pool curators to unpause affected pools after the mitigation. 32
The protocol also said it was working with Pragma, StarkWare, the Starknet Foundation, and pool curators to seek recovery of funds for affected users. That is an effort to recover funds, not a confirmed statement that every affected user had already been repaid. 24
32
For affected users, reports of Vesu’s guidance said to:
- keep Earn positions open, as withdrawing could affect eligibility in a recovery process; and
- submit a support ticket through Vesu’s Discord if a position was liquidated in the incident.
27
34
Pool status can change as curators lift or maintain precautions, so users should rely on Vesu’s current official incident and support communications rather than assume that all markets were affected or that every pool has the same status.
What is known—and not known—about the fix
Public disclosures established several key facts: the source was an upstream Pragma price feed, the fault lasted about two minutes, the feed self-corrected, and a root-cause fix was deployed in collaboration with relevant parties. 23
32
They did not establish the full technical mechanism behind the bad values or a final compensation framework. Vesu indicated that a full technical report would follow. Until that report is available, claims about the exact software defect, fault attribution beyond the disclosed upstream feed issue, or final recovery outcome should be treated as unconfirmed. 27
The broader DeFi lesson: correct code still needs correct data
Vesu is a clear example of the oracle problem: decentralized applications may be transparent and deterministic onchain, yet their financial decisions depend on facts supplied from outside the contract—especially asset prices.
Two recent incidents illustrate related, but distinct, forms of that risk.
Aave’s March 2026 wstETH oracle misalignment
On March 10, a CAPO risk-oracle incident on Aave’s Ethereum Core and Prime markets depressed the effective wstETH/stETH exchange rate by about 2.85%. The resulting incorrect valuation triggered roughly $26.6 million in liquidation volume. Aave’s post-mortem attributed the issue to an inconsistency between a snapshot ratio and snapshot timestamp, rather than a broad market collapse. 10
11
Like Vesu, the key failure was not that the liquidation rules stopped working. It was that the system applied those rules to an incorrect valuation.
Switchboard’s suspected Move-environment compromise
In a separate and more severe category of oracle risk, Switchboard halted oracle operations on Aptos, Sui, IOTA, and Movement after reports of a potential security compromise affecting its Move-based deployments. The halt was precautionary and did not stop the affected chains from producing blocks. 3
4
Reports linked the event to manipulated IOTA price data, abnormal VUSD minting, and liquidations, but the incident should remain characterized as a suspected compromise unless and until a definitive investigation establishes the cause and scope. 2
5
What stronger oracle safeguards look like
No single safeguard guarantees that a lending market will reject every bad input. The practical aim is to reduce the chance that a brief abnormal price can immediately create irreversible harm. Common approaches include:
- using independent price sources rather than relying on one input path;
- applying deviation limits that reject or pause unusually large price moves;
- enforcing staleness checks so outdated data cannot be treated as current;
- adding circuit breakers and pool-level emergency pauses;
- delaying or reviewing high-impact oracle configuration changes; and
- setting conservative collateral parameters for volatile or complex assets.
The trade-off is unavoidable: tighter safeguards can slow down valid responses to real market moves, while looser safeguards can make automated liquidations more responsive to incorrect data. Vesu’s two-minute incident demonstrates why that balance is central to DeFi risk design.
For borrowers, the practical takeaway is that liquidation risk is not limited to market volatility or contract exploits. It also includes the integrity, configuration, and operational resilience of the oracle systems that determine a position’s onchain health.
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "How a Two-Minute Pragma Oracle Error Triggered $3M in Vesu Liquidations"?
Between 04:08 and 04:10 UTC on Sept. 4, 2026, an incorrect upstream Pragma price feed made 47 Vesu borrowing positions appear liquidatable, leading to about $3 million in collateral being irregularly liquidated.
What are the key points to validate first?
Between 04:08 and 04:10 UTC on Sept. 4, 2026, an incorrect upstream Pragma price feed made 47 Vesu borrowing positions appear liquidatable, leading to about $3 million in collateral being irregularly liquidated. Pragma and relevant parties deployed a root cause fix, while affected pools were paused pending curator action.
What should I do next in practice?
The episode echoes Aave’s March 2026 oracle misalignment and Switchboard’s later precautionary halt on four Move based networks: deterministic smart contracts still depend on reliable external data.