Två minuters felaktiga orakelpriser utlöste likvideringar för 3 miljoner dollar på Vesu

Ett två minuter långt fel i prisdata räckte för att utlösa omkring 3 miljoner dollar i onormala likvideringar på Starknet-baserade låneprotokollet Vesu. Den 4 september 2026 levererade ett felaktigt uppströmsprisflöde från Pragma fel priser mellan 04:08 och 04:10 UTC. Därmed såg 47 lånepositioner i flera Vesu-pooler ut att kunna likvideras. 32

Den avgörande skillnaden är att Vesu beskriver händelsen som ett fel i orakeldatan, inte som en sårbarhet i dess smarta kontrakt. Likvideringsmotorn följde de regler den hade fått – men prisunderlaget för reglerna var fel. 32

Så kunde två minuter räcka

I DeFi-lånemarknader jämförs löpande värdet på låntagarens säkerhet med skulden. Faller positionen under protokollets krav på säkerhetsmarginal kan en likvidator använda den vanliga likvideringsfunktionen och ta säkerhet enligt marknadens regler.

I Vesus fall fick de felaktiga Pragma-priserna 47 positioner att framstå som underkollateraliserade. Automatiserade likvidatorer tog därefter cirka 3 miljoner dollar i säkerheter innan prisflödet hade rättat sig. Händelsen kopplas inte till något fel i Vesus kontrakt. 2032

Det förklarar varför formuleringen ”kontrakten fungerade som avsett” inte är samma sak som att utfallet blev ekonomiskt korrekt. Smarta kontrakt kan kontrollera och verkställa utifrån tillgängliga data, men de kan inte på egen hand avgöra om ett orakels pris verkligen motsvarar marknaden.

Varför ett orakelfel kan likvidera i grunden friska positioner

Likvideringslogiken i ett låneprotokoll är medvetet mekanisk. Den måste kunna agera snabbt när säkerhet faktiskt tappar i värde, annars riskerar långivare att få dåliga lån i systemet. Men samma automatisering gör att ett felaktigt pris kan passera en likvideringströskel lika effektivt som en verklig marknadsrörelse.

Förloppet ser i praktiken ut så här:

1. Ett orakel publicerar ett pris som används av lånemarknaden.
2. Protokollet räknar om säkerhetens värde och skuldens risknivå utifrån priset.
3. Positionen ser ut att underskrida den nödvändiga säkerhetsgränsen.
4. Likvidatorer använder protokollets normala likvideringsväg.

På Vesu var det första steget som blev fel – inte likvideringsfunktionen som kringgicks eller utnyttjades. Vesu uppger att ingen kontraktsändring på protokollsidan behövdes. 32

Återvinning av medel, pausade pooler och råd till användare

Enligt Vesu rättade prisflödet sig självt inom det två minuter långa incidentfönstret. Pragma och relevanta parter hade dessutom infört en åtgärd mot grundorsaken. Vesu förväntade sig att poolförvaltare skulle häva pauserna i berörda pooler efter åtgärden. 32

Protokollet uppgav också att det arbetar med Pragma, StarkWare, Starknet Foundation och poolförvaltare för att försöka återvinna medel åt drabbade användare. Det är ett uttalat återvinningsarbete, inte en bekräftelse på att samtliga drabbade redan har fått ersättning. 2432

Vesus kommunicerade råd till drabbade användare var att:

• hålla sina Earn-positioner öppna, eftersom ett uttag kan påverka möjligheten att omfattas av en återvinningsprocess; och
• skicka ett supportärende via Vesus Discord om positionen likviderades i incidenten. 2734

Poolernas status kan ändras när förvaltare häver eller behåller försiktighetsåtgärder. Användare bör därför följa Vesus aktuella officiella incident- och supportkommunikation i stället för att anta att alla marknader drabbades eller att alla pooler har samma status.

Det som är känt – och det som fortfarande saknas

De offentliga uppgifterna fastställer flera centrala fakta: källan var ett uppströmsprisflöde från Pragma, felet varade cirka två minuter, flödet rättade sig självt och en åtgärd mot grundorsaken infördes i samarbete med relevanta parter. 2332

Däremot har man inte redovisat den fullständiga tekniska mekanismen bakom de felaktiga värdena eller en slutlig modell för kompensation. Vesu har angett att en fullständig teknisk rapport ska följa. Fram till dess bör påståenden om exakt programvarufel, ansvar utöver det offentliggjorda problemet i Pragmas uppströmsflöde eller slutligt återvinningsresultat betraktas som obekräftade. 27

Ett bredare DeFi-problem: korrekt kod behöver korrekta data

Vesu är ett tydligt exempel på orakelproblemet i DeFi. Applikationer kan vara transparenta och deterministiska på blockkedjan, men finansiella beslut bygger ändå på fakta som tillförs utifrån – i synnerhet tillgångspriser.

Aaves felvärdering av wstETH i mars 2026

Den 10 mars ledde en incident i Aaves CAPO-riskorakel på Ethereum Core- och Prime-marknaderna till att den effektiva växlingskursen för wstETH/stETH sänktes med omkring 2,85 procent. Den felaktiga värderingen utlöste likvideringar på cirka 26,6 miljoner dollar. Aaves efteranalys kopplade problemet till en inkonsekvens mellan ett snapshot-förhållande och en snapshot-tidsstämpel, snarare än en bred marknadskrasch. 1011

Precis som hos Vesu var kärnproblemet inte att likvideringsreglerna slutade fungera. Problemet var att reglerna tillämpades på en felaktig värdering.

Switchboards misstänkta kompromettering i Move-miljöer

I en annan och potentiellt allvarligare kategori av orakelrisk stoppade Switchboard sina orakeltjänster på Aptos, Sui, IOTA och Movement efter uppgifter om en möjlig säkerhetskompromettering i dess Move-baserade utrullningar. Stoppet var en försiktighetsåtgärd och hindrade inte de berörda blockkedjorna från att fortsätta producera block. 34

Rapporter kopplade händelsen till manipulerade IOTA-priser, onormal prägling av VUSD och likvideringar. Incidenten bör dock fortsatt beskrivas som en misstänkt kompromettering tills en definitiv utredning har fastställt orsak och omfattning. 25

Vilka skydd kan minska risken?

Ingen enskild skyddsåtgärd kan garantera att en lånemarknad avvisar varje felaktig datapunkt. Målet är snarare att minska risken att ett kortvarigt avvikande pris omedelbart orsakar oåterkallelig skada. Vanliga metoder är:

• flera oberoende priskällor i stället för en enda dataväg;
• gränser för prisavvikelser som kan avvisa eller pausa ovanligt stora rörelser;
• kontroller av hur färsk datan är, så att gamla värden inte behandlas som aktuella;
• nödstopp, så kallade circuit breakers, och poolvisa pauser;
• fördröjning eller granskning av orakeländringar med stor påverkan; och
• försiktiga säkerhetskrav för volatila eller komplexa tillgångar.

Avvägningen går inte helt att undvika: hårdare skydd kan bromsa reaktioner på verkliga marknadsrörelser, medan mindre strikta skydd gör automatiska likvideringar känsligare för felaktiga data. Vesus tvåminutersincident visar varför denna balans är central i DeFi-systemens riskhantering.

För låntagare är den praktiska lärdomen att likvideringsrisken inte bara handlar om volatilitet på marknaden eller angrepp mot smarta kontrakt. Den omfattar även integriteten, konfigurationen och den operativa motståndskraften i de orakelsystem som avgör en positions hälsa på blockkedjan.