Am 4. September 2026 ließen fehlerhafte Pragma Preisdaten zwischen 04:08 und 04:10 UTC 47 Vesu Kreditpositionen fälschlich liquidierbar erscheinen; betroffen waren Sicherheiten im Wert von rund 3 Mio.
Veröffentlicht vonBearbeitet mit GPT-5.6 TerraBilder erstellt mit GPT Image 2
Forschungsantwort

Create 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
Ein Fehler von nur zwei Minuten hat auf dem Starknet-Kreditprotokoll Vesu irreguläre Liquidationen von Sicherheiten im Wert von rund 3 Mio. US-Dollar ausgelöst. Am 4. September 2026 lieferte ein vorgelagerter Preisfeed von Pragma zwischen 04:08 und 04:10 UTC falsche Kurse. Dadurch erschienen 47 Kreditpositionen in mehreren Vesu-Pools als liquidierbar. 32
Der entscheidende Punkt: Vesu ordnet den Vorfall als Fehler bei den Oracle-Eingabedaten ein – nicht als Sicherheitslücke in den eigenen Smart Contracts. Die Liquidationslogik setzte also die Regeln um, die ihr vorlagen; die Preisgrundlage dieser Regeln war jedoch falsch. 32
DeFi-Kreditmärkte prüfen fortlaufend, ob der gemeldete Wert einer hinterlegten Sicherheit noch ausreichend ist, um die Schulden einer Position zu decken. Fällt die Position unter die vorgeschriebene Besicherungsgrenze, können Liquidatoren die reguläre Liquidationsfunktion auslösen und Sicherheiten nach den Marktregeln übernehmen.
Bei Vesu ließen die fehlerhaften Pragma-Kurse 47 Positionen unterbesichert aussehen. Automatisierte Liquidatoren entfernten daraufhin Sicherheiten im Wert von etwa 3 Mio. US-Dollar, bevor sich der Feed wieder korrigierte. 20
32
Dass die Verträge „wie vorgesehen“ arbeiteten, bedeutet daher nicht automatisch, dass das wirtschaftliche Ergebnis korrekt war. Smart Contracts können Daten prüfen und Regeln ausführen, aber nicht aus eigener Kraft feststellen, ob ein gemeldeter Oracle-Preis den tatsächlichen Markt widerspiegelt.
Liquidationsmechanismen sind bewusst automatisiert: Sinkt eine Sicherheit tatsächlich stark im Wert, muss ein Protokoll schnell reagieren können, damit Kreditgeber nicht auf ungedeckten Forderungen sitzen bleiben. Genau diese Automatisierung kann aber auch bei einem falschen Preis eine Liquidationsschwelle überschreiten.
Der Ablauf ist einfach:
Bei Vesu war der Fehler demnach der erste Schritt – der Preisinput –, nicht eine Umgehung oder Ausnutzung der Liquidationslogik. Vesu erklärte, auf Ebene der eigenen Smart Contracts sei kein Fix erforderlich gewesen. 32
Nach Vesu-Angaben korrigierte sich der Preisfeed innerhalb des zweiminütigen Zeitfensters. Pragma habe gemeinsam mit weiteren Beteiligten eine Behebung der Ursache ausgerollt. Anschließend sollten Pool-Kuratoren die betroffenen Pools wieder freigeben. 32
Zugleich arbeitet Vesu nach eigenen Angaben mit Pragma, StarkWare, der Starknet Foundation und Pool-Kuratoren daran, Gelder für betroffene Nutzer zurückzuholen. Das ist eine angekündigte Wiederherstellungsbemühung – keine Bestätigung, dass bereits alle Geschädigten entschädigt wurden. 24
32
Betroffenen riet Vesu laut Berichten:
Der Status einzelner Pools kann sich ändern. Nutzer sollten daher aktuelle offizielle Incident- und Support-Mitteilungen von Vesu prüfen, statt anzunehmen, dass alle Märkte gleichermaßen betroffen oder bereits wieder freigegeben sind.
Öffentlich bestätigt sind mehrere Kernpunkte: Auslöser war ein vorgelagerter Pragma-Preisfeed, der Fehler dauerte rund zwei Minuten, der Feed korrigierte sich selbst, und gemeinsam mit Beteiligten wurde ein Fix für die Ursache bereitgestellt. 23
32
Nicht veröffentlicht wurde bislang der vollständige technische Mechanismus, der zu den fehlerhaften Werten führte. Ebenso gibt es noch keinen abschließenden Rahmen für eine Entschädigung. Vesu stellte einen detaillierten technischen Bericht in Aussicht. Bis zu dessen Veröffentlichung bleiben Aussagen über den exakten Softwarefehler, eine weitergehende Schuldzuordnung oder das endgültige Ergebnis der Wiederherstellung unbestätigt. 27
Der Vesu-Fall verdeutlicht das Oracle-Problem in DeFi: Anwendungen können onchain transparent und deterministisch arbeiten, treffen finanzielle Entscheidungen aber auf Grundlage von Informationen außerhalb des Smart Contracts – allen voran Assetpreisen.
Am 10. März führte ein Vorfall beim CAPO-Risiko-Oracle auf Aaves Ethereum-Core- und Prime-Märkten dazu, dass der effektive wstETH/stETH-Wechselkurs um rund 2,85 % zu niedrig angesetzt wurde. Die falsche Bewertung löste Liquidationen im Umfang von ungefähr 26,6 Mio. US-Dollar aus. Aaves Post-Mortem führte dies auf eine Inkonsistenz zwischen einem Snapshot-Verhältnis und dem zugehörigen Zeitstempel zurück – nicht auf einen breit angelegten Markteinbruch. 10
11
Wie bei Vesu versagten nicht die Liquidationsregeln selbst. Sie wurden auf eine unzutreffende Bewertung angewandt.
Eine andere, potenziell gravierendere Kategorie des Oracle-Risikos zeigte sich bei Switchboard. Nach Berichten über einen möglichen Sicherheitskompromiss setzte das Netzwerk seine Oracle-Dienste auf Aptos, Sui, IOTA und Movement aus. Der vorsorgliche Stopp betraf die Oracle-Infrastruktur, nicht die Blockproduktion der jeweiligen Netzwerke. 3
4
Berichte brachten das Ereignis mit manipulierten IOTA-Preisdaten, ungewöhnlicher VUSD-Prägung und Liquidationen in Verbindung. Der Vorfall sollte jedoch weiterhin als mutmaßlicher Kompromiss bezeichnet werden, bis eine abschließende Untersuchung Ursache und Umfang eindeutig geklärt hat. 2
5
Keine einzelne Schutzmaßnahme kann jeden fehlerhaften Preiswert sicher abfangen. Ziel ist vielmehr, zu verhindern, dass eine kurze Anomalie sofort irreversiblen Schaden verursacht. Gängige Ansätze sind:
Der Zielkonflikt bleibt: Strengere Sicherungen können auch notwendige Reaktionen auf echte Kursbewegungen verlangsamen. Lockerere Einstellungen machen automatische Liquidationen hingegen anfälliger für fehlerhafte Daten. Der zweiminütige Vesu-Vorfall zeigt, weshalb diese Abwägung zentral für das Risikodesign in DeFi ist.
Für Kreditnehmer ist die praktische Lehre klar: Liquidationsrisiko entsteht nicht nur durch Marktschwankungen oder Smart-Contract-Exploits. Es hängt auch von Integrität, Konfiguration und operativer Widerstandsfähigkeit der Oracle-Systeme ab, welche die finanzielle Gesundheit einer Onchain-Position bestimmen.
Studio Global AI
Diese Seite enthält eine quellengestützte Antwort, die Sie in Studio Global fortsetzen können.
Am 4. September 2026 ließen fehlerhafte Pragma Preisdaten zwischen 04:08 und 04:10 UTC 47 Vesu Kreditpositionen fälschlich liquidierbar erscheinen; betroffen waren Sicherheiten im Wert von rund 3 Mio.
Am 4. September 2026 ließen fehlerhafte Pragma Preisdaten zwischen 04:08 und 04:10 UTC 47 Vesu Kreditpositionen fälschlich liquidierbar erscheinen; betroffen waren Sicherheiten im Wert von rund 3 Mio. Vesu betont, dass seine Smart Contracts wie vorgesehen funktionierten. Pragma und beteiligte Parteien haben nach Angaben des Protokolls eine Ursache behoben; betroffene Pools waren vorsorglich pausiert.
Der Fall erinnert an Aaves wstETH Oracle Fehler im März und den jüngsten vorsorglichen Switchboard Stopp auf vier Move Netzwerken: DeFi Protokolle sind trotz deterministischer Smart Contracts von verlässlichen externe...
Am 4. September 2026 ließen fehlerhafte Pragma Preisdaten zwischen 04:08 und 04:10 UTC 47 Vesu Kreditpositionen fälschlich liquidierbar erscheinen; betroffen waren Sicherheiten im Wert von rund 3 Mio.
Veröffentlicht vonBearbeitet mit GPT-5.6 TerraBilder erstellt mit GPT Image 2
Forschungsantwort

Create 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
Ein Fehler von nur zwei Minuten hat auf dem Starknet-Kreditprotokoll Vesu irreguläre Liquidationen von Sicherheiten im Wert von rund 3 Mio. US-Dollar ausgelöst. Am 4. September 2026 lieferte ein vorgelagerter Preisfeed von Pragma zwischen 04:08 und 04:10 UTC falsche Kurse. Dadurch erschienen 47 Kreditpositionen in mehreren Vesu-Pools als liquidierbar. 32
Der entscheidende Punkt: Vesu ordnet den Vorfall als Fehler bei den Oracle-Eingabedaten ein – nicht als Sicherheitslücke in den eigenen Smart Contracts. Die Liquidationslogik setzte also die Regeln um, die ihr vorlagen; die Preisgrundlage dieser Regeln war jedoch falsch. 32
DeFi-Kreditmärkte prüfen fortlaufend, ob der gemeldete Wert einer hinterlegten Sicherheit noch ausreichend ist, um die Schulden einer Position zu decken. Fällt die Position unter die vorgeschriebene Besicherungsgrenze, können Liquidatoren die reguläre Liquidationsfunktion auslösen und Sicherheiten nach den Marktregeln übernehmen.
Bei Vesu ließen die fehlerhaften Pragma-Kurse 47 Positionen unterbesichert aussehen. Automatisierte Liquidatoren entfernten daraufhin Sicherheiten im Wert von etwa 3 Mio. US-Dollar, bevor sich der Feed wieder korrigierte. 20
32
Dass die Verträge „wie vorgesehen“ arbeiteten, bedeutet daher nicht automatisch, dass das wirtschaftliche Ergebnis korrekt war. Smart Contracts können Daten prüfen und Regeln ausführen, aber nicht aus eigener Kraft feststellen, ob ein gemeldeter Oracle-Preis den tatsächlichen Markt widerspiegelt.
Liquidationsmechanismen sind bewusst automatisiert: Sinkt eine Sicherheit tatsächlich stark im Wert, muss ein Protokoll schnell reagieren können, damit Kreditgeber nicht auf ungedeckten Forderungen sitzen bleiben. Genau diese Automatisierung kann aber auch bei einem falschen Preis eine Liquidationsschwelle überschreiten.
Der Ablauf ist einfach:
Bei Vesu war der Fehler demnach der erste Schritt – der Preisinput –, nicht eine Umgehung oder Ausnutzung der Liquidationslogik. Vesu erklärte, auf Ebene der eigenen Smart Contracts sei kein Fix erforderlich gewesen. 32
Nach Vesu-Angaben korrigierte sich der Preisfeed innerhalb des zweiminütigen Zeitfensters. Pragma habe gemeinsam mit weiteren Beteiligten eine Behebung der Ursache ausgerollt. Anschließend sollten Pool-Kuratoren die betroffenen Pools wieder freigeben. 32
Zugleich arbeitet Vesu nach eigenen Angaben mit Pragma, StarkWare, der Starknet Foundation und Pool-Kuratoren daran, Gelder für betroffene Nutzer zurückzuholen. Das ist eine angekündigte Wiederherstellungsbemühung – keine Bestätigung, dass bereits alle Geschädigten entschädigt wurden. 24
32
Betroffenen riet Vesu laut Berichten:
Der Status einzelner Pools kann sich ändern. Nutzer sollten daher aktuelle offizielle Incident- und Support-Mitteilungen von Vesu prüfen, statt anzunehmen, dass alle Märkte gleichermaßen betroffen oder bereits wieder freigegeben sind.
Öffentlich bestätigt sind mehrere Kernpunkte: Auslöser war ein vorgelagerter Pragma-Preisfeed, der Fehler dauerte rund zwei Minuten, der Feed korrigierte sich selbst, und gemeinsam mit Beteiligten wurde ein Fix für die Ursache bereitgestellt. 23
32
Nicht veröffentlicht wurde bislang der vollständige technische Mechanismus, der zu den fehlerhaften Werten führte. Ebenso gibt es noch keinen abschließenden Rahmen für eine Entschädigung. Vesu stellte einen detaillierten technischen Bericht in Aussicht. Bis zu dessen Veröffentlichung bleiben Aussagen über den exakten Softwarefehler, eine weitergehende Schuldzuordnung oder das endgültige Ergebnis der Wiederherstellung unbestätigt. 27
Der Vesu-Fall verdeutlicht das Oracle-Problem in DeFi: Anwendungen können onchain transparent und deterministisch arbeiten, treffen finanzielle Entscheidungen aber auf Grundlage von Informationen außerhalb des Smart Contracts – allen voran Assetpreisen.
Am 10. März führte ein Vorfall beim CAPO-Risiko-Oracle auf Aaves Ethereum-Core- und Prime-Märkten dazu, dass der effektive wstETH/stETH-Wechselkurs um rund 2,85 % zu niedrig angesetzt wurde. Die falsche Bewertung löste Liquidationen im Umfang von ungefähr 26,6 Mio. US-Dollar aus. Aaves Post-Mortem führte dies auf eine Inkonsistenz zwischen einem Snapshot-Verhältnis und dem zugehörigen Zeitstempel zurück – nicht auf einen breit angelegten Markteinbruch. 10
11
Wie bei Vesu versagten nicht die Liquidationsregeln selbst. Sie wurden auf eine unzutreffende Bewertung angewandt.
Eine andere, potenziell gravierendere Kategorie des Oracle-Risikos zeigte sich bei Switchboard. Nach Berichten über einen möglichen Sicherheitskompromiss setzte das Netzwerk seine Oracle-Dienste auf Aptos, Sui, IOTA und Movement aus. Der vorsorgliche Stopp betraf die Oracle-Infrastruktur, nicht die Blockproduktion der jeweiligen Netzwerke. 3
4
Berichte brachten das Ereignis mit manipulierten IOTA-Preisdaten, ungewöhnlicher VUSD-Prägung und Liquidationen in Verbindung. Der Vorfall sollte jedoch weiterhin als mutmaßlicher Kompromiss bezeichnet werden, bis eine abschließende Untersuchung Ursache und Umfang eindeutig geklärt hat. 2
5
Keine einzelne Schutzmaßnahme kann jeden fehlerhaften Preiswert sicher abfangen. Ziel ist vielmehr, zu verhindern, dass eine kurze Anomalie sofort irreversiblen Schaden verursacht. Gängige Ansätze sind:
Der Zielkonflikt bleibt: Strengere Sicherungen können auch notwendige Reaktionen auf echte Kursbewegungen verlangsamen. Lockerere Einstellungen machen automatische Liquidationen hingegen anfälliger für fehlerhafte Daten. Der zweiminütige Vesu-Vorfall zeigt, weshalb diese Abwägung zentral für das Risikodesign in DeFi ist.
Für Kreditnehmer ist die praktische Lehre klar: Liquidationsrisiko entsteht nicht nur durch Marktschwankungen oder Smart-Contract-Exploits. Es hängt auch von Integrität, Konfiguration und operativer Widerstandsfähigkeit der Oracle-Systeme ab, welche die finanzielle Gesundheit einer Onchain-Position bestimmen.
Studio Global AI
Diese Seite enthält eine quellengestützte Antwort, die Sie in Studio Global fortsetzen können.
Am 4. September 2026 ließen fehlerhafte Pragma Preisdaten zwischen 04:08 und 04:10 UTC 47 Vesu Kreditpositionen fälschlich liquidierbar erscheinen; betroffen waren Sicherheiten im Wert von rund 3 Mio.
Am 4. September 2026 ließen fehlerhafte Pragma Preisdaten zwischen 04:08 und 04:10 UTC 47 Vesu Kreditpositionen fälschlich liquidierbar erscheinen; betroffen waren Sicherheiten im Wert von rund 3 Mio. Vesu betont, dass seine Smart Contracts wie vorgesehen funktionierten. Pragma und beteiligte Parteien haben nach Angaben des Protokolls eine Ursache behoben; betroffene Pools waren vorsorglich pausiert.
Der Fall erinnert an Aaves wstETH Oracle Fehler im März und den jüngsten vorsorglichen Switchboard Stopp auf vier Move Netzwerken: DeFi Protokolle sind trotz deterministischer Smart Contracts von verlässlichen externe...