Rédigé par : Eric, Foresight News
Aujourd'hui, à environ 10h21, Resolv Labs, qui a émis le stablecoin USR en utilisant une stratégie neutre Delta, a été victime d'une attaque de hacker. L'adresse commençant par 0x04A2 a minté 50 millions d'USR à partir du protocole Resolv Labs avec 100 000 USDC.
Avec l'exposition des événements, l'USR a chuté à environ 0,25 dollar, et au moment de la rédaction, il a rebondi à environ 0,8 dollar. Le prix du jeton RESOLV a également connu une baisse maximale de près de 10 %.
Ensuite, les hackers ont répliqué la méthode en mintant à nouveau 30 millions d'USR avec 100 000 USDC. Avec le désancrage important de l'USR, les traders d'arbitrage ont également agi rapidement, de nombreux marchés de prêt sur Morpho soutenant l'USR, wstUSR, etc., en tant que collatéraux ont été presque vidés, et le Lista DAO sur la chaîne BNB a également suspendu les nouvelles demandes de prêt.
Les protocoles de prêt affectés ne se limitent pas à ceux-ci. Dans la conception du protocole Resolv Labs, les utilisateurs peuvent également mint un jeton RLP, dont la volatilité des prix est plus grande et les rendements plus élevés, mais qui nécessite de supporter une responsabilité de compensation lorsque le protocole subit des pertes. Actuellement, l'offre en circulation du jeton RLP est d'environ 30 millions, le plus grand détenteur, Stream Finance, possédant plus de 13 millions de RLP, avec une exposition nette au risque d'environ 17 millions de dollars.
En effet, Stream Finance, qui avait déjà subi une chute à cause de l'effondrement de xUSD, pourrait subir une nouvelle frappe.
Au moment de la rédaction, les hackers avaient déjà converti l'USR en USDC et USDT, et continuaient à acheter de l'Ethereum, ayant déjà acquis plus de 10 000 unités. Avec 200 000 USDC, ils ont retiré plus de 20 millions de dollars d'actifs, trouvant pendant le marché baissier leur « monnaie multipliée par cent ».
Encore une fois, la négligence a permis aux hackers de profiter de la situation.
La chute massive du 11 octobre de l'année dernière a entraîné des pertes de collatéraux pour de nombreux stablecoins émis avec la stratégie neutre Delta en raison de l'ADL (automated deleveraging). Certains projets utilisant des altcoins comme actifs pour exécuter des stratégies ont subi des pertes encore plus importantes, voire ont carrément fait faillite.
Cette fois, Resolv Labs, qui a été attaqué, a également émis l'USR en utilisant un mécanisme similaire. Le projet avait annoncé en avril 2025 avoir complété un tour de financement de 10 millions de dollars dirigé par Cyber.Fund et Maven11, avec Coinbase Ventures comme investisseur, et les jetons RESOLV ont été lancés fin mai ou début juin.
Cependant, la raison de l'attaque contre Resolv Labs n'est pas due à des conditions extrêmes, mais à la conception du mécanisme de mint de l'USR qui n'est pas « assez rigoureuse ».
Actuellement, aucune entreprise de sécurité ni aucune autorité n'a analysé la cause de cet incident de hacking. La communauté DeFi YAM a conclu après une analyse préliminaire que l'attaque était probablement due au fait que le SERVICE_ROLE utilisé par l'arrière-plan du protocole pour fournir des paramètres au contrat de mint avait été contrôlé par les hackers.
Selon l'analyse de Grok, les utilisateurs lancent une demande sur la chaîne lors de la mint de l'USR et appellent la fonction requestMint du contrat, avec les paramètres suivants :
_depositTokenAddress : adresse du jeton déposé ;
_amount : quantité à déposer ;
_minMintAmount : quantité minimale d'USR attendue (glissement).
Ensuite, les utilisateurs déposent des USDC ou USDT dans le contrat, le SERVICE_ROLE de l'arrière-plan du projet surveille la demande, utilise l'oracle Pyth pour vérifier la valeur des actifs déposés, puis appelle les fonctions completeMint ou completeSwap pour décider du nombre réel d'USR à mint.
Le problème réside dans le fait que le contrat de mint fait entièrement confiance à _mintAmount fourni par le SERVICE_ROLE, estimant que ce chiffre avait été vérifié hors chaîne par Pyth, et n'a donc pas mis de limite supérieure, ni vérifié sur la chaîne par un oracle, exécutant directement mint(_mintAmount).
À cet égard, YAM soupçonne que les hackers ont contrôlé le SERVICE_ROLE qui aurait dû être contrôlé par l'équipe du projet (peut-être à cause d'une perte de contrôle de l'oracle interne, de vols internes ou de vols de clés), et ont directement défini _mintAmount à 50 millions lors de la mint, réalisant ainsi l'attaque consistant à mint 50 millions d'USR avec 100 000 USDC.
En fin de compte, la conclusion de Grok est que Resolv n'a pas pris en compte la possibilité que l'adresse (ou le contrat) utilisée pour recevoir les demandes de mint des utilisateurs soit contrôlée par des hackers lors de la conception du protocole. Lorsque la demande de mint de l'USR a été soumise au contrat final pour mint de l'USR, aucune limite maximale n'a été définie, et le contrat de mint n'a pas effectué de vérification secondaire via un oracle sur la chaîne, faisant directement confiance à tous les paramètres fournis par le SERVICE_ROLE.
La prévention n'est également pas à la hauteur.
En plus de spéculer sur les raisons de l'attaque, 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 que 3 heures après la première attaque, une heure de ce temps étant due à la collecte des 4 signatures nécessaires pour la transaction multi-signatures. YAM estime que la suspension d'urgence ne devrait nécessiter qu'une seule signature, et que les droits devraient être attribués dans la mesure du possible aux membres de l'équipe ou à des opérateurs externes de confiance, ce qui augmenterait la vigilance face aux anomalies sur la chaîne et améliorerait la possibilité d'une suspension rapide, tout en tenant compte des différents fuseaux horaires.
Bien que la suggestion de suspendre le protocole avec une seule signature soit quelque peu radicale, le fait que plusieurs signatures soient nécessaires à travers différents fuseaux horaires pourrait en effet retarder les actions cruciales en cas d'urgence. L'introduction de tiers de confiance qui surveillent en permanence les comportements sur la chaîne, ou l'utilisation d'outils de surveillance ayant les droits de suspension d'urgence, sont des enseignements tirés de cet incident.
Les attaques des hackers contre les protocoles DeFi ne se limitent déjà plus aux vulnérabilités des contrats. L'incident de Resolv Labs avertit les équipes de projet que les hypothèses en matière de sécurité du protocole ne doivent pas faire confiance à un quelconque maillon, tous les paramètres impliqués doivent être vérifiés au moins deux fois, même le backend opéré par l'équipe du projet.