Artikel von: Eric, Foresight News

Heute um etwa 10:21 Uhr, wurde Resolv Labs, das den stabilen USR-Token mit einer Delta-Neutral-Strategie ausgibt, von Hackern angegriffen. Eine Adresse, die mit 0x04A2 beginnt, hat mit 100.000 USDC aus dem Resolv Labs-Protokoll 50 Millionen USR geprägt.

Mit der Enthüllung des Vorfalls fiel der USR-Preis auf etwa 0,25 USD und stieg zum Zeitpunkt des Schreibens auf etwa 0,8 USD. Der Preis des RESOLV-Tokens fiel kurzfristig um fast 10%.

Anschließend prägten die Hacker erneut mit 100.000 USDC 30 Millionen USR. Mit dem erheblichen Verlust der Bindung des USR handelten auch Arbitrage-Trader schnell, viele Kreditmärkte auf Morpho, die USR, wstUSR usw. als Sicherheiten unterstützen, wurden nahezu leer geräumt, und die Lista DAO auf der BNB Chain stellte neue Kreditanforderungen ein.

Betroffen sind nicht nur diese Kreditprotokolle. Im Design des Resolv Labs-Protokolls können Benutzer auch einen RLP-Token prägen, dessen Preisvolatilität höher und die Erträge auch höher sind, jedoch müssen sie im Falle eines Verlusts des Protokolls für Entschädigungen aufkommen. Derzeit beträgt das Umlaufvolumen des RLP-Tokens fast 30 Millionen Exemplare, der größte Inhaber, Stream Finance, hält über 13 Millionen RLP mit einem Netto-Risiko von etwa 17 Millionen US-Dollar.

Genau, Stream Finance, das zuvor wegen xUSD einen Rückschlag erlitten hat, könnte erneut getroffen werden.

Zum Zeitpunkt des Schreibens hat der Hacker USR in USDC und USDT umgewandelt und kauft weiterhin Ethereum, wobei bereits über 10.000 Exemplare gekauft wurden. Mit 200.000 USDC wurden über 20 Millionen US-Dollar an Vermögenswerten abgezogen, und der Hacker fand in der Bärenmarktphase seine 'Hundertfach-Währung'.

Wieder einmal wurde aufgrund von 'Unachtsamkeit' eine Schwachstelle ausgenutzt.

Der starke Rückgang am 11. Oktober letzten Jahres führte dazu, dass viele Stablecoins, die eine Delta-neutrale Strategie verwendeten, aufgrund von ADL (automatischer Hebelabbau) Verluste bei den Sicherheiten erlitten. Einige Projekte, die als Ausführungsstrategie Altcoins verwendeten, erlitten noch größere Verluste oder liefen sogar direkt weg.

Dieses Mal wurde Resolv Labs, das ebenfalls ein ähnliches Mechanismus zur Ausgabe von USR verwendet, angegriffen. Das Projekt gab im April 2025 bekannt, dass es eine Seed-Finanzierungsrunde in Höhe von 10 Millionen US-Dollar abgeschlossen hatte, angeführt von Cyber.Fund und Maven11, mit Beteiligung von Coinbase Ventures, und die Token RESOLV wurden Ende Mai und Anfang Juni gelistet.

Aber der Grund für den Angriff auf Resolv Labs sind nicht extreme Marktentwicklungen, sondern das Design des Mechanismus zur Prägung von USR ist 'nicht stringent genug'.

Bislang hat kein Sicherheitsunternehmen oder offizielles Organ eine Analyse der Ursachen des Hackerangriffs durchgeführt. Die DeFi-Community YAM hat durch Analysen vorläufig zu dem Schluss gekommen, dass der Angriff wahrscheinlich darauf zurückzuführen ist, dass die SERVICE_ROLE, die vom Backend des Protokolls zur Bereitstellung von Parametern für den Prägevertrag verwendet wird, von Hackern kontrolliert wurde.

Laut Grok-Analysen initiieren Benutzer beim Prägen von USR eine Anfrage auf der Blockchain und rufen die Funktion requestMint des Vertrags auf, wobei die Parameter Folgendes umfassen:

_depositTokenAddress: Adresse des eingezahlten Tokens;

_amount: Einzahlungsbetrag;

_minMintAmount: Mindestanzahl an erwarteten USR (Slippage-Schutz).

Danach werden die Benutzer USDC oder USDT in den Vertrag einzahlen, das Backend des Projektteams SERVICE_ROLE überwacht die Anfragen, verwendet das Pyth-Orakel, um den Wert der eingezahlten Vermögenswerte zu überprüfen, und ruft dann die Funktionen completeMint oder completeSwap auf, um die tatsächliche Menge an USR zu bestimmen, die geprägt wird.

Das Problem liegt darin, dass der Prägevertrag der von der SERVICE_ROLE bereitgestellten _mintAmount vollständig vertraut und annimmt, dass diese Zahl off-chain von Pyth validiert wurde, weshalb keine Obergrenzenbeschränkung gesetzt wurde und auch keine On-Chain-Oracle-Validierung stattfand, sodass mint(_mintAmount) direkt ausgeführt wurde.

In diesem Zusammenhang verdächtigt YAM, dass Hacker die SERVICE_ROLE kontrollierten, die eigentlich vom Projektteam kontrolliert werden sollte (möglicherweise aufgrund eines internen oracle-Control-Fails, Diebstahl oder gestohlener Schlüssel) und beim Prägen die _mintAmount direkt auf 50 Millionen setzten, was zu einem Angriff führte, der 50 Millionen USR mit 100.000 USDC prägte.

Letztendlich ist das Fazit von Grok, dass Resolv bei der Gestaltung des Protokolls nicht die Möglichkeit berücksichtigt hat, dass die Adresse (oder der Vertrag), die zur Entgegennahme von Benutzerprägenanfragen verwendet wird, von Hackern kontrolliert werden könnte. Als die Anfrage zur Prägung von USR an den Vertrag gesendet wurde, der letztendlich USR prägt, wurden keine maximalen Prägebeträge festgelegt, und der Prägevertrag verwendete keine On-Chain-Oracle zur zweiten Validierung, sondern vertraute direkt auf alle von der SERVICE_ROLE bereitgestellten Parameter.

Die Prävention ist ebenfalls unzureichend.

Neben der Spekulation über die Gründe für den Hack stellte YAM auch fest, dass die Projektteams unzureichend auf Krisen vorbereitet waren.

YAM äußerte auf X, dass Resolv Labs die Protokolle erst 3 Stunden nach dem ersten erfolgreichen Angriff des Hackers aussetzte, wobei etwa 1 Stunde Verzögerung durch die Notwendigkeit von 4 Unterschriften für die Sammlung der Multisignaturtransaktionen entstand. YAM glaubt, dass eine sofortige Aussetzung nur eine Unterschrift erfordern sollte und die Berechtigungen so weit wie möglich an Teammitglieder oder vertrauenswürdige externe Betreiber verteilt werden sollten, um das Bewusstsein für ungewöhnliche On-Chain-Situationen zu erhöhen, die Wahrscheinlichkeit einer schnellen Aussetzung zu erhöhen und eine bessere Abdeckung über verschiedene Zeitzonen hinweg zu ermöglichen.

Obwohl der Vorschlag, das Protokoll mit nur einer Unterschrift auszusetzen, etwas radikal ist, könnte die Notwendigkeit mehrerer Unterschriften über verschiedene Zeitzonen hinweg in Notfallsituationen tatsächlich wichtige Angelegenheiten verzögern. Die Einführung eines vertrauenswürdigen Dritten, der das On-Chain-Verhalten kontinuierlich überwacht, oder die Verwendung von Überwachungswerkzeugen mit Berechtigungen zur Notaussetzung des Protokolls sind die 'Lehren' aus diesem Vorfall.

Die Angriffe von Hackern auf DeFi-Protokolle beschränken sich längst nicht mehr auf Vertragsanfälligkeiten. Der Vorfall bei Resolv Labs warnt die Projektteams, dass in Bezug auf die Sicherheit des Protokolls keine Annahme in irgendeinem Glied der Kette vertrauenswürdig sein sollte; alle Parameter müssen mindestens zweimal verifiziert werden, selbst wenn es sich um Backend handelt, das von den Projektteams betrieben wird.