Article rédigé par Eric, Foresight News
Vers 10:21 heure de Pékin, Resolv Labs, qui a lancé la stablecoin USR selon une stratégie delta neutre, a été piratée. L’adresse commençant par 0x04A2 a créé 50 millions d’USR en utilisant 100 000 USDC sur le protocole Resolv Labs.
À la suite de la révélation de l'événement, l'USR est tombé à environ 0,25 dollar, puis a rebondi à environ 0,8 dollar au moment de la rédaction. Le prix du jeton RESOLV a également chuté de près de 10 % à son plus bas moment.
Ensuite, le pirate a répété la même méthode pour créer 30 millions d'USR avec 100 000 USDC. Avec le fort décrochage de l'ancrage de l'USR, les arbitragistes ont rapidement agi ; de nombreux marchés de prêt sur Morpho qui acceptaient l'USR, le wstUSR et d'autres actifs en garantie ont été presque entièrement vidés, et le Lista DAO sur BNB Chain a suspendu les nouvelles demandes de prêt.
Ce ne sont pas seulement ces protocoles de prêt qui sont affectés. Dans la conception du protocole Resolv Labs, les utilisateurs peuvent également émettre des jetons RLP, présentant une plus grande volatilité de prix et un rendement plus élevé, mais exigeant une responsabilité de compensation en cas de pertes pour le protocole. Actuellement, la circulation des jetons RLP s'élève à près de 30 millions, avec Stream Finance comme plus grand détenteur, détenant plus de 13 millions de jetons RLP, pour une exposition nette au risque d'environ 17 millions de dollars américains.
Oui, Stream Finance, qui avait déjà été touché par un crash lié à xUSD, pourrait être de nouveau frappé.
Au moment de la rédaction, le pirate a converti l'USR en USDC et USDT, et continue d'acheter Ethereum, ayant déjà acquis plus de 10 000 unités. Avec 200 000 USDC, il a extrait plus de 20 millions de dollars d'actifs ; pendant la baisse du marché, le pirate a trouvé son « coin à cent fois ».
Encore une fois, des failles ont été exploitées en raison d'une « négligence »
Le krach du 11 octobre de l'année dernière a entraîné des pertes de collatéral pour de nombreuses stablecoins émises selon des stratégies delta neutre en raison de l'ADL (réduction automatique de levier). Certains projets utilisant des altcoins comme actifs de stratégie ont subi des pertes encore plus importantes, voire ont directement fui.
Resolv Labs, ciblé lors de cette attaque, a également émis l'USR en utilisant un mécanisme similaire. Ce projet avait annoncé en avril 2025 avoir levé 10 millions de dollars en financement de démarrage, dirigé par Cyber.Fund et Maven11, avec la participation de Coinbase Ventures, et avait lancé le jeton RESOLV à la fin mai et au début juin.
Mais la raison pour laquelle Resolv Labs a été attaqué n'est pas une行情 extrême, mais une conception du mécanisme de création de USR « insuffisamment rigoureuse ».
Aucune entreprise de sécurité ni autorité officielle n'a encore analysé la cause de cet incident de piratage. La communauté DeFi YAM a, après analyse, établi une conclusion préliminaire : l'attaque a probablement été causée par la compromission du rôle SERVICE_ROLE utilisé par l'arrière-plan du protocole pour fournir des paramètres au contrat de frappe.
Selon l'analyse de Grok, lorsqu'un utilisateur frappe de l'USR, il déclenche une demande sur la chaîne et appelle la fonction requestMint du contrat, avec les paramètres suivants :
_depositTokenAddress : adresse du jeton déposé ;
_amount : quantité déposée ;
_minMintAmount : Quantité minimale attendue de USR à recevoir (slippage).
Ensuite, l'utilisateur dépose des USDC ou des USDT dans le contrat ; le backend du projet, avec le rôle SERVICE_ROLE, surveille la demande, vérifie la valeur des actifs déposés à l'aide de l'oracle Pyth, puis appelle les fonctions completeMint ou completeSwap pour déterminer le nombre réel d'USR à émettre.
Le problème réside dans le fait que le contrat de frappe fait entièrement confiance à _mintAmount fourni par SERVICE_ROLE, en supposant que ce nombre a été vérifié hors chaîne par Pyth, sans imposer de limite supérieure ni effectuer de vérification par oracles sur chaîne, exécutant directement mint(_mintAmount).
À la lumière de cela, YAM soupçonne que le pirate a pris le contrôle du SERVICE_ROLE, qui devait être géré par l'équipe du projet (probablement en raison d'une défaillance interne de l'oracle, d'une fraude interne ou d'un vol de clés), et a défini directement _mintAmount à 50 millions lors de la création, permettant ainsi d'effectuer une attaque consistant à créer 50 millions d'USR en échange de 100 000 USDC.
Au final, Grok conclut que Resolv n’a pas envisagé la possibilité que l’adresse (ou le contrat) destiné à recevoir les demandes de frappe des utilisateurs soit compromis par un pirate, n’a pas fixé de limite maximale de frappe lors de la soumission des demandes de frappe USR au contrat final, et n’a pas exigé une vérification secondaire via un oracle sur chaîne, se contentant de faire confiance à tous les paramètres fournis par SERVICE_ROLE.
Les mesures de prévention ne sont pas suffisantes
Outre les hypothèses sur les raisons du piratage, YAM a également souligné le manque de préparation de l'équipe du projet face à la crise.
YAM a déclaré sur X que Resolv Labs n'a suspendu le protocole qu'après 3 heures suivant la première attaque de l'attaquant, avec environ 1 heure de délai causé par la collecte des 4 signatures nécessaires pour les transactions multisig. YAM estime qu'une suspension d'urgence devrait nécessiter une seule signature, et que les autorisations devraient être réparties aussi largement que possible parmi les membres de l'équipe ou des opérateurs externes de confiance, afin d'augmenter la vigilance face aux anomalies sur la chaîne, d'améliorer la probabilité d'une suspension rapide et de mieux couvrir les différents fuseaux horaires.
Bien que l'idée de ne nécessiter qu'une seule signature pour suspendre le protocole semble radicale, exiger plusieurs signatures provenant de différentes zones horaires peut effectivement retarder les actions en cas d'urgence. Introduire un tiers de confiance surveillant en continu les comportements sur la chaîne, ou utiliser des outils de surveillance dotés d'un droit de suspension d'urgence, constituent des leçons tirées de cet événement.
Les attaques des pirates contre les protocoles DeFi ne se limitent plus aux vulnérabilités des contrats. L'événement de Resolv Labs avertit les équipes de projets : il faut supposer qu'aucun élément du protocole ne peut être considéré comme digne de confiance ; toutes les étapes impliquant des paramètres doivent faire l'objet d'au moins une double vérification, même pour les backends gérés par les équipes elles-mêmes.