Le 1er avril 2026, 16:05:18 UTC, un attaquant a soumis une transaction au Drift Protocol. Une seconde plus tard, une autre transaction l'a approuvée.
Douze minutes après, 285 millions de dollars avaient disparu. Dix-sept jours plus tard, un validateur compromis sur le pont de KelpDAO a à lui seul frappé pour 292 millions de dollars de jetons non soutenus, déclenchant en 48 heures une fuite d'environ 8,5 milliards de dollars depuis Aave et environ 4,5 milliards de dollars depuis d'autres protocoles DeFi.
Douze jours plus tard, un attaquant détenant la clé privée d'un déployeur volé a drainé 4,5 millions de dollars du Wasabi Protocol sur quatre chaînes.
Aucun de ces incidents n'était dû à l'exploitation d'une vulnérabilité de contrat intelligent.
Pendant plus de la moitié d'une décennie, le DeFi a cru que la sécurité était une question de code. Audit, vérification formelle, programme de bug bounty - toute l'industrie s'est organisée autour d'un postulat : tant que la logique du contrat intelligent est solide, le protocole est sécurisé. Les mathématiques font loi. Avril 2026 a été le mois où ce postulat s'est effondré en public.
Plus de 625 millions de dollars volés en un mois sur environ 30 incidents - selon DefiLlama, c'est le mois le plus piraté de l'histoire de la crypto en nombre d'événements - et chaque perte majeure remontait à une clé privée d'administrateur, un validateur de pont, un angle mort d'oracle ou une ingénierie sociale, tous des socles opérationnels que les audits n'ont jamais été conçus pour couvrir.
Cet article parle de cette migration. Nous décomposerons les trois graves piratages d'avril en trois visages d'un même échec sous-jacent, reviendrons sur la façon dont une mauvaise configuration de pont d'un protocole a déclenché une fuite de 13,2 milliards de dollars dans un protocole 25 fois plus gros, et examinerons de manière franche la véritable nature du DeFi aujourd'hui : c'est une infrastructure ouverte avec des leviers opérationnels de confiance, même si le marketing ne le dit pas. Le problème n'est pas dans les mathématiques.
Le problème est dans le « modèle mental » construit autour des mathématiques.
Les maths ne sont pas cassées. Ce qui est cassé, c'est le modèle mental superposé aux maths, et le prix de cette discordance force l'industrie à reconsidérer ce que signifie réellement la « décentralisation ».
L'écart de modèle mental
Pour la majeure partie de l'histoire du DeFi, la culture de sécurité dominante a été basée sur Solidity. Les audits examinent la logique des contrats. Les bug bounties paient pour les réentrances, les dépassements d'entiers, les erreurs de modificateurs d'accès. La vérification formelle prouve les invariants pour le code on-chain. L'hypothèse implicite était : tout ce qui est en dehors du contrat - les multisignatures, les clés privées des déployeurs, les validateurs de ponts, l'infrastructure de relais, les canaux de communication des équipes - était soit hors périmètre, soit le problème de quelqu'un d'autre.
Cette hypothèse ne tenait que tant que les attaquants exploitaient des vulnérabilités Solidity.
Les incidents de piratage d'avril 2026 partageaient une caractéristique structurelle qu'un rapport d'audit ne peut pas décrire : les contrats intelligents eux-mêmes n'avaient pas de vulnérabilités. Selon les analyses d'investigateurs on-chain indépendants, le code de Drift avait été audité par Trail of Bits en 2022 et par ClawSecure en février 2026, les deux fois avec succès.
Aucun des deux audits n'avait couvert la configuration de la multisignature de Drift, la logique de gestion des « durable nonces », ni la surface d'attaque d'ingénierie sociale autour de son Conseil de Sécurité. L'adaptateur LayerZero de KelpDAO était un code standard de modèle OFT, le contrat en soi n'avait rien de problématique. L'erreur était dans la configuration de déploiement, ce qui sort généralement du périmètre standard d'un audit Solidity.
Le contrat Vault de Wasabi était conçu pour être mis à niveau ; la conception elle-même était la vulnérabilité.
Ce qui a craqué en avril, ce ne sont pas les maths, c'est le socle opérationnel sur lequel les maths fonctionnent.
Trois autopsies : trois visages d'un même échec
Les trois graves incidents de piratage d'avril 2026 - Drift, KelpDAO, Wasabi - représentent trois types distincts d'« échec non-code ».
Ensemble, ils couvrent la plupart des nouvelles surfaces d'attaque, et partagent une caractéristique structurelle commune : dans chaque incident, un ou deux acteurs ou infrastructures compromis ont eu un effet domino sur l'ensemble du protocole.
Drift : La multisignature humaine (285 millions $)
Le piratage de Drift était une opération de renseignement, pas une exploitation de vulnérabilité. L'attaquant, attribué après analyse par TRM Labs, Elliptic et Drift lui-même avec l'aide de SEAL 911 au groupe nord-coréen Lazarus, spécifiquement la sous-unité UNC4736, déjà liée par Mandiant à l'attaque de Radiant Capital d'octobre 2024.
L'attaquant a passé environ six mois à planifier l'opération. L'ingénierie sociale a commencé lors de conférences industrielles à l'automne 2025, la préparation on-chain n'a démarré que trois semaines avant l'incident.
Le 11 mars 2026, l'opération a commencé avec 10 ETH sortis de Tornado Cash. Le lendemain, vers 9h00 heure de Pyongyang, ces fonds ont déployé le jeton CarbonVote (CVT) sur Solana. L'attaquant a créé un petit pool de liquidité sur Raydium, a effectué des wash trades sur le CVT pour ancrer son prix autour de 1$, puis a mis en place un oracle de prix qu'il contrôlait pour alimenter Drift avec ce prix artificiel.
Les wash trades existaient pour faire paraître « légitime » la sortie de l'oracle - toute vérification aléatoire trouverait le prix du marché aligné avec celui de l'oracle.
Pendant ce temps, l'attaquant s'est fait passer pour un fonds de trading quantitatif, passant des semaines à établir une relation avec des contributeurs de Drift. Le but n'était pas d'extraire des informations, mais de bâtir de la confiance en avance pour un moment précis.
Ce moment dépendait d'une fonctionnalité de Solana appelée « durable nonces » : un mécanisme légitime permettant de « signer aujourd'hui, exécuter plus tard ». Entre le 23 et le 30 mars, l'attaquant a obtenu des signatures de durable nonce d'au moins deux des cinq membres du Conseil de Sécurité de Drift.
Du point de vue des signataires, ils approuvaient des transactions de routine. Du point de vue du réseau, ces signatures étaient des justificatifs d'autorisation valides, dormants mais actifs.
Le 26 mars, Drift a pris une décision rétrospectivement catastrophique : migrer vers un tout nouveau Conseil de Sécurité multisignature 2-sur-5, avec un délai d'exécution (timelock) de zéro. Cette migration a supprimé la fenêtre de délai qui aurait pu permettre de détecter ou d'intervenir sur l'attaque.
Le 1er avril, 16:05:18 UTC, l'attaquant a soumis la première transaction pré-signée avec un durable nonce - une proposition pour transférer le contrôle administratif à l'adresse H7PiGqqUaanBovwKgEtreJbKmQe6dbq6VTrw6guy7ZgL. Une seconde plus tard, 16:05:19 UTC, une deuxième transaction pré-signée l'a approuvée et exécutée. L'attaquant avait pris le contrôle de Drift.
La suite a pris douze minutes. L'attaquant a listé le CVT sans valeur comme collatéral, avec une capacité d'emprunt quasi illimitée, déposé 500 millions de CVT au prix manipulé par l'oracle, puis retiré 285 millions de dollars d'actifs réels de trois coffres-forts (Vaults) principaux - JLP, USDC, SOL, cbBTC, wBTC, ETH. Le TVL de Drift s'est effondré de 550 millions de dollars à environ 250 millions. Deux signataires, un protocole, les contrats intelligents fonctionnant exactement comme conçu. La vulnérabilité était dans l'« humain ».
Un aspect de la réponse post-incident de Drift mérite d'être souligné, car il concerne la norme à laquelle les prochains protocoles victimes devraient aspirer : la divulgation de Drift elle-même a été exceptionnellement franche.
Cinq jours après la révélation de la faille, l'équipe a publié une analyse détaillée de l'attaque par ingénierie sociale - incluant les faits suivants : les contributeurs avaient été contactés à plusieurs reprises sur six mois ; au moins deux contributeurs avaient probablement été compromis via un clonage de dépôt de code et une version bêta TestFlight d'un portefeuille ; les conversations Telegram avec l'attaquant avaient été supprimées avant et après l'attaque ; la décision de migrer vers une multisignature sans délai six jours avant l'incident avait supprimé la dernière fenêtre de détection.
L'équipe a aussi publiquement attribué l'attaque avec une confiance moyenne (UNC4736 / Citrine Sleet), a coordonné avec SEAL 911, et a partagé des détails opérationnels pouvant aider d'autres protocoles à identifier les mêmes tactiques.
Les protocoles victimes reculent souvent dans la prudence juridique et la formulation vague ; Drift a choisi de publier un récit d'une qualité médico-légale qui peut transformer un incident isolé en renseignement de menace pour toute l'industrie. L'incident en soi reste un piratage, la faille de gouvernance sous-jacente reste une faille. Mais le fait d'être disposé à rendre public « comment l'ingénierie sociale a fonctionné » est précisément ce qui distingue les protocoles qui contribuent à l'apprentissage collectif de l'industrie, de ceux qui digèrent leurs pertes en silence.
KelpDAO : Le validateur unique (292 millions $)
Dix-sept jours plus tard, le 18 avril, le même profil de menace a produit une attaque structurellement totalement différente. KelpDAO est un protocole de restaking de liquidités, émettant le rsETH - un jeton représentant les dépôts des utilisateurs, acheminé via EigenLayer pour obtenir des rendements supplémentaires.
En avril 2026, le TVL du rsETH dépassait 10 milliards de dollars, déployé sur plus de 20 chaînes via la norme OFT (Omnichain Fungible Token) de LayerZero.
Le contrat n'avait pas de problème. La configuration, si.
Le pont de KelpDAO fonctionnait sur un DVN (Decentralized Verifier Network, réseau de vérificateurs décentralisés) 1-sur-1 - c'est-à-dire avec un seul validateur. Un seul nœud suffisait à approuver un message cross-chain. La « décentralisation » était un mot, pas une architecture.
L'attaque s'est déroulée en phases. L'attaquant a d'abord compromis le nœud RPC interne sur lequel le validateur s'appuyait pour lire l'état de la chaîne source, puis a lancé une attaque DDoS coordonnée contre des nœuds externes, forçant le système à revenir sur l'infrastructure contaminée. Avec la source de données sous son contrôle, ils ont forgé un message cross-chain, ordonnant au contrat de KelpDAO sur Ethereum mainnet de frapper du rsETH contre une « brûlure qui ne s'était jamais produite sur aucune chaîne source ».
À 17:35 UTC, le contrat a libéré 116 500 rsETH - d'une valeur d'environ 292 millions de dollars, soit environ 18% de l'offre en circulation du jeton - vers une adresse contrôlée par l'attaquant. En quelques minutes, ces rsETH ont été déposés comme collatéral sur Aave, chaque jeton étant valorisé à environ 2 500$.
L'attaquant a emprunté du WETH, de l'USDC, du wBTC réel contre ce collatéral non soutenu, retirant finalement plus de 82 600 ETH (environ 191 millions de dollars) avant que KelpDAO ne suspende le contrat à 18:21 UTC.
Deux tentatives ultérieures à 18:26 et 18:28 UTC, chacune visant à drainer 40 000 rsETH supplémentaires, ont été annulées. La suspension a arrêté les pertes ultérieures, mais pas la première.
Pas de vulnérabilité de réentrance, pas de vérification d'accès manquante, pas de manipulation d'oracle dans la logique de Kelp elle-même. L'invariant comptable qui définit un pont - les actifs libérés sur la chaîne de destination doivent être égaux aux actifs brûlés sur la chaîne source - a été violé au niveau du système, pas au niveau de la transaction. Un nœud, des centaines de millions de pertes.
Ce qui a suivi a été une controverse publique : sur qui la responsabilité retombe-t-elle ? Le rapport post-incident initial de LayerZero a directement rejeté la faute sur Kelp, arguant que Kelp avait violé les directives en choisissant un DVN 1-sur-1. Le mémoire de Kelp du 5 mai dessinait un tableau différent : à l'époque, 47% des contrats OApp LayerZero actifs - environ 1 250 applications, avec une capitalisation combinée de plus de 45 milliards de dollars - fonctionnaient avec la même configuration à validateur unique.
Kelp a soutenu : le OFT Quickstart de LayerZero lui-même, les exemples GitHub et les modèles pour développeurs, expédiaient le DVN propre à LayerZero Labs comme validateur obligatoire par défaut, et sans second ; et a présenté des captures d'écran de Telegram d'employés de LayerZero disant à l'équipe Kelp pendant deux ans et demi, lors de huit discussions d'intégration, que « les valeurs par défaut étaient OK ».
Le chercheur en sécurité Sujith Somraaj (ancien auditeur de LayerZero) avait soumis un rapport de bug bounty à Immunefi décrivant précisément ce mode d'attaque, rejeté par LayerZero au motif que « le choix du réseau de validateurs relève de la configuration de la couche application ».
La réponse de LayerZero au mémoire de Kelp a été : cette caractérisation est trompeuse. L'exclusion des « configurations de couche application » des bug bounties est une frontière standard « plateforme / application » (un porte-parole de LayerZero a noté qu'autrement, « toute application pourrait se définir comme DVN unique, et percevoir malicieusement des récompenses ») ; la valeur par défaut du protocole pour presque tous les chemins est en réalité multi-DVN ; et pour les modèles qui présentaient un 1-sur-1, le DVN unique pointait vers un contrat de remplacement appelé « DeadDVN » qui rejetait tous les messages, forçant les développeurs à configurer eux-mêmes leur pile de sécurité avant la mise en ligne.
Concernant Kelp, LayerZero a indiqué que Kelp avait initialement déployé un multi-DVN, et l'avait rétrogradé manuellement plus tard en 1-sur-1 - pas « utilisé les valeurs par défaut ».
La frontière plateforme vs. application est bien un point de désaccord réel, sur lequel des ingénieurs raisonnables peuvent diverger quant à savoir si « une plateforme dont les modèles peuvent être configurés dans un état dangereux est responsable de la configuration réellement déployée par l'utilisateur ».
Ce qui est moins discutable, c'est la seconde partie de la réponse finale de LayerZero. Le 8 mai, trois semaines après le premier rapport post-incident, LayerZero a fait volte-face et s'est excusé : « Nous avons fait une erreur en permettant à notre DVN de fonctionner comme un DVN 1-sur-1 pour des transactions à haute valeur. Nous n'avons pas contraint notre DVN sur ce qu'il protégeait. »
Le protocole a cessé de supporter le 1-sur-1 au sein du système DVN, a migré la valeur par défaut vers 5-sur-5, a relevé le seuil de sa propre multisignature de 3-sur-5 à 7-sur-10, et a annoncé une nouvelle plateforme de surveillance pour les émetteurs (Console).
Que la configuration sous-jacente ait été la faute de Kelp, celle de LayerZero, ou - plus probablement - un échec partagé entre une plateforme expédiée dans un état potentiellement dangereux et un intégrateur ayant rétrogradé activement, les réponses finales des deux parties ont convergé vers la même réponse : la validation 1-sur-1 n'est pas sûre à l'échelle, et l'industrie n'aurait pas dû avoir besoin de 292 millions de dollars pour l'apprendre.
Wasabi : La clé privée d'administrateur (4,5 millions $)
Wasabi le 30 avril était d'un ordre de grandeur inférieur aux deux autres, et donc d'autant plus embarrassant. C'était un « piratage ennuyeux ».
Un EOA (compte externe) de déployeur - l'adresse 0x5c629f8c0b5368f523c85bfe79d2a8efb64fb0c8 - détenait le rôle ADMIN_ROLE dans le gestionnaire de contrats perpétuels de Wasabi déployé sur les chaînes Ethereum, Base, Blast et Bera. Pas de multisignature. Le framework de contrat supportait un timelock, mais la valeur configurée était zéro.
L'attaquant a obtenu cette clé privée - phishing, compromission d'appareil, attaque de la chaîne d'approvisionnement sont tous possibles, Wasabi n'a pas donné de conclusion définitive. Avec le rôle ADMIN_ROLE, ils ont attribué le même rôle à un contrat auxiliaire malveillant, ont effectué une mise à niveau proxy UUPS sur le contrat Vault, et ont siphonné les collatéraux et soldes des pools. Pertes totales cross-chain : 4,5 - 5,5 millions de dollars.
Wasabi n'a utilisé aucune nouvelle technique. Cette vulnérabilité est dénoncée depuis des années comme un anti-modèle du DeFi : concentration excessive des droits d'administration, absence de séparation des pouvoirs, pas de fenêtre de délai. C'est la même vulnérabilité que le DeFi a subie, a écrit des rapports post-mortem dessus, et n'a toujours pas corrigée dans la pratique depuis 2020.
En liant les trois incidents : au fond, c'était le même type de piratage. Que l'accès privilégié ait été obtenu en manipulant des signataires, en piratant un nœud validateur, ou en volant une clé privée de déployeur, la surface d'attaque était la même - une concentration de pouvoir non protégée en dehors de la couche des contrats intelligents. Ce schéma est aussi un avertissement : dans chaque incident, une ou deux entités compromises ont déclenché une chaîne domino qu'aucune fortification Solidity n'aurait pu arrêter.
Le domino asymétrique
La raison pour laquelle l'incident KelpDAO a dépassé sa signification purement monétaire, c'est ce qui s'est passé après - c'est le premier test de résistance réel de la composabilité du DeFi face à un échec opérationnel - et aussi le cas d'école à ce jour le plus parlant sur « à quel point les mathématiques de la contagion sont asymétriques de façon absurde ».
Posons les échelles : au moment des faits, le TVL du rsETH de KelpDAO était d'environ 10 milliards de dollars ; l'actif sous gestion (AUM) d'Aave sur toutes les chaînes dépassait 250 milliards de dollars. Un protocole représentant environ 4% de la taille d'Aave a, par un seul incident, drainé 8,45 milliards de dollars d'Aave en 48 heures - ce chiffre a grimpé à 15,1 milliards en trois jours et demi - tandis que le TVL total du DeFi a baissé de 13,21 milliards de dollars dans cette fenêtre de 48 heures. L'asymétrie est la vraie histoire.
Un petit protocole avec une mauvaise configuration de pont a déclenché une ruée bancaire sur un protocole bien plus grand, qui fonctionnait « selon ses spécifications » selon toutes ses propres métriques de contrat.
Lorsque l'attaquant a frappé le rsETH non soutenu et l'a déposé sur Aave, les contrats d'Aave ont exécuté exactement selon leurs spécifications. Son oracle, pendant la brève fenêtre où l'attaquant a emprunté, lisait toujours le rsETH comme proche du ratio 1:1. Les pools de prêt ont libéré du WETH réel, contre un collatéral qui paraissait « valide » à tous les systèmes on-chain.
La réaction du marché a été immédiate. Le rsETH s'est négocié avec une décote importante sur les DEX en quelques heures, reflétant une incertitude réelle - les 82% restants de l'offre étaient-ils encore pleinement soutenus ? Aave V3 et V4 ont gelé les marchés du rsETH ; Fluid, Compound, Euler, Morpho ont suivi en quelques heures (SparkLend l'avait déjà retiré en janvier).
Les détenteurs de rsETH sur Arbitrum, Base, Mantle, Linea, Blast, Scroll avaient désormais un jeton dont ils ne pouvaient plus être sûrs qu'il était convertible 1:1 vers la garde sur Ethereum mainnet.
La fuite de capitaux qui a suivi n'était pas due à un piratage d'Aave, mais à l'incapacité des déposants à déterminer si le collatéral garantissant leurs prêts était encore solvable.
Les semaines précédant l'incident, Aave avait accumulé une position importante en rsETH, car les utilisateurs utilisaient l'effet de levier pour des trades de restaking ; le protocole en tirait des frais, sans plafonner cette exposition. Ainsi, cette contagion n'était pas une pure logique de « témoin innocent » - Aave avait choisi de prendre un risque de contrepartie - mais l'événement déclencheur était en dehors de ses propres contrats, et en dehors de la portée de sa propre gouvernance.
La réponse d'Aave à cet incident mérite d'être notée séparément, car elle établit une norme à laquelle les autres grands protocoles de prêt seront comparés. Quelques heures après la révélation de l'incident, l'administrateur d'urgence du protocole a gelé les marchés du rsETH sur tous les V3 et V4 des chaînes affectées, a fixé le LTV à zéro, contenant ainsi les pertes ultérieures.
En 48 heures, le fournisseur de services d'Aave a publié un rapport d'incident détaillé sur le forum de gouvernance, modélisant publiquement deux scénarios différents de créances douteuses - si Kelp socialisait la perte parmi tous les détenteurs de rsETH, 123,7 millions de dollars de créances douteuses ; si la perte était isolée aux déploiements L2, 230,1 millions de dollars - avec une ventilation par chaîne indiquant quels marchés assumeraient quels déficits.
Le fondateur d'Aave, Stani Kulechov, s'est personnellement engagé à fournir 5 000 ETH pour le recouvrement ; l'alliance DeFi United, menée par le fournisseur de services d'Aave et réunissant Lido, EtherFi, LayerZero, Mantle, etc., a réuni des engagements de plus de 300 millions de dollars pour combler le déficit du rsETH. C'est la plus grande opération de sauvetage inter-protocole de l'industrie à ce jour.
La partie critique est plus étroite et doit être considérée séparément de la réponse : la position d'Aave a évolué au fur et à mesure que la fourchette de créances douteuses devenait claire. L'engagement initial que sa réserve Umbrella couvrirait le déficit s'est assoupli en quelques jours pour devenir « explorer les voies pour combler le déficit ». La dérive narrative, bien que mineure, est notable - l'assurance au niveau du protocole qui semble catégorique dans un contexte abstrait devient négociable une fois que les chiffres sont concrets.
Le fait qu'Aave ait bien géré l'opérationnel ne change pas la réalité structurelle : les déposants mettant de l'USDC dans le protocole ont assumé un risque de contrepartie sur un jeton dont ils ignoraient peut-être l'existence, et le mécanisme d'assurance du protocole s'est révélé moins contraignant que ce que la documentation laissait entendre.
C'est le problème structurel plus profond. La conception à pool unique qui donne à Aave sa liquidité profonde et son expérience utilisateur épurée signifie aussi qu'une mauvaise liste de collatéraux a un rayon d'explosion au niveau de l'ensemble du protocole. Même avec une gouvernance diligente et des contrats robustes, le protocole reste en aval d'un échec de sécurité d'une contrepartie bien plus petite - et cette exposition en aval est suffisante pour mettre sous pression les fonds des déposants à neuf chiffres et déclencher le gel des marchés dans neuf protocoles.
La composabilité qui a soutenu la croissance du DeFi est aussi son canal de transmission de la contagion, et avril 2026 a été la première fois que cette facture a été payée à grande échelle. La correction n'est pas évidente. La composabilité qui a autrefois alimenté la croissance du DeFi est devenue le canal par lequel l'échec opérationnel d'un protocole se transforme en ruée bancaire sur un autre.
La vérité sur l'OpenFi
Nous tournons autour d'une conversation que l'industrie a évitée.
Appelons cela l'OpenFi : une infrastructure financière à accès sans permission, auditable on-chain, mais qui, sur les points critiques où le raisonnement décentralisé initial disait qu'il fallait supprimer les intermédiaires, dépend opérationnellement de tierces parties de confiance. Par cette définition, la plupart de ce qui est aujourd'hui vendu sous le nom de DeFi est de l'OpenFi. Un Conseil de Sécurité ayant le pouvoir de transférer le contrôle administratif.
Un pont avec seulement un validateur 1-sur-1. Un EOA de déployeur avec un rôle ADMIN_ROLE cross-chain. Un jeton de gouvernance suffisamment concentré pour qu'une minorité patiente capture le trésor, comme Nouns. Chacun est une « couture de privilège » patchée dans un système censé être sans couture.
Il vaut la peine de se rappeler ce que disait l'argument original. Le calcul de « minimisation de la confiance » de Szabo, l'infrastructure « neutre et digne de confiance » de Buterin, l'insistance des Cypherpunks sur le fait que « la vie privée et la liberté exigent de supprimer, pas d'auditer, les intermédiaires » - ce n'était pas à propos de « transparence ». La transparence est nécessaire, et facile. La proposition vraiment difficile - celle qui justifie toutes les frictions de faire tourner une machine à états globale sur des dizaines de milliers de nœuds redondants - est que « aucune partie dans le système ne peut être contrainte, capturée, soudoyée ou piratée pour changer les règles ».
Un grand livre public que vous pouvez inspecter mais pas influencer, et un grand livre public dont la clé privée d'administrateur se trouve dans un portefeuille matériel dans le coffre-fort de quelqu'un, sont deux choses différentes. L'OpenFi a tenu la première moitié du marché, et a tranquillement abandonné la seconde.
Différents protocoles dépendent de différents types de confiance, avec des modes d'échec différents.
Il est utile de les nommer : confiance de custodie (quelqu'un détient le vrai actif pour vous, vous négociez une créance sur celui-ci - ponts, jetons wrapped) ; confiance de mise à niveau (quelqu'un peut modifier le comportement du contrat après votre dépôt - administrateurs de proxy, Conseil de Sécurité) ; confiance d'oracle (quelqu'un fournit des données que le contrat ne peut pas produire lui-même - flux de prix) ; confiance de vivacité (le fonctionnement du système dépend de quelqu'un qui continue à opérer - séquenceurs, relais, keepers) ; confiance de gouvernance (les détenteurs de jetons, ou le petit sous-ensemble pouvant atteindre le quorum lors d'un vote controversé).
La plupart des protocoles dépendent de trois ou quatre de ces types simultanément. La plupart des textes de marketing les réduisent tous en un seul mot, « décentralisation », laissant le lecteur deviner le reste.
Le problème plus grand est que certaines de ces hypothèses sont complètement cachées. LayerZero, dans ses excuses de mai, a admis qu'il y a trois ans et demi, l'un de ses signataires multisignature avait effectué une transaction personnelle avec un portefeuille matériel de production. Cette erreur, corrigée en interne, n'a jamais été divulguée aux utilisateurs, et a finalement émergé comme partie d'une annonce de renforcement, présentée comme un nettoyage de routine plutôt qu'un aveu. Les utilisateurs du système de confiance n'avaient aucun moyen de le savoir, ni aucun moyen de valoriser le risque que « cela se soit réellement produit ».
L'industrie a un euphémisme pour cet écart : les « petites roues ». L'argument de vente est que les clés privées d'administrateur et les Conseils de Sécurité sont transitoires - existent aujourd'hui, seront retirés une fois le protocole assez mature pour marcher seul. En pratique, les petites roues ne sont presque jamais retirées. Elles sont renommées, reconditionnées, reconduites, ou tranquillement transférées à une fondation.
Le cadre Stage 0 / Stage 1 / Stage 2 de L2Beat est l'exception la plus propre, une preuve d'existence que « cette industrie peut, si elle le veut, décrire honnêtement ses hypothèses de confiance réelles ». Qu'à peine un protocole n'adopte le langage de L2Beat dans son marketing est en soi la preuve que « la malhonnêteté est structurelle, pas accidentelle ».
C'est une réalité d'ingénierie, façonnée à chaque niveau par les incitations auxquelles les bâtisseurs font réellement face. Si vous voulez lancer rapidement un produit complexe, pouvoir répondre aux vulnérabilités sans forker le protocole, supporter de nouveaux types de collatéraux, vous intégrer au reste de l'écosystème, vous avez besoin de leviers opérationnels.
Les contrats complètement immuables, sans accès privilégié, sont robustes, mais aussi fragiles - tout changement nécessite une migration complète, toute vulnérabilité devient permanente, toute nouvelle fonctionnalité exige que les utilisateurs réadoptent un nouveau déploiement. Au-delà des facteurs techniques, il y a une réalité : les calendriers des VC ne permettent pas des cycles de vérification formelle de trois ans, et les protocoles qui lancent en premier captent la liquidité en premier.
La composabilité aggrave le problème : un protocole immuable ne peut pas intégrer de nouvel oracle, supporter une nouvelle chaîne, corriger une vulnérabilité découverte, sans forcer tous les utilisateurs et intégrateurs à migrer.
Le résultat est : pour toute équipe individuelle, le choix rationnel est de « lancer avec une clé privée d'administrateur, promettre de la retirer plus tard » ; pour tout utilisateur individuel, le choix rationnel est d'accepter ce compromis, car les protocoles alternatifs n'existent pas ou n'ont pas de liquidité. L'OpenFi n'est pas un échec moral de bâtisseurs individuels. C'est l'équilibre de Nash de cet espace.
La formulation honnête est : le DeFi a presque universellement choisi d'échanger une partie de la décentralisation contre la faisabilité opérationnelle. Ce choix est défendable. La malhonnêteté réside dans le fait de ne pas nommer le compromis, et de continuer à commercialiser les protocoles comme « décentralisés » alors que leur modèle de sécurité réel dépend de quelques signataires, d'un validateur, ou d'une multisignature pouvant être compromise par de l'ingénierie sociale.
La voie à suivre ressemble plus à la « divulgation » qu'à la « révolution » : étiquetage obligatoire des hypothèses de confiance sur le modèle de L2Beat ; des délais d'exécution suffisamment longs pour que les utilisateurs puissent sortir avant qu'une opération privilégiée ne soit finalisée ; des marchés d'assurance qui valorisent le « risque opérationnel » plutôt que le fictif « risque pur code » ; et une séparation lucide entre « quelles parties du système ont réellement besoin d'une voie de mise à niveau » et « quelles parties sont simplement devenues mutables par habitude architecturale ». Avril 2026 n'a pas prouvé que l'OpenFi était irréalisable.
Il a prouvé que : vendre un système OpenFi comme du DeFi laisse ses utilisateurs totalement non préparés à ses modes d'échec réels. Pour rendre ce genre de système sûr, la première étape est d'admettre honnêtement que c'est ce que nous construisons.
La pièce à deux faces de la centralisation
Le compromis central de l'OpenFi est devenu visible dans l'incident de gel d'Arbitrum. Trois jours après l'exploitation de la faille de KelpDAO, le Conseil de Sécurité d'Arbitrum a voté le gel de 30 766 ETH - environ 71 millions de dollars - que l'attaquant avait déjà transférés sur Arbitrum One. Le gel a été coordonné avec les autorités, et par la plupart des standards, c'est un bon résultat : les fonds volés ont été empêchés d'être blanchis, les canaux en aval de l'attaquant ont été fermés, une partie des pertes des utilisateurs pourra peut-être être récupérée.
Mais remarquez ce qui a rendu ce gel possible : Arbitrum a un Conseil de Sécurité ayant le pouvoir de « mettre la main dans les transferts on-chain ». Ce n'est pas une caractéristique d'une infrastructure décentralisée. C'est un interrupteur d'arrêt centralisé par conception - défendable sous le prétexte de « réponse d'urgence », utilisé de la manière même que les critiques craignaient - pas nécessairement mauvais, mais certainement aux conséquences importantes.
Le même type de mécanisme qui a permis à Arbitrum de jouer les « bons » après l'incident Kelp est exactement la même forme de mécanisme qui a causé la compromission de Drift - une poignée de signataires de confiance, détenant le pouvoir d'exécuter des opérations au niveau du protocole, différant seulement par la force des contraintes sur ce pouvoir. Une fois, ce pouvoir a été utilisé légitimement pour geler des fonds volés ; une autre fois, il a été détourné par ingénierie sociale pour vider les dépôts des utilisateurs. Le levier coupe des deux côtés.
Les « interrupteurs d'arrêt » ont échoué par au moins cinq canaux différents - ingénierie sociale (Ronin, Drift), personnel interne compromis (Multichain), coercition souveraine, contrainte légale (Tornado Cash, USDC), et capture de gouvernance (Beanstalk, Mango Markets). Chacun est une attaque différente, avec des défenses différentes, que l'expression « le Conseil a échoué » masque toutes. Pointer le canal d'échec spécifique est la première étape pour commencer à le défendre.
C'est la « pièce à deux faces de la centralisation » dans le DeFi, et la chose la plus importante sur l'état actuel de cette industrie : chaque levier opérationnel qui peut produire un « bon résultat » en cas d'urgence est aussi une surface d'attaque - qui produira un mauvais résultat dans un autre incident.
La question plus profonde est : dans le cas d'Arbitrum, le mot « bon résultat » en porte beaucoup. La légitimité est socialement construite, et des leviers de même forme ont été actionnés dans des contextes où le consensus était bien moins clair. Le fork du DAO d'Ethereum en 2016 reste un cas d'école : la moitié de la communauté a soutenu qu'inverser cette exploitation de 60 millions de dollars était l'usage le plus évident et légitime du consensus social ; l'autre moitié a soutenu que c'était une trahison fatale du « code is law », et a forkée pour continuer sous le nom d'Ethereum Classic.
Circle et Tether gèlent souvent des adresses USDC et USDT, parfois en réponse à des sanctions de l'OFAC, parfois sur simple soupçon, sans aucune voie de recours pour les utilisateurs affectés - le gel est présenté comme de la conformité, mais c'est essentiellement du pouvoir discrétionnaire. Le gel d'Arbitrum a fonctionné. Le fork du DAO, d'une certaine manière, a aussi fonctionné.
Les gels d'USDC fonctionnent quotidiennement. La question honnête n'est pas « un interrupteur d'arrêt peut-il produire un bon résultat », mais « qui décide de ce qui constitue un bon résultat » - et ce que les utilisateurs du protocole ont été réellement informés de ce processus décisionnel.
Aucune version du compromis ne peut « ne prendre que l'un ». Soit vous avez un interrupteur d'arrêt, et alors vous avez quelque chose qui peut être capturé, manipulé, victime d'ingénierie sociale ; soit vous n'en avez pas, et alors vous devez accepter que certains événements seront permanents, irrécupérables.
Ces leviers ne sont pas non plus interchangeables. Le Conseil de Sécurité d'Arbitrum peut rapidement transférer des fonds via un processus d'urgence à bas seuil - la combinaison « vitesse + étendue » rend le gel possible, mais cette même combinaison rend aussi le mode d'échec catastrophique si le Conseil lui-même est compromis.
Le levier de THORChain est plus étroit : il peut suspendre et recapitaliser via l'émission de RUNE, mais n'a pas le pouvoir de saisir ou de rediriger les actifs des utilisateurs. L'administrateur d'urgence d'Aave peut geler les marchés, ajuster les paramètres de risque, mais ne peut pas transférer les soldes des utilisateurs. L'arrêt d'urgence de MakerDAO est une sortie à sens unique, pas un outil de confiscation. Des formes différentes, des compromis différents, tous appelés « interrupteur d'arrêt » dans le langage courant. Un protocole prêt à être honnête sur son modèle de confiance doit à ses utilisateurs non pas des catégories, mais des formes spécifiques.
L'industrie a aussi tendance à éviter une autre distinction : celle entre les leviers « actionnés uniquement dans des circonstances extrêmes » et ceux « actionnés selon un rythme de routine ».
Bitcoin et Ethereum ont en principe tous deux des interrupteurs d'arrêt - une coordination suffisante entre nœuds, mineurs, validateurs et exchanges pourrait forker n'importe quelle chaîne demain. Ces deux chaînes sont toujours considérées comme des systèmes de confiance minimisée dignes de confiance parce que ce levier n'a presque jamais été actionné, et chaque action a un coût : une scission permanente de la communauté.
Cela fait dix ans depuis le fork du DAO, et cela reste l'événement le plus controversé de l'histoire d'Ethereum. Bitcoin n'a jamais connu de fork similaire.
Le levier existe, mais est crédiblement engagé à « ne pas bouger » sur les opérations de routine, et c'est précisément cette longue histoire d'abstention qui a donné au système sous-jacent un niveau de fiabilité qu'aucune caractéristique de conception seule ne peut conférer.
En revanche, le Conseil de Sécurité d'Arbitrum fonctionne sur un rythme de routine. Il vote régulièrement pour des mises à niveau. Il a exécuté des actions d'urgence avant le gel Kelp, et en exécutera d'autres après. Ce n'est pas une capacité dormante en réserve, mais un organe de gouvernance actif. La critique OpenFi s'applique avec bien plus de force aux « leviers actifs » qu'aux « leviers dormants », car l'abstention des leviers dormants est elle-même un signal - la confiance gagnée par un opérateur dont le seuil d'utilisation est très élevé est une confiance que le levier lui-même ne peut pas accorder. Les leviers actifs n'ont pas ce signal. Ils ne peuvent être évalués que sur leurs contrôles, et ces contrôles se sont avérés à plusieurs reprises insuffisants.
THORChain, après avoir subi une vulnérabilité en 2021, a adopté la voie « sans levier », critiquée pour l'absence de moyens d'intervention. Arbitrum a pris la voie « interrupteur d'arrêt » et a reçu des éloges. Les deux choix sont défendables. Aucun n'est gratuit. L'industrie doit arrêter de prétendre qu'on peut avoir les deux - et doit dire honnêtement aux utilisateurs lequel de ces compromis chaque protocole spécifique a réellement fait.
Un dernier tournant : ce compromis ne fait qu'empirer avec le temps, et dans une seule direction. Une fois qu'un protocole peut geler, les régulateurs et les tribunaux sont de plus en plus enclins à statuer qu'il « doit » geler. La capacité de gel de l'USDC, à l'origine un outil de conformité d'urgence, est devenue une réponse de facto aux notifications de l'OFAC et à une liste d'exécution étatique en constante expansion.
La décision de « lancer avec un interrupteur d'arrêt » est aussi la décision « d'hériter d'une liste d'utilisations obligatoires qui ne fera que croître tout au long de la vie du protocole », dont beaucoup d'utilisations ne sont pas alignées avec ce que la propre communauté du protocole soutiendrait. La position « sans levier » de THORChain n'est donc pas seulement un choix d'ingénierie, mais aussi une posture réglementaire - en excluant par avance la « possibilité de se conformer », elle exclut par avance « l'obligation de se conformer ».
Que cette posture puisse survivre à une pression continue des autorités est une question ouverte, mais l'asymétrie est réelle : les protocoles avec des leviers peuvent être forcés de les utiliser ; ceux sans ne le peuvent pas.
Pour les institutions en attente, cette honnêteté est plus importante que le marketing. Un interrupteur d'arrêt opérationnel avec une divulgation claire, accompagné d'une gouvernance documentée, d'une gestion des clés et d'une réponse aux incidents - c'est quelque chose qu'une équipe de gestion de fonds ou une compagnie d'assurance peut assurer. Un protocole prétendant à une confiance minimisée mais fonctionnant sur une multisignature 2-sur-5 sans délai ne l'est pas. Le premier est un choix d'ingénierie légitime. Le second est un risque que personne ne peut valoriser.
Ce qui va suivre
L'habitude des cycles de l'industrie est d'oublier. Chaque cycle de quatre ans réinvente les institutions que le DeFi était censé remplacer, se fait frapper, se souvient brièvement pourquoi les principes existaient, puis oublie à nouveau. Tout ce qui s'est passé en avril n'est pas sans précédent. C'est l'état final prévisible d'une industrie qui échange la commodité contre les principes sans nommer le compromis.
Trois décisions sont maintenant devant l'industrie, aucune ne peut être reportée plus longtemps.
Honneteté. Chaque protocole doit choisir publiquement quels leviers opérationnels il détient, et l'expliquer à ses utilisateurs. La version honnête du DeFi n'est pas celle qui se vend comme « décentralisée » tout en fonctionnant sur une multisignature 2-sur-5 sans délai, mais celle qui divulgue publiquement la composition de la multisignature, ses seuils, ses délais, et les conditions de déclenchement de chaque levier. Nommer le compromis, c'est ce qui rend le compromis viable.
Sécurité. Les audits ne sont pas la ligne de démarcation. Les protocoles qui survivront au prochain cycle traiteront la sécurité opérationnelle - clés, signataires, ponts, configuration, réponse aux incidents - comme une discipline de premier ordre, aussi importante que l'examen Solidity. La plupart des équipes la traitent encore comme un travail de logistique. Cette attitude ne sera plus tenable à partir du moment où les allocateurs de trésorerie commenceront à poser les questions qu'ils posent maintenant.
Allocation de capitaux. Les capitaux qui détermineront le prochain cycle sont assis sur les pensions, les allocateurs souverains, les trésoreries d'entreprise et les bilans d'assurance - ils observent. Ils n'ont pas besoin d'une confiance purement minimisée. Ils ont besoin d'un risque opérationnel qui peut être assuré. Les protocoles qui ressemblent davantage à des infrastructures critiques qu'à des expériences absorberont ce flux de capitaux. Les autres continueront avec les capitaux retail qu'ils ont toujours eus, regardant la vague institutionnelle les contourner.
Avril 2026 n'était pas une crise de sécurité. C'était le moment où le modèle mental de l'industrie s'est complètement fracturé, et le moment où les protocoles qui survivront ont commencé à se distinguer de ceux qui ne survivront pas.
