En échangeant 200 000 contre près de 100 millions, les stablecoins DeFi font face à une nouvelle attaque

Écrit par : Eric, Actualités prospectives

Vers 10 h 21, heure de Pékin, Resolv Labs, qui émet des stablecoins en USDT en utilisant une stratégie neutre Delta, a été piraté. Une adresse commençant par 0x04A2 a frappé 50 millions d'USR du protocole Resolv Labs en utilisant 100 000 USDC.

Lorsque l’incident a été révélé, l’USR a chuté à environ 0,25 $ et, au moment d’écrire ces lignes, il a rebondi à environ 0,8 $. Le prix du token RESOLV a également connu une baisse temporaire de près de 10 %.

Par la suite, le hacker a reproduit la méthode et a de nouveau frappé 30 millions d’USR en utilisant 100 000 USDC. Avec le découplage significatif des USD, les traders d'arbitrage ont rapidement agi, et de nombreux marchés de prêt sur Morpho qui prennent en charge les USD, les USDT et d'autres types de garanties ont été presque vidés, tandis que Lista DAO de la blockchain BNB a également suspendu les nouvelles demandes de prêt.

L'impact ne se limite pas à ces protocoles de prêt. Dans la conception du protocole Resolv Labs, les utilisateurs peuvent également frapper un token RLP plus volatil et à rendement plus élevé, mais ils doivent assumer des responsabilités d'indemnisation lorsque le protocole subit des pertes. Actuellement, la circulation des tokens RLP est de près de 30 millions, le plus gros détenteur, Stream Finance, détenant plus de 13 millions de RLP, ce qui entraîne une exposition nette au risque d'environ 17 millions de dollars.

En effet, Stream Finance, qui avait précédemment souffert en raison de l'incident de xUSD, pourrait être à nouveau touché.

Au moment d'écrire ces lignes, le hacker a converti des USDR en USDC et USDT et continue d'acheter de l'Ethereum, après en avoir déjà acheté plus de 10 000. Avec 200 000 USDC, ils ont extrait plus de 20 millions de dollars d'actifs, trouvant leur « coin centuple » pendant le marché baissier.

Une autre exploitation due à un « manque de rigueur »

La forte baisse du 11 octobre de l’année dernière a entraîné de nombreuses pertes collatérales dues à l’ADL (désendettement automatique) pour de nombreux stablecoins émis selon des stratégies Delta neutres. Certains projets qui ont exécuté des stratégies en utilisant des altcoins ont subi des pertes encore plus lourdes ou ont fait directement faillite.

Les Resolv Labs attaqués ont également émis des USD en utilisant un mécanisme similaire. Le projet a annoncé en avril 2025 avoir réalisé un tour de table de 10 millions de dollars mené par Cyber.Fund et Maven11, avec la participation de Coinbase Ventures, et lancé le token RESOLV fin mai à début juin.

Cependant, la raison de l'attaque de Resolv Labs n'était pas due à des conditions de marché extrêmes, mais plutôt au « manque de rigueur » dans la conception du mécanisme de frappe des USDR.

Actuellement, aucune société de sécurité ou aucun responsable n'a analysé les raisons de cet incident de piratage. La communauté DeFi YAM a préliminairement conclu par une analyse que l'attaque avait probablement été causée par le hacker contrôlant le SERVICE_ROLE utilisé par le backend du protocole pour fournir les paramètres du contrat de frappe.

Selon l'analyse de Grok, lorsque les utilisateurs frappent des USDR, ils initient une requête on-chain et appellent la fonction requestMint du contrat, avec des paramètres notamment :

_depositTokenAddress : l'adresse du token déposé ;

_amount : le montant déposé ;

_minMintAmount : montant minimum attendu d’USR à recevoir (pour éviter tout glissement).

Par la suite, les utilisateurs déposent des USDC ou des USDT dans le contrat, et SERVICE_ROLE du projet surveille la demande, en utilisant l'oracle Pyth pour vérifier la valeur des actifs déposés, puis appelle la fonction completeMint ou completeSwap pour déterminer le montant réel d'USR frappés.

Le problème réside dans le fait que le contrat de frappe fait entièrement confiance au _mintAmount fourni par le SERVICE_ROLE, croyant que ce nombre a été vérifié hors-chaîne par Pyth, donc aucune limite maximale n'a été fixée, et il n'y a pas eu de vérification on-chain de l'oracle, exécutant directement mint(_mintAmount).

Sur cette base, YAM soupçonne que le hacker a contrôlé le SERVICE_ROLE qui aurait dû être contrôlé par l'équipe du projet (peut-être en raison d'une défaillance interne de l'oracle, d'une collusion ou d'un vol de clés), fixant directement le _mintAmount à 50 millions pendant la frappe, réalisant l'événement d'attaque de frapper 50 millions d'USR avec 100 000 USDC.

Finalement, Grok a conclu que Resolv n'avait 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 des pirates informatiques lors de la conception du protocole. Lorsque la demande de frappe d’USR a été soumise au contrat qui frappe finalement des USR, aucun montant maximum de frappe n'a été défini, et il n'y a pas eu de vérification secondaire à l'aide d'un oracle on-chain, faisant directement confiance à tous les paramètres fournis par le SERVICE_ROLE.

Les mesures de prévention étaient également inadéquates

En plus de spéculer sur les raisons du piratage, YAM a également souligné la préparation insuffisante du projet à la réponse à la crise.

YAM a déclaré sur X que Resolv Labs n'avait suspendu le protocole que trois heures après la première attaque du hacker, environ une heure de ce retard venant de la nécessité de recueillir quatre signatures pour la transaction multi-signatures. YAM estime qu'une pause d'urgence ne devrait nécessiter qu'une seule signature, et que l'autorité devrait être distribuée autant que possible aux membres de l'équipe ou aux opérateurs externes de confiance, ce qui permettrait de mieux sensibiliser les utilisateurs aux anomalies sur la blockchain, d'améliorer la probabilité d'une pause rapide et de mieux couvrir les différents fuseaux horaires.

Bien que la suggestion selon laquelle une seule signature pourrait suspendre le protocole soit quelque peu radicale, exiger plusieurs signatures sur différents fuseaux horaires pour suspendre le protocole pourrait effectivement retarder des questions importantes en cas d'urgence. Présentation de tiers de confiance qui surveillent en continu le comportement on-chain ou l'utilisation d'outils de surveillance avec l'autorité de protocole de suspension d'urgence sont les leçons tirées de cet incident.

Les attaques de pirates informatiques contre les protocoles DeFi ne se limitent plus aux vulnérabilités des contrats. L'incident impliquant Resolv Labs sert d'avertissement aux équipes de projet : les hypothèses concernant la sécurité du protocole ne doivent pas faire confiance à un lien unique, et tous les processus liés aux paramètres doivent faire l'objet d'une vérification au moins secondaire, y compris ceux opérés par l'équipe de projet elle-même.