Le 22 mars 2026, un attaquant a émis 80 millions d'USR sans garantie — en déposant à peine 200 000 USDC. En 17 minutes, l'USR est passé de 1 $ à 0,025 $. Ce n'était pas un bug dans un smart contract. C'était une clé AWS compromise. Le contrat a fonctionné exactement comme programmé — il a simplement obéi à la mauvaise personne. 25 millions de dollars volés. Morpho et Fluid contaminés par des créances irrécouvrables. Et la leçon la plus coûteuse que la DeFi ait reçue concernant l'infrastructure off-chain.
Dans notre analyse de la crise USR-Morpho, nous avons couvert l'impact immédiat sur les marchés de prêt. Cet article va plus loin : comment l'attaque a été exécutée étape par étape, pourquoi 18 audits ne l'ont pas détectée, ce qu'il est advenu des utilisateurs, et ce qui a changé dans la sécurité DeFi par la suite.
Avis éditorial : cet article est informatif. L'USR a perdu sa parité et ne l'a pas retrouvée. Le token RESOLV est en alerte de delisting sur Binance. CleanSky n'a aucune relation avec Resolv Labs. Données de mai 2026.
Qu'est-ce que Resolv et comment fonctionnait l'USR avant le hack ?
Resolv était un protocole de stablecoin delta-neutral — similaire à Ethena — avec une architecture à double couche conçue pour séparer les risques :
| Couche | Token | Fonction | APY pré-hack | Qui assume le risque |
|---|---|---|---|---|
| Senior (priorité élevée) | USR | Stablecoin — maintient la parité avec le dollar | ~7,8 % | Protégé par la couche junior |
| Junior (priorité basse) | RLP | Fonds d'assurance — absorbe les pertes en premier | ~20-40 % | Première ligne de pertes |
L'idée était élégante : les investisseurs à risque (RLP) gagnent plus mais absorbent les pertes en premier, protégeant les détenteurs de stablecoin (USR). La garantie était couverte par des positions courtes sur des perpétuels — le même modèle qu'Ethena. Resolv a atteint ~100 M$ en TVL avant le hack, avec une intégration dans Morpho et Fluid comme garantie.
Comment le hack a-t-il été exécuté étape par étape ?
L'attaque n'était pas sophistiquée. Elle était brutale dans sa simplicité :
- L'attaquant a compromis les identifiants AWS — il a accédé à l'environnement Amazon Web Services où Resolv gérait la clé privée du SERVICE_ROLE (le rôle qui autorise l'émission d'USR).
- Il a appelé
requestSwapen déposant ~200 000 USDC — la fonction publique que n'importe qui peut utiliser pour initier une émission. - Il a appelé
completeSwapavec la clé volée — ordonnant au contrat d'émettre 80 millions d'USR pour ces 200 000 USDC. Ratio : 1 USDC = 500 USR. Le contrat n'avait pas de limites de ratio ni de vérification d'oracle — il a simplement obéi à celui qui détenait la clé. - Il a converti les USR en wstUSR (une version wrapped qui avait plus de liquidité sur Curve).
- Il a échangé contre de l'ETH sur Curve, KyberSwap et Uniswap — drainant ~25 M$ en ETH réel avant que quiconque ne réagisse.
| Phase | Heure (UTC) | Action | Impact |
|---|---|---|---|
| Infiltration | Pré-02:20 | Compromission des identifiants AWS + accès à KMS | Contrôle total de la clé |
| Émission I | 02:21 | Émission de 50 M USR contre 100K USDC | Inflation massive |
| Émission II | 02:23 | Émission de 30 M USR supplémentaires | Total : 80 M USR sans garantie |
| Conversion | 02:25 | Swap vers wstUSR → pools de Curve | USR chute à 0,025 $ |
| Extraction | 02:40 | Conversion finale en ~11 400 ETH | ~25 M$ volés |
Durée totale de l'attaque : ~20 minutes. 18 audits de code n'ont rien détecté — car le smart contract a fonctionné comme prévu. La faille se trouvait dans l'infrastructure : une clé avec un pouvoir absolu, stockée dans un service cloud, sans multifirma ni validation de ratio on-chain.
Pourquoi 18 audits n'ont-ils pas détecté la faille ?
Parce que les audits de sécurité en DeFi auditent le code du smart contract — pas l'infrastructure qui le contrôle. Le contrat de Resolv était techniquement correct : il faisait exactement ce qu'on lui disait. Le problème était de savoir qui pouvait lui dire quoi faire et avec quelles limitations.
Ce qui manquait et aurait dû exister :
- Multisig pour le SERVICE_ROLE — au lieu d'une seule clé, exiger 2 sur 3 ou 3 sur 5 signatures pour autoriser l'émission.
- Limites de ratio on-chain — que le contrat rejette toute émission où le ratio USDC:USR dépasse 1:1,1 (par exemple). Le ratio de 1:500 aurait dû être impossible.
- Oracle de prix — vérifier on-chain que la quantité mintée est cohérente avec la garantie déposée et le prix du marché.
- Rate limiting — limiter l'émission maximale par heure/jour. 80 M en 2 minutes aurait dû activer un circuit breaker.
L'ironie : ces mesures d'atténuation existent et sont utilisées dans des protocoles plus matures. Chainlink propose des oracles qui peuvent agir comme validateurs secondaires. Le multisig de Gnosis Safe est standard dans l'industrie. Resolv ne les a pas implémentés car il a privilégié la vitesse d'exécution (une seule signature = plus rapide) à la sécurité (signatures multiples = plus lent mais plus sûr).
Qu'est-il arrivé aux utilisateurs après le hack ?
| Catégorie d'utilisateur | Statut (mai 2026) | Ratio de rachat | Délai |
|---|---|---|---|
| Utilisateurs vérifiés (liste blanche pré-hack) | 98 % complété | 1:1 (USDC/ETH) | Terminé |
| Utilisateurs non vérifiés (pré-hack) | En cours technique | 1:1 promis | T2 2026 |
| Acheteurs post-hack | Pas de solution définie | En attente | Pas de calendrier |
| Détenteurs de RLP | Valeur déprimée/bloquée | Variable (résiduel) | Dépend des burn d'USR |
Resolv Labs a effectué des rachats de 77 M$ pour les utilisateurs prioritaires — couvrant 90 % des personnes vérifiées affectées. Le protocole disposait de 141 M$ d'actifs intacts (la garantie n'a jamais été volée — elle a seulement été diluée avec des tokens contrefaits). La stratégie : brûler les USR illicites pour restaurer la proportion garantie/offre. 46 M des 80 M émis ont été brûlés (57 %). Mais avec l'USR à 0,11-0,12 $ et un volume quotidien d'environ 420 $, le token a cessé de fonctionner comme stablecoin.
Comment le hack a-t-il contaminé Morpho et Fluid ?
La contagion a été immédiate car l'USR était utilisé comme garantie dans les protocoles de prêt :
- Fluid : a absorbé >10 M$ de créances irrécouvrables. Les oracles n'ont pas mis à jour le prix de l'USR à temps — les utilisateurs ont déposé de l'USR à valeur nominale (1 $) et ont retiré des actifs réels. L'équipe a couvert 100 % des pertes avec des prêts personnels et de trésorerie.
- Morpho : 15 de ses plus de 500 vaults ont été affectés. Les curateurs (Re7 Labs, Steakhouse Financial) ont réduit les limites à zéro. ~7,77 M$ bloqués avec 100 % d'utilisation — les prêteurs ne pouvaient pas retirer.
La leçon pour l'investisseur : si vous déposez dans un vault Morpho ou Fluid qui accepte des "garanties exotiques" (nouveaux stablecoins, tokens de restaking), votre risque inclut que cette garantie perde de la valeur instantanément. KelpDAO a fait la même chose à Aave un mois plus tard avec rsETH. Le schéma se répète : garantie acceptée pour son rendement → garantie explose → créance irrécouvrable contamine le marché monétaire.
Qu'est-ce qui a changé dans la sécurité DeFi après Resolv ?
| Avant le hack | Après le hack |
|---|---|
| Clé unique dans AWS KMS | Schémas multisig obligatoires pour les rôles privilégiés |
| Pas de validation on-chain des ratios | Limites d'émission + vérifications du ratio garantie/émission |
| Audits statiques (code uniquement) | Surveillance agencielle en temps réel (Hexagate, Chaos Labs) |
| Oracles avec délai de 15-24h | Oracles hybrides avec vérifications de déviation |
| Pause manuelle (intervention humaine) | Circuit breakers automatiques basés sur les anomalies |
Le changement le plus important n'est pas technique — il est conceptuel : l'industrie a accepté que auditer le code ne suffit pas. La sécurité d'un protocole DeFi dépend de toute la chaîne : code + infrastructure cloud + gestion des clés + oracles + surveillance en temps réel. Un seul maillon faible — comme une clé AWS sans multisig — invalide 18 audits.
Les agents de sécurité IA (comme ceux d'Hexagate que Resolv a implémentés post-hack) analysent chaque transaction avant de la confirmer on-chain, bloquant les anomalies statistiques. Un ratio d'émission de 1:500 aurait été signalé et bloqué automatiquement. La surveillance agencielle est la réponse à l'erreur humaine — mais elle doit être implémentée avant le hack, pas après.
Resolv était-il un cas isolé ou est-ce un schéma du T1 2026 ?
Ce n'était pas isolé. Le T1 2026 a montré un schéma clair : les attaquants ont cessé de chercher des bugs dans les smart contracts et se sont concentrés sur la compromission des clés privées et de l'infrastructure off-chain :
| Protocole | Date | Cause principale | Perte | Smart contract vulnérable ? |
|---|---|---|---|---|
| Resolv (USR) | Mars 2026 | Clé AWS KMS compromise | 25 M$ | Non — le contrat a fonctionné comme programmé |
| Step Finance | Janvier 2026 | Défaillance de sécurité opérationnelle | 27,3 M$ | Non — clé compromise |
| Truebit | Janvier 2026 | Vulnérabilité dans un ancien contrat | 26,6 M$ | Oui — mais dans du code legacy |
| IoTeX Bridge | Février 2026 | Fuite de clé privée d'administrateur | 4,4 M$ | Non — clé volée |
| KelpDAO | Avril 2026 | Configuration 1-sur-1 dans le vérificateur LayerZero | 292 M$ | Non — infrastructure de bridge |
Le schéma est clair : le vecteur d'attaque dominant en 2026 n'est plus le bug logique — c'est la compromission du "dernier kilomètre" de sécurité : identifiants d'administration, clés de service, configurations de bridge. Les smart contracts sont de plus en plus audités et plus sûrs. L'infrastructure qui les contrôle, non.
Pour un investisseur, l'implication est directe : avant de déposer dans n'importe quel protocole, la question n'est pas seulement "a-t-il été audité ?" mais "qui détient la clé qui peut émettre des tokens, suspendre les retraits ou modifier les paramètres — et que se passerait-il si cette clé était compromise ?" Si la réponse est "une seule personne avec une clé AWS", le risque est équivalent à celui de Resolv — quel que soit le nombre d'audits.
L'USR peut-il retrouver la parité ?
Avec les données de mai 2026 : improbable à court terme.
- Prix actuel : 0,11-0,12 $ (−88 % par rapport au peg)
- Volume quotidien : ~420 $ — pratiquement inexistant
- Capitalisation : de ~100 M$ à 5,74 M$
- Token RESOLV : 0,028 $ — en alerte de delisting (Upbit/Bithumb le suppriment le 26 mai, Binance a un Monitoring Tag)
Pour que l'USR retrouve 1 $, Resolv doit : brûler tous les USR illicites restants + restaurer la confiance du marché + récupérer les intégrations dans Morpho/Fluid + éviter les delistings. C'est un long chemin et les preuves de mai suggèrent que le marché a déplacé son capital vers des alternatives plus sûres.
Le plus honnête : Resolv était un protocole avec un modèle économique intéressant (la double couche USR/RLP est innovante) détruit par la décision la plus basique et la plus coûteuse de la sécurité informatique : confier une clé avec un pouvoir absolu à une seule personne sans validation. La garantie "est restée intacte" — mais à quoi sert une garantie intacte si l'offre en circulation a été multipliée par 80 en 2 minutes. La prochaine fois qu'un protocole vous dit "nous avons passé 18 audits", demandez : "et qui contrôle la clé qui émet les tokens ?"
Que devrait vérifier un investisseur avant de déposer dans un nouveau stablecoin ?
Resolv a enseigné que la bonne question n'est pas "le code est-il sûr ?" mais "qu'est-ce qui peut mal tourner en dehors du code ?" Liste de contrôle pratique :
- Le rôle d'émission utilise-t-il un multisig ? Si une seule clé peut émettre des tokens illimités, le protocole dépend du fait que cette clé ne soit jamais compromise. Recherchez des contrats avec des rôles attribués à un Gnosis Safe 3/5 ou supérieur.
- Y a-t-il des limites de ratio on-chain ? Un contrat qui permet d'émettre 500 USR pour 1 USDC sans qu'une alerte ne se déclenche est un protocole sans garde-fous. Le ratio d'émission devrait être codé en dur avec une marge maximale (ex : 1:1.05).
- Y a-t-il des circuit breakers ? Si l'émission dépasse X tokens par heure, se met-elle automatiquement en pause ? Sinon — toute personne ayant compromis la clé peut tout drainer avant qu'un humain ne réagisse.
- Où sont stockées les clés ? AWS KMS, GCP KMS, hardware wallet ? Qui y a accès ? Les protocoles sérieux publient la structure de garde de leurs clés d'administration.
- Que se passe-t-il si l'oracle tombe en panne ? Resolv n'avait pas d'oracle vérifiant l'émission. Les protocoles avec des oracles redondants (Chainlink + Pyth, par exemple) ont une deuxième ligne de défense.
- Quel est le TVL par rapport à son temps de fonctionnement ? Resolv avait 100 M$ avec des mois de fonctionnement. Les protocoles avec un TVL élevé et peu d'historique sont les cibles les plus attrayantes pour les attaquants — beaucoup d'argent, peu de maturité défensive.
Aucune liste de contrôle ne garantit une sécurité à 100 %. Mais si un protocole échoue sur plus de 2 de ces points, le rendement qu'il offre ne compense probablement pas le risque que son infrastructure soit la prochaine à tomber. Le rendement ajusté au risque de l'USR semblait attrayant (7,8 % APY) — jusqu'à ce que le risque se matérialise et que le rendement passe à −97 % en 17 minutes.
Avez-vous du capital dans des protocoles de prêt qui acceptent des stablecoins exotiques comme garantie ? Voir votre exposition par type de garantie vous aide à évaluer le risque de contagion.
CleanSky affiche votre portefeuille DeFi par protocole, chaîne et type d'actif — pour que vous voyiez où le risque s'accumule avant qu'un hack ne le révèle. Sans custodier vos fonds. Découvrez comment ça marche.