Asset recovery is complete. Curators handle refunds.
In its 13 September recovery update , Vesu reported 95% recovery at 11 September prices, or 93% at prices on the morning of the incident. Each pool curator holds its recovered funds and arranges refunds. This is an asset recovery milestone, not confirmation that all refunds are complete. Recovery figures and next steps ↓
The 4 September publisher hotfix removed the use of the oracle’s USDT/USD median as a conversion input for other feeds. On 13 September we deployed additional monitoring corrections and verified fresh deviation calculations in production.
A 3-of-4 multisig for contract administration is being coordinated. The ownership transfer has not happened. Publisher availability and independent-reference discrepancies still need operational follow-up.
What happened
On 4 September 2026, an incorrect price produced by Pragma’s publishing pipeline propagated into several Starknet price feeds. Vesu consumed those prices and liquidated positions that would not have been liquidatable at the correct market prices. Our reconstruction identified 47 liquidations affecting 42 borrower wallets across seven pools.
This was a failure in our pricing system. The affected users relied on data we provided, and we are sorry for the harm this caused. Publishing the incident mechanism, its impact, and the remaining work is part of taking responsibility.
The underlying markets did not fall by half. Multiple exchange observations were transformed by the same incorrect conversion factor inside the publisher software. Running that software through multiple publishers did not make those observations independent.
How the error propagated
1. A token mapping pointed to a stale conversion route
The publisher’s asset registry mapped USDC to legacy bridged USDC.e rather than native USDC. The Ekubo-derived price calculation consequently used a route through an inactive USDC.e pool. Its stale price relationship produced a USDT/USD observation of approximately $3.07.
This was a problem in how Pragma selected and used the route. It was not evidence that exchange USDT prices had actually risen to $3.07. Healthy observations normally outvoted the incorrect source.
2. Freshness filtering left only two observations
At 04:07:52 UTC, three healthy USDT/USD source observations were outside the oracle’s 60-minute freshness window. The remaining values were Bitstamp at approximately $0.99995 and the faulty Ekubo-derived value at $3.073203. With two observations, the median calculation returned their average: $2.036576.
($0.99995 + $3.073203) / 2 = $2.0365763. The publisher fed the aggregate back into other prices
The publisher SDK read that onchain USDT/USD result and divided USDT-quoted venue prices by it. Both active publishers ran the same software. BTC, WBTC, ETH, STRK and USDC observations were therefore divided by approximately 2.0366, making them appear to have lost about half their value.
Many affected feeds still contained numerous source observations. A source-count check alone could not detect that those sources had all been transformed by the same faulty input.
4. Derived assets updated at different times
wstETH/USD was derived from ETH/USD on a separate update cadence. Its fall and recovery lagged ETH. During one interval, wstETH collateral was valued at roughly half its correct price while ETH debt was valued at its recovered price. That mismatch increased the damage.
Vesu’s minimum-source check rejected the two-source USDT feed. It did not reject the populated BTC and ETH feeds carrying the correlated error. The reconstruction points to incorrect oracle inputs, rather than a defect in Vesu’s liquidation arithmetic.
Timeline
All times are UTC on 4 September 2026 unless stated otherwise.
- USDT/USD aggregate becomes incorrect
Freshness filtering leaves two observations. The resulting median is $2.036576.
- The conversion error spreads
Publishers use the incorrect factor in USDT-quoted prices. Several major asset feeds fall by approximately half.
- 47 liquidations
The reconstructed Vesu liquidation window affects 42 borrower wallets in seven pools.
- Reported medians normalize
The main liquidation window ends earlier; derived feeds recover on their own cadence.
- SDK 2.13.1 hotfix
The conversion factor used to construct other feeds is fixed at 1.00, removing the feedback path.
- Main recovery transfer confirmed
Funds returned by the principal liquidator reach the Vesu Security Council multisig. Curator distribution work follows.
- Vesu announces completion of asset recovery
Vesu publishes the recovery figures and recommended refund approach. Pool curators are responsible for distributions.
- Monitoring corrections deployed
Decimal normalization, reference collection, publishing-cadence health checks and reorg recovery are corrected and deployed.
Impact on users and pools
The initial reconstruction used pre-incident Pragma median prices to value the affected transactions. These are incident estimates, not a final recovery or compensation statement.
| Measure | Estimated value |
|---|---|
| Liquidated positions | 47 |
| Borrower wallets | 42 |
| Affected pools | 7 |
| Collateral seized | $3,077,500 |
| Debt repaid by liquidators | $1,674,711 |
| Borrower equity lost | $783,905 |
| Bad debt absorbed by pools | $618,884 |
| Liquidator proceeds above debt repaid | $1,402,789 |
Collateral seized is not the same measure as users’ net loss. Liquidators repaid debt, borrowers lost equity, and pools absorbed bad debt. Recovery proceeds reduce the final loss only once received and allocated; the figures above should not be read as the amount still outstanding today.
Response and recovery
Pragma released SDK 2.13.1 at 07:59 UTC. The change stops the SDK from using its own oracle’s USDT/USD output to construct other feeds. The direct USDT/USD feed remains separately published and aggregated.
The 1.00 factor is a containment measure. It prevents this particular feedback mechanism, but it does not model a real stablecoin depeg. A durable conversion design must explicitly handle quote currencies, liquidity, independent references and abnormal market conditions.
Recovery coordination involved Vesu, pool curators, StarkWare, the Starknet Foundation and Pragma. The principal liquidator’s recovery transfer was confirmed in the Vesu Security Council multisig on 7 September. The subsequent allocation to borrowers and lending pools is handled with the curators.
Vesu confirmed completion of asset recovery on 13 September. The Vesu and Starknet Security Councils, curators and partners worked with liquidators who voluntarily returned funds; some liquidators could not be identified or reached. Vesu’s published accounting uses 11 September prices:
| Measure | Reported value |
|---|---|
| Assets recovered, before conversion costs | $1,330,278.93 |
| Available for distribution after swaps | $1,324,085.08 |
| Lender claims from bad debt | $657,386.80 |
| Borrower claims | $737,913.96 |
| Total claims | $1,395,300.76 |
| Reported recovery rate | 95% |
At prices on the morning of 4 September, Vesu values the same recovery at 93%. The difference reflects market movements between valuation dates. These figures use a different price basis from our initial incident estimates above; they do not mean 95% of every original position has been restored.
How refunds work
Vesu, Re7 Labs and Clearstar hold recovered assets for their respective pools. Vesu recommends applying the same recovery rate to lenders’ bad-debt losses and borrowers’ net losses, but each curator decides its pool’s refund process. Under the recommended approach:
- Lenders still holding an affected position receive value through a top-up of the pool reserve; no action is needed.
- Lenders who withdrew after absorbing bad debt should contact their curator for a direct refund.
- Liquidated borrowers should contact their curator. Their claim is the collateral lost minus the debt repaid, with a direct refund in the collateral asset. The liquidation is not reversed.
Vesu also reports separate compensation for missed BTCfi rewards while liquidated positions were closed. This is outside the recovery pot and is available through the regular BTCfi rewards process.
See Vesu’s refund guide for the full methodology and open a ticket in Vesu’s official Discord to reach your curator about a specific position. Refunds go to the addresses that held those positions. Vesu warns that neither it nor a curator will contact you asking you to connect a wallet or sign a message to claim an incident refund. Questions about Pragma’s feeds can be sent to support@pragma.build.
Remediation tracker
These statuses describe verified work as of 13 September at 21:21 UTC. Deployment does not by itself close the wider operating and data-quality issues.
Remove the conversion feedback path
SDK 2.13.1 stops reuse of the onchain USDT/USD median when constructing other feeds. The permanent handling of real stablecoin deviations remains a separate design task.
Monitor publishers, freshness and deviations
Rules cover publisher outages, stale core feeds, insufficient source counts, nonpositive prices, stablecoin deviations, independent references and publisher gas. Telegram reports are grouped to reduce repeated messages. A separate urgent response path and named responders still need to be finalized.
Correct the monitoring calculations
Monitoring v0.1.30 fixes overflow when normalizing 18-decimal sources and restores independent reference lookups. v0.1.31 aligns indexer health with the deployed 30-minute publishing heartbeat.
Resume deviation metrics after a reorg
v0.1.32 restores the monitor’s synced state when replacement events catch up. Regression tests passed and fresh production calculations were verified. No natural reorg occurred during the deployment check, so recovery after a live reorg was not yet observed in that window.
Move contract administration to a 3-of-4 multisig
The intended participants are Pragma’s two founders, a Foundation nominee and a StarkWare nominee. Signer nominations and keys are still being collected. No contract ownership transfer has been submitted. This protects administration; it is separate from the pricing bug that caused the incident.
Restore publisher participation and review remaining discrepancies
Registered Ready/ARGENT and StarkWare publishers still had stale observations in the last operating check. Foundation publisher onboarding is in progress. Independent-reference disagreements and upstream RPC capacity also require follow-up.
What we learned
Publisher redundancy is not software independence. Two operators running the same conversion path can publish the same wrong result. We need to evaluate shared dependencies as well as operator count.
A timestamp and a source count are not sufficient quality checks. Fresh observations can depend on a stale route. Numerous observations can share one incorrect conversion factor. Independent price comparisons and route-liquidity checks must accompany freshness and count checks.
Derived assets need consistency checks. A derivative and its underlying can become dangerously inconsistent when they recover at different times. That failure mode belongs in integration testing.
Monitoring must itself be verified. During the follow-up we found that a chain reorg could freeze deviation calculations while indexing continued. The presence of a metric series was not proof of a newly computed observation. Verification now checks changed values alongside sync and indexing state.
The remaining work is to turn these lessons into sustained operating controls, complete the governance transition and track curator distribution updates. This page provides the dated record of that work.
Sources and technical references
This report draws on Pragma’s 4 September technical reconstruction shared with incident participants, transaction receipts and block-level oracle reads, and the verified 13 September deployment record. Recovery and refund information comes from Vesu’s public 13 September update and refund guide.