Le hack de Resolv (USR) : les curateurs face à leurs responsabilités

Mise à jour du 24 mars : Après la publication de cette analyse, nous avons poursuivi nos investigations et de nouvelles informations nous sont parvenues : #1 Mise à jour de Resolv sur la situation, #2 Erratum sur le vecteur d’attaque (Public Allocator → Donation Attack). Nous remercions 9Summits pour leur accompagnement dans ces recherches.

---

Les détails de l’incident USR de Resolv

Resolv en deux mots

Resolv est un protocole de finance on-chain qui se présente comme une “couche financière pour le rendement sur les stablecoins”. Son produit principal est l’USR, un dollar synthétique adossé à des actifs cryptos (ETH, stETH, BTC) et conçu pour générer du rendement via des instruments financiers comme des stratégies delta-neutral.

Le protocole repose sur une structure à deux tranches. L'USR est la tranche senior, censée être stable, sur-collatéralisée et orientée sur la protection du capital. Le RLP est la tranche junior, un produit avec levier portant les risques résiduels de l’USR en échange d'un rendement plus élevé. En cas de perte au niveau du protocole, c'est le RLP qui absorbe en premier.

À la veille de l'incident, Resolv affichait une supply d'environ 102 millions d'USR pour une TVL de 141 millions de dollars environ.

Le processus de mint d’USR

Le mint d'USR fonctionne en deux temps. Les dépôts en USDC des utilisateurs sont traités via une fonction appelée requestSwap(). Une adresse détenant le SERVICE_ROLE finalise ensuite automatiquement l'opération via completeSwap(), en déterminant la quantité d'USR à émettre.

Le problème fondamental est inscrit dans la conception même de Resolv : la fonction completeSwap() ne contient aucune vérification on-chain du ratio entre le montant déposé et la quantité mintée. Cette décision est prise entièrement off-chain.

Le smart contract se contente de vérifier que l'appelant détient bien le SERVICE_ROLE, et que le montant émis est supérieur au minimum indiqué par l'utilisateur. En d'autres termes : si le détenteur du SERVICE_ROLE décide d'émettre 50 millions d'USR contre 100 000 USDC, le contrat s'exécute sans poser de questions.

Une clé privée compromise

Ce qu’il s’est passé le 22 mars 2026 est qu’un individu est parvenu à compromettre la clé privée du SERVICE_ROLE, hébergée dans un environnement AWS KMS. À partir de là, il disposait de tous les droits du compte, sans aucune restriction. En effet, nous le verrons par la suite, il ne s’agissait pas d’une multisig mais bien d'une adresse EOA classique, comme celle que la majorité d’entre nous utilisons quotidiennement.

Le hacker a soumis trois requestSwap(), permettant chacune de déposer 100 000 USDC. Pour la première, il appelle completeSwap() avec un paramètre cible de 50 millions d'USR. Pour la dernière, 30 millions d’USR. La deuxième demande (id=31) appartient à un utilisateur lambda, qui reçoit un mint normal de 100 000 USR environ (ce qui révèle une manipulation sélective du hacker).

Au total, ce sont 300 000 USDC déposés en entrée pour 80 millions d’USR créés à partir de rien, avec un ratio hallucinant de 266:1.

La conversion des fonds volés

Les USR non collatéralisés ont ensuite été convertis de manière méthodique contre des actifs “réels”. Le hacker a déposé de l'USR dans le pool Curve USR/USDC, provoquant un effondrement du prix de 1 dollar à moins de 0,025 dollar à son point le plus bas. Les USDC ont ensuite été échangés contre de l’ETH via Uniswap V4 et MetaMask Swaps. Il a également procédé à des échanges de wstUSR contre de l’USDC via KyberSwap en passant par Fluid.

Finalement, le hacker a extrait environ 11 400 ETH de l’opération, valorisés 24 millions de dollars au cours actuel. Environ 36 millions d'USR sont encore détenus par l'attaquant actuellement, pour une valeur estimée de 2 millions de dollars.

Resolv Labs est parvenu à mettre en pause le protocole environ trois heures après le début de l'incident. Aussi étonnant que cela puisse paraître, ce délai est notamment explicable par le délai nécessaire à la réunion des quatre signatures multisig nécessaires à la transaction d’arrêt d’urgence du protocole, alors que la transaction de mint d’USR n’en requiert pas.

---

Les éléments clés et catalyseurs du hack

Les failles sur Resolv

• Un SERVICE_ROLE mal configuré

Le SERVICE_ROLE détenait un pouvoir de création monétaire illimité sur un protocole gérant 141 millions de dollars. Il était contrôlé par une EOA (Externally Owned Account), c'est-à-dire une adresse classique gérée par une seule clé privée, comme celle qu’utilise n’importe quel individu pour interagir avec la blockchain.

Le paradoxe est d’autant plus cynique. La fonction de pause du protocole était protégée par un multisig à quatre signatures. La fonction de mint, elle, dépendait d'une seule clé. Resolv avait mis plus de précautions pour arrêter le protocole que pour contrôler sa capacité à créer de la monnaie.

• Une absence totale de garde-fous on-chain

L’un des éléments les plus étonnants dans l’opération réalisée par le hacker est qu’il est parvenu à mint plusieurs dizaines de millions d’USR d’un coup. Autrement dit, aucun cap de mint par transaction n'était en place. Une protection basique aurait pu consister à plafonner le montant pouvant être émis lors d'une seule opération à un pourcentage de la supply totale, ou à instaurer un délai entre deux opérations de grande ampleur. Rien de tel n'existait dans completeSwap().

Par ailleurs, aucune vérification de ratio n'était implémentée on-chain. Le contrat n'effectuait aucune comparaison entre le montant déposé et le montant à émettre. Une règle simple aurait pu consister à fixer le mint à un certain multiple du dépôt, ce qui aurait rendu cette attaque impossible à grande échelle.

Aucun oracle de sanity check n'était présent. L'intégration d'un oracle de prix sur l'USR dans la logique de mint aurait permis de détecter automatiquement une émission incohérente avec la valeur de marché du stablecoin.

• Une vulnérabilité signalée

Le code de Resolv a été audité 18 fois, sans aucune vulnérabilité repérée. Pourtant, il y a environ 1 an, un internaute spécialisé en cybersécurité avait soumis un rapport à Resolv dans lequel il pointait directement ce vecteur d’attaque lié au SERVICE_ROLE. Le rapport a été fermé : le scénario impliquait la compromission d'un rôle privilégié, ce qui était considéré hors scope.

Ce qui est problématique est qu’il existe une convention tacite selon laquelle les scénarios de compromission de clés admin sont exclus des périmètres d'audit, au motif que les administrateurs sont des entités de confiance. Or, l’exemple de Resolv montre qu’une clé privée peut justement être compromise et que souvent, l’humain est le premier point de défaillance.

Le fait de concevoir des garde-fous on-chain comme des caps de mint, des timelocks ou des vérifications de ratio n'est pas une mesure de méfiance envers les équipes. Au contraire, c'est simplement admettre que la confiance humaine ne remplace pas la robustesse d'un système.

Les mécanismes qui ont amplifié les dégâts

• Le vault wstUSR/USDC de Morpho

Pour comprendre l'amplification des pertes, il faut présenter Morpho. Le protocole fonctionne sur une logique de marchés isolés : chaque marché est une paire unique, un collatéral et un actif empruntable. L'isolation entre marchés est une propriété de sécurité importante, censée empêcher la propagation du risque.

Au-dessus de ces marchés opèrent des vaults gérés par des curateurs, qui répartissent le capital entre plusieurs marchés pour optimiser le rendement des déposants. En conditions normales, c'est une architecture solide. En conditions de crise, elle présente une vulnérabilité peu connue que l'attaquant a parfaitement identifiée et exploitée.

• Un oracle hardcodé à 1$

Au moment où l'USR s'effondrait à 0,025 dollar sur les marchés secondaires, les vaults Morpho contenant de l'USR ou du wstUSR en collatéral continuaient de l'évaluer à 1 dollar. Le prix de l'USR n'était pas récupéré via un oracle externe mais était hardcodé à 1 USDC.

Autrement dit, dans la théorie, n’importe quel utilisateur pouvait déposer de l’USR en collatéral et emprunter des USDC à hauteur d’une valeur fictive : 1000 USR (valorisé à 25 dollars) pouvaient permettre d’emprunter par exemple 500 USDC et de répéter l’opération.

Cela signifie également qu'il n'y avait aucun mécanisme de mise à jour en temps réel ni aucun circuit-breaker capable de suspendre les marchés en cas d'écart significatif entre le prix oracle et le prix de marché. C'est cette configuration précise qui a rendu possible toute la suite.

• Le Donation Attack, une vulnérabilité documentée

Autour de 2h20 UTC, dès que les curateurs ont pris conscience de l'exploit sur Resolv, la quasi-totalité d'entre eux a réagi de la même manière : mettre les supply caps des marchés USR à zéro sur leurs vaults, bloquant ainsi tout nouvel afflux de capital vers ces marchés. En théorie, c'est la bonne réponse. En pratique, c’était insuffisant et Morpho le savait.

La documentation officielle de Morpho Vaults V1 décrit une vulnérabilité dans les versions 1.0 et 1.1 : lorsqu'un marché utilise un oracle dont le prix est significativement supérieur au prix de marché réel (i.e la situation du USR) il est possible d'augmenter le nombre de parts détenues par un vault dans ce marché via une "donation", et donc de lui infliger des pertes.

Ce qui est d’autant plus incroyable, c’est que la précision figure en toutes lettres dans la documentation de Morpho : ”une supply cap fixée à zéro ne protège pas contre cette attaque”. Vraisemblablement, elle n’a pas correctement été communiquée aux curateurs, puisqu’ils ont tous réagi de cette manière en pensant mettre leurs vaults en sécurité.

Pour comprendre pourquoi, il faut distinguer deux niveaux de contrôle. Les supply caps et la file d'allocation régissent ce que le vault décide lui-même d'allouer via sa propre logique. Mais la fonction supply() de Morpho accepte un paramètre onBehalf : n'importe qui peut l'appeler en désignant l'adresse d'un vault comme bénéficiaire du dépôt, créditant ainsi des parts de marché à ce vault sans que celui-ci ne l'ait demandé ni autorisé.

L’ampleur des dégâts causés par cette attaque réside dans le ratio de parts que détient l’attaquant dans la supply totale du vault ciblé. Plus l'attaquant détient une grande fraction des shares du vault, plus il peut extraire. C'est là qu'intervient le flashloan : il permet à l'attaquant d'acquérir temporairement une part massive des shares du vault, d'exécuter l'attaque, puis de rembourser le flashloan.

Revenons à l’affaire Resolv. Le marché ciblé par l’attaquant est le wstUSR/USDC sur Morpho. C'est le seul endroit où l'attaquant peut déposer son wstUSR déprécié comme collatéral et l'emprunter contre des USDC, puisque l'oracle y valorise encore l'USR à 1 dollar. Le problème : ce marché est peu liquide au départ. Il n'y a pas assez de USDC disponibles pour que l'opération soit rentable à grande échelle.

C'est là qu'intervient la Donation Attack. L’attaquant aurait d’abord pris un flashloan de USDC depuis Morpho directement, puis en appelant supply(onBehalf=vault_address), il aurait forcé des vaults détenant des USDC et ayant listé le marché wstUSR/USDC dans leur WithdrawalQueue à augmenter malgré eux leur exposition à ce marché.

Ces vaults se retrouvent avec des parts dans le marché wstUSR/USDC sans l'avoir décidé, ce qui y injecte de la liquidité USDC. Plus l'attaquant détient une fraction importante des shares du vault ciblé au moment de l'opération, plus la quantité de liquidité qu'il peut forcer à entrer dans le marché est grande. D'où le recours au flashloan pour acquérir temporairement cette position dominante.

Une fois la liquidité injectée de force dans le marché wstUSR/USDC, l'attaquant dépose son wstUSR fictivement valorisé à 1 dollar comme collatéral, emprunte les USDC fraîchement disponibles, rembourse le flashloan et repart avec la différence.

Ce qui est élégant dans cette attaque, c'est que mettre les supply caps à zéro ne change rien : les caps contrôlent ce que le vault alloue lui-même via sa logique interne, mais pas ce qu'on lui force depuis l'extérieur via supply(onBehalf=vault_address). C'est exactement ce que la documentation Morpho avertit.

9summits documente précisément le moment où cette attaque a été exécutée contre son vault : à 12h33 UTC, une série de 32 transactions a contourné ses défenses. Sa bad debt résiduelle s'est limitée à 41 000 dollars grâce à son intervention précoce à 3h UTC. Re7 Labs, qui avait détecté l'exploit dès 2h46 UTC et alerté ses partenaires en temps réel, a également subi des pertes isolées sur deux marchés. Gauntlet, avec une réaction plus lente, concentre 96% des pertes totales.

---

La responsabilité des curateurs

Ce qu’un curateur est censé être

L’un des paradoxes récurrents de la DeFi est qu’elle prétend supprimer les intermédiaires, en reprenant l’un des principes fondateurs de l’écosystème comme mot d’ordre. C’est évidemment une fausse promesse, car supprimer la confiance est tout simplement impossible. La vraie révolution de la DeFi réside non pas dans la disparition de la confiance, mais dans sa transformation.

Les curateurs en sont l’exemple le plus évident, et pourtant le moins connu du grand public. En théorie, leur rôle est de faire le travail que l’utilisateur ne peut pas faire lui-même : analyser les marchés, sélectionner les expositions, calibrer le risque, surveiller les anomalies et, surtout, protéger le capital lorsqu’un scénario sort du cadre normal. En d’autres termes, ils ne vendent pas seulement du rendement. Ils vendent aussi leur confiance.

C’est précisément pour cela que nous écrivions en 2025 que les curateurs étaient devenus les nouveaux garants de la confiance dans la finance on-chain. Non pas parce qu’ils détiennent directement les fonds, mais parce qu’ils orientent leur exposition, décident des marchés jugés acceptables et agissent comme filtre entre la complexité des protocoles et les utilisateurs finaux.

La promesse implicite est donc la suivante : vous nous déléguez une partie du travail de sélection et de surveillance, en échange d’une meilleure gestion du risque. L’affaire Resolv permet justement de tester cette promesse dans un environnement réel, c’est-à-dire au pire moment possible.

Une mauvaise analyse de risque

Steakhouse Financial est l'un des acteurs de référence dans le rôle de curateur et de gestionnaire de risque en DeFi. Récemment nommé risk manager officiel de Resolv, Steakhouse a publié une évaluation approfondie du protocole 5 jours seulement avant le hack.

Le rapport couvre en détail la structure USR/RLP, la mécanique delta-neutral, et les mécanismes de gestion des crises. La conclusion est que Resolv "démontre une rigueur institutionnelle", est "conçu pour gérer les situations de crise via des mécanismes automatisés", et utilise "des composants vérifiés dans sa logique de mint et de rachat".

Ce rapport a influencé les décisions d'allocation d'autres curateurs, qui s'en sont appuyés pour justifier leur exposition aux marchés Resolv. Or, Steakhouse elle-même n'avait aucune exposition directe au USR.

Une évaluation de risque qui influence l'exposition d'autres acteurs tout en exemptant son auteur de cette même exposition pose une question de cohérence. Et surtout, une évaluation qui valide la rigueur opérationnelle d'un protocole à quelques jours d’un hack répond-elle au standard attendu d'un risk manager dans ce rôle ?

Un modèle souvent critiqué

Les curateurs ont souvent été pointés du doigt pour certains comportements problématiques, notamment au cours des derniers mois. L’affaire Resolv rappelle une nouvelle fois que ces questionnements étaient justifiés.

Concrètement, le modèle des curateurs contient en lui-même un dilemme permanent entre rendement, croissance des encours et prudence. Concrètement, un curateur attire du capital parce qu’il affiche un rendement compétitif, une bonne réputation et une allocation perçue comme plus efficace que celle de ses concurrents.

Néanmoins, la compétitivité dans le secteur des curateurs pousse les acteurs à mécaniquement rechercher des marchés plus rémunérateurs, donc souvent plus complexes, plus récents ou plus fragiles, afin de se rendre plus attractifs.

Tant que tout se passe bien, le modèle semble vertueux. Les dépôts augmentent, les revenus du curateur aussi, et le protocole sous-jacent y gagne en TVL et en activité. Mais cette dynamique peut aussi encourager une forme de dérive progressive, où le risque devient secondaire face à la nécessité de rester attractif.

C’est d’autant plus vrai que la majorité des utilisateurs ne choisissent pas un vault après avoir audité le protocole sous-jacent, le design des oracles, la structure des rôles admin ou les conditions de pause d’urgence (spoiler : ce rôle est censé appartenir aux curateurs). En réalité, beaucoup choisissent un actif reconnu et un APY intéressant sur l’interface. Le curateur bénéficie indirectement d’un transfert de confiance considérable, souvent disproportionné par rapport au niveau réel de diligence exercé sur chaque marché.

---

Ce que l’affaire Resolv implique pour les curateurs

Ce que l’épisode Resolv met en lumière, c’est que le métier de curateur ne peut plus se limiter à faire du screening initial et à publier une thèse de risque en amont. Ce n’est plus suffisant. Par ailleurs, il est nécessaire que les acteurs de l’industrie exigent et apportent plus de transparence, ne serait-ce que pour les utilisateurs.

La finance on-chain se professionnalise, et tout le monde s’en félicite. Néanmoins, il est grand temps que les acteurs principaux de cet écosystème se mettent également au niveau si l’on souhaite un jour sortir de notre microcosme pour onboard le fameux milliard d’utilisateurs que chacun nous rabâche depuis toujours.

À commencer par les curateurs, dont les responsabilités sont claires :

• La première est une responsabilité de sélection. Allouer vers un marché revient à lui accorder une forme de validation implicite. Cela suppose donc d’analyser non seulement la logique économique du protocole, mais aussi ses dépendances opérationnelles : architecture des rôles, gestion des clés, présence de caps on-chain, logique de pause, fonctionnement des oracles, scénarios de compromission administrative.
• La deuxième est une responsabilité de surveillance. Un marché ne doit pas seulement être jugé “acceptable” au moment T. Il doit être surveillé en continu, avec une capacité à détecter rapidement une rupture de régime. Un stablecoin qui s’effondre sur le secondaire, une utilisation qui explose anormalement, une divergence entre la valeur de marché et la valeur retenue par l’oracle : ce sont précisément les signaux qui devraient suspendre immédiatement l’allocation automatique.
• La troisième est une responsabilité d’intervention. Un curateur digne de ce nom doit être en mesure de couper l’exposition rapidement, ou au minimum de bloquer tout nouvel afflux de capital. Sinon, il ne gère pas réellement le risque, mais l’accompagne passivement.
• La quatrième, enfin, est une responsabilité de cohérence. Il est de plus en plus difficile pour les curateurs de produire un discours public sur la gestion du risque tout en opérant des systèmes incapables de se comporter différemment lorsque le risque se matérialise. À mesure que la DeFi mûrit, cette incohérence sera de moins en moins tolérée.

---

Les autres protocoles impactés

L'effondrement de l'USR ne s'est pas cantonné à Resolv. Parce que l'USR et ses dérivés étaient intégrés comme collatéral dans de nombreux protocoles, le depeg a déclenché une série d'impacts en cascade.

• Morpho (vaults Gauntlet, Re7, MEV Capital, 9summits, et al.) : 6,2 millions de USDC de bad debt post-exploit via le Public Allocator. Gauntlet représente 96 % de cette somme. Un plan de compensation pour les déposants affectés a été annoncé.
• Fluid / Instadapp : exposition potentielle supérieure à 11 millions de dollars de bad debt, principalement due à un oracle également hardcodé. L'équipe a sécurisé des prêts court terme via des investisseurs et la core team pour couvrir 100 % des pertes. Resolv Labs s'est engagé à couvrir toutes les positions USR antérieures à l'exploit.
• Inverse Finance : le Risk Working Group a pausé le marché wstUSR-DOLA en 15 minutes. Malgré 10 millions de DOLA en dette active, les liquidations ont fonctionné correctement. Bad debt résiduelle : 340 060 DOLA. Exemple de réactivité opérationnelle à retenir.
• Euler Finance : exposition sur les vaults RLP/USR sur Arbitrum. Allocations gelées, marchés pausés. Pas de chiffre de perte définitif communiqué au moment de l'écriture.
• Stream Finance : détient environ 13,6 millions de tokens RLP sur Morpho, pour une exposition nette d'environ 17 millions de dollars aux prix pré-exploit. RLP est la tranche junior de Resolv, la première à absorber les pertes. Pour rappel, Stream avait déjà annoncé 93 millions de dollars de pertes en novembre 2025. L'issue reste incertaine.
• Venus, Seamless, Lista DAO : exposition USR préventivement pausée. Pas de pertes confirmées.

---

Conclusion

L'incident Resolv n'est pas simplement l'histoire d’un hack ou d'une clé privée compromise. C'est l'histoire d'intermédiaires de confiance qui n'ont pas joué leur rôle au moment critique. Nous écrivions il y a plus d’un an que la DeFi n’avait pas aboli les intermédiaires, mais qu’elle les avait transformés.

Les curateurs sont ces nouveaux intermédiaires. Mais ce que cet incident révèle, c'est une opposition entre la promesse et la réalité. La promesse d’avoir des experts qui gèrent le risque à la place des utilisateurs s’est confrontée à la réalité de systèmes automatisés qui continuent d'alimenter des marchés en train d'imploser pendant des heures, sans que personne n'intervienne.

Et l’enjeu dépasse largement le cas de Resolv. Ce qui est en train de se jouer, c’est la crédibilité même de la finance on-chain. Avec OAK Research, nous défendons la thèse que l’avenir de l’industrie reposera sur la capacité à générer du rendement attractif sur des actifs fiables et sécurisés, et que pour cela, différentes couches d’acteurs vont émerger : des émetteurs, des apporteurs de liquidités, des distributeurs, des gestionnaires de rendement, des curateurs, etc.

Les curateurs occupent une place particulière dans cette architecture, parce qu’ils relient l’utilisateur final à cette complexité croissante. Ce sont eux qui transforment un empilement de risques techniques, de paramètres de marché et de dépendances croisées en un produit présenté comme simple. C’est précisément pour cela que, s’ils n’acceptent pas de se mettre à niveau, la finance on-chain est vouée à rester un écosystème d’expérimentation pour amateurs de risque.

Concrètement, cela signifie probablement plusieurs choses pour les prochaines années : des standards de due diligence plus élevés, des systèmes de monitoring en temps réel intégrés nativement, des circuit-breakers automatiques, davantage de transparence sur les méthodologies de risque, et peut-être, à terme, des mécanismes de responsabilité économique plus directs lorsque la négligence est avérée.