Resolv Labs Attaqué, Les Projets DeFi Subissent Encore Une Fois Une Exploitation

Resolv Labs, l’émetteur du stablecoin USR utilisant une stratégie neutre Delta, a été victime d’une attaque. Une adresse commençant par 0x04A2 a créé 50 millions d’USR à partir du protocole Resolv Labs en utilisant 100 000 USDC.
Après la révélation de l’incident, le prix de l’USR a immédiatement chuté à environ 0,25 dollar, avant de se redresser à environ 0,80 dollar au moment de la rédaction. Le prix du token RESOLV a également chuté de près de 10 % en peu de temps.

Ensuite, les hackers ont utilisé une méthode similaire pour générer 30 millions d’USR avec 100 000 USDC. Lorsque l’USR a perdu une part importante de sa valeur, les spéculateurs ont rapidement réagi, et de nombreux marchés de prêt sur Morpho, supportant USR, wstUSR et d’autres actifs en garantie, ont été presque épuisés. La DAO Lista sur la chaîne BNB a également suspendu les nouvelles demandes de prêt.

Ces protocoles de prêt ne sont pas les seuls affectés. Le protocole Resolv Labs permet aussi aux utilisateurs de créer des tokens RLP, ce qui entraîne une volatilité plus grande et des profits plus élevés, mais aussi une responsabilité légale pour les pertes subies par le protocole. Actuellement, près de 30 millions de tokens RLP sont en circulation, dont plus de 13 millions détenus par Stream Finance, représentant un risque net d’environ 17 millions de dollars.
Oui, Stream Finance, la société ayant subi de lourdes pertes à cause de xUSD, pourrait bientôt faire face à un nouveau choc.
Au moment de la rédaction, les hackers ont converti l’USR en USDC et USDT, et continuent d’acheter de l’Ethereum, en achetant plus de 10 000 ETH. Avec 200 000 USDC, ils ont récupéré plus de 20 millions de dollars d’actifs, trouvant leur « monnaie rentable 100 fois » dans le marché baissier.
Une fois de plus, une faille a été exploitée en raison d’un « manque de rigueur ».

La forte chute du 11 octobre dernier a entraîné des pertes d’actifs en garantie pour de nombreux stablecoins émis selon la stratégie Delta-neutral, en raison de l’ADL (Auto Deleveraging). Certains projets utilisant des altcoins comme actifs ont subi des pertes encore plus importantes, voire ont disparu complètement.

Resolv Labs, le projet attaqué cette fois, utilise un mécanisme similaire pour émettre l’USR. En avril 2025, le projet a annoncé avoir terminé une levée de fonds d’amorçage de 10 millions de dollars menée par Cyber.Fund et Maven11, avec la participation de Coinbase Ventures, et avoir lancé le token RESOLV fin mai et début juin.

Cependant, la cause de l’attaque contre Resolv Labs n’est pas liée à un marché difficile, mais au fait que le mécanisme de création d’USR « n’était pas suffisamment rigoureux ».

Aucune société de sécurité ou agence officielle n’a encore analysé les causes de cette attaque. Une analyse préliminaire par un membre de la communauté DeFi, YAM, suggère que l’attaque pourrait résulter d’un hacker ayant pris le contrôle de la fonction SERVICE_ROLE, utilisée dans la partie auxiliaire du protocole pour fournir des paramètres au contrat de création de monnaie.

Selon Grok, lorsque les utilisateurs créent des USR, ils initient une requête sur la blockchain et appellent la fonction requestMint du contrat, avec des paramètres tels que :

• _depositTokenAddress : l’adresse où les tokens sont envoyés ;
• _amount : la quantité à déposer ;
• _minMintAmount : la quantité minimale d’USR attendue (point anti-dérive).

Ensuite, l’utilisateur envoie USDC ou USDT dans le contrat. La partie auxiliaire SERVICE_ROLE du projet supervise la requête, utilisant l’oracle Pyth pour vérifier la valeur des actifs envoyés, puis appelle la fonction completeMint ou completeSwap pour déterminer la quantité réelle d’USR créée.

Le problème réside dans le fait que le contrat de mint fait entièrement confiance au mintAmount fourni par SERVICE_ROLE, supposant que ce chiffre a été vérifié hors chaîne par Pyth. Il ne limite pas ou ne vérifie pas ce montant avec un oracle on-chain, mais exécute directement mint(_mintAmount).

Sur cette base, YAM suspecte que le hacker a pris le contrôle de SERVICE_ROLE, qui aurait dû être contrôlé par l’équipe du projet (peut-être en raison d’un problème interne avec l’oracle, d’un vol interne ou d’un piratage de clé), et a directement fixé _mintAmount à 50 millions lors de la création de la monnaie virtuelle, permettant ainsi de générer 50 millions d’USR avec 100 000 USDC.

En conclusion, Grok indique que Resolv n’a pas prévu que l’adresse (ou le contrat) recevant la demande de création d’USR puisse être contrôlée par un hacker lors de la conception du protocole. Lorsqu’une demande de création d’USR est envoyée au contrat final, aucune limite maximale n’est définie, et le contrat de mint ne vérifie pas secondairement avec un oracle on-chain. Il fait simplement confiance à tous les paramètres fournis par SERVICE_ROLE.

Les mesures de prévention sont également insuffisantes.

Outre la spéculation sur la cause de l’attaque, YAM souligne le manque de préparation de l’équipe du projet pour faire face à une crise.

YAM a déclaré sur X que Resolv Labs avait suspendu le protocole pendant trois heures après l’attaque initiale, dont environ une heure pour collecter les quatre signatures nécessaires pour les transactions multisignatures. YAM pense que la suspension d’urgence aurait dû nécessiter une seule signature, et que cette autorité devrait être confiée à des membres de l’équipe ou à des opérateurs externes de confiance chaque fois que possible. Cela renforcerait la détection d’anomalies sur la chaîne, améliorerait la capacité à suspendre rapidement et couvrirait mieux différents fuseaux horaires.

Bien que la proposition de suspendre un protocole avec une seule signature puisse sembler extrême, exiger plusieurs signatures provenant de différents fuseaux horaires pour suspendre un protocole pourrait entraîner des retards importants en situation d’urgence. La mise en place d’un tiers de confiance surveillant en permanence le comportement sur la chaîne, ou l’utilisation d’outils de surveillance avec pouvoir de suspension d’urgence, sont des leçons à tirer de cet incident.

Les attaques de hackers contre les protocoles DeFi ont longtemps été limitées aux vulnérabilités des contrats. L’incident Resolv Labs est un avertissement pour les équipes de projets : la sécurité du protocole ne doit faire confiance à aucune partie du système, et tous les paramètres liés doivent faire l’objet d’au moins deux vérifications, y compris sur les serveurs gérés par l’équipe elle-même.