Rédigé par : Eric, Foresight News
Aujourd'hui à 10:21 heure de Pékin, Resolv Labs, qui émet le stablecoin USR en utilisant une stratégie delta neutre, a été victime d'une attaque de pirate. L'adresse commençant par 0x04A2 a utilisé 100 000 USDC pour frapper 50 millions d'USR à partir du protocole Resolv Labs.
Suite à l'exposition de l'événement, l'USR a chuté à environ 0,25 dollar, remontant à environ 0,8 dollar au moment de la rédaction. Le prix du jeton RESOLV a également enregistré une baisse maximale à court terme de près de 10%.
Ensuite, le pirate a réitéré la méthode en utilisant à nouveau 100 000 USDC pour frapper 30 millions d'USR. Avec le décrochage important de l'USR, les traders d'arbitrage sont rapidement passés à l'action. De nombreux marchés de prêt sur Morpho supportant l'USR, le wstUSR, etc. comme collatéral ont été presque vidés, et Lista DAO sur BNB Chain a également suspendu les nouvelles demandes de prêt.
Les protocoles affectés ne se limitent pas à ces marchés de prêt. Dans la conception du protocole Resolv Labs, les utilisateurs peuvent également frapper un jeton RLP, dont le prix est plus volatile et le rendement plus élevé, mais qui nécessite de assumer la responsabilité de l'indemnisation en cas de perte du protocole. Actuellement, le nombre de jetons RLP en circulation est proche de 30 millions, le plus grand détenteur, Stream Finance, détenant plus de 13 millions de RLP, avec une exposition nette aux risques d'environ 17 millions de dollars.
Oui, Stream Finance, qui avait déjà été touché une fois par l'effondrement du xUSD, pourrait être frappé à nouveau.
Au moment de la rédaction, le pirate a converti l'USR en USDC et USDT, et continue d'acheter de l'Ethereum, ayant déjà acheté plus de 10 000 ETH. Avec 200 000 USDC, le pirate a extorqué des actifs d'une valeur supérieure à 20 millions de dollars, trouvant sa « crypto à 100x » pendant le marché baissier.
Une autre faille exploitée à cause d'un manque de rigueur
La forte baisse du 11 octobre dernier a entraîné des pertes de collatéral pour de nombreux stablecoins émis via des stratégies delta neutres en raison de l'ADL (Auto-Deleveraging). Les projets utilisant des altcoins comme actifs pour exécuter leurs stratégies ont subi des pertes encore plus importantes, certains ayant même purement et simplement disparu.
Resolv Labs, victime de cette attaque, utilise un mécanisme similaire pour émettre l'USR. Le projet avait annoncé en avril 2025 avoir levé 10 millions de dollars en financement de démarrage (seed round) mené par Cyber.Fund et Maven11, avec la participation de Coinbase Ventures, et avait lancé son jeton RESOLV fin mai début juin.
Mais la raison de l'attaque contre Resolv Labs n'est pas due à des conditions de marché extrêmes, mais à une conception « pas assez rigoureuse » du mécanisme de frappe de l'USR.
Aucune entreprise de sécurité ou officiel n'a encore analysé la cause de cet incident de piratage. La communauté DeFi YAM a tiré une conclusion préliminaire après analyse : l'attaque est probablement due au fait que le SERVICE_ROLE, utilisé par le backend du protocole pour fournir des paramètres au contrat de frappe, a été contrôlé par le pirate.
Selon l'analyse de Grok, lorsqu'un utilisateur frappe de l'USR, il initie une requête on-chain et appelle la fonction requestMint du contrat, dont les paramètres incluent :
_depositTokenAddress : l'adresse du jeton déposé ;
_amount : le montant déposé ;
_minMintAmount : le montant minimum d'USR attendu (protection contre le slippage).
Ensuite, l'utilisateur dépose de l'USDC ou de l'USDT dans le contrat, le backend du projet (SERVICE_ROLE) surveille la requête, utilise l'oracle Pyth pour vérifier la valeur de l'actif déposé, puis appelle la fonction completeMint ou completeSwap pour décider du nombre réel d'USR à frapper.
Le problème réside dans le fait que le contrat de frappe fait entièrement confiance au _mintAmount fourni par SERVICE_ROLE, supposant que ce chiffre a été vérifié off-chain par Pyth. Il n'a donc pas fixé de limite supérieure et n'a pas effectué de vérification on-chain par oracle, exécutant directement mint(_mintAmount).
Sur cette base, YAM soupçonne que le pirate a contrôlé le SERVICE_ROLE qui devrait normalement être sous le contrôle de l'équipe du projet (peut-être en raison d'une perte de contrôle de l'oracle interne, de détournement interne ou du vol de clés). Lors de la frappe, il a directement défini _mintAmount sur 50 millions, réalisant ainsi l'attaque consistant à frapper 50 millions d'USR avec 100 000 USDC.
En fin de compte, la conclusion donnée par Grok est que Resolv, lors de la conception du protocole, n'a pas envisagé la possibilité que l'adresse (ou le contrat) utilisée pour recevoir les demandes de frappe des utilisateurs puisse être contrôlée par un pirate. Lorsque la demande de frappe d'USR est soumise au contrat final de frappe, aucun montant de frappe maximum n'a été fixé, et le contrat de frappe n'a pas effectué de double vérification avec un oracle on-chain, faisant simplement confiance à tous les paramètres fournis par SERVICE_ROLE.
La prévention était également insuffisante
Outre la spéculation sur la cause 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 que 3 heures après la première attaque du pirate, dont environ 1 heure de retard était due à la collecte des 4 signatures nécessaires pour la transaction multisig. YAM estime que la suspension d'urgence ne devrait nécessiter qu'une seule signature, et que les autorisations devraient être attribuées autant que possible aux membres de l'équipe ou à des opérateurs externes de confiance, afin d'accroître l'attention portée aux anomalies on-chain, d'améliorer la possibilité d'une suspension rapide et de mieux couvrir les différents fuseaux horaires.
Bien que la suggestion d'une suspension du protocole avec une seule signature soit quelque peu radicale, le fait de nécessiter plusieurs signatures couvrant différents fuseaux horaires pour suspendre le protocole peut effectivement causer des retards importants en cas d'urgence. L'introduction d'un tiers de confiance surveillant en continu le comportement on-chain, ou l'utilisation d'outils de surveillance disposant de permissions de suspension d'urgence du protocole, sont des leçons à tirer de cet événement.
Les attaques de pirates contre les protocoles DeFi ne se limitent plus depuis longtemps aux seules vulnérabilités des contrats. L'événement de Resolv Labs sert d'avertissement pour les équipes de projet : l'hypothèse en matière de sécurité du protocole devrait être de ne faire confiance à aucun maillon de la chaîne. Tous les maillons impliquant des paramètres doivent faire l'objet d'au moins une double vérification, même le backend exploité par l'équipe du projet elle-même.
