Dans la première partie de notre dossier d’été, nous avons posé une distinction essentielle : Cosmos Hub, ATOM, IBC, Cosmos SDK et les appchains Cosmos ne sont pas la même chose.

Ce n’est pas une nuance de puriste. C’est la différence entre une analyse correcte et un raccourci de marché.

Dans le post qui a relancé le débat, plusieurs hacks sont cités comme preuves que l’écosystème Cosmos serait en train de s’effondrer : Gravity Bridge, Secret Network, Quicksilver, Namada, THORChain, Saga, et d’autres.

Certains incidents sont réels. Certains sont graves. Certains montrent clairement des faiblesses de design, de maintenance, de monitoring ou de gouvernance technique.

La question n’est donc pas de savoir s’il y a eu des hacks. Il y en a eu.

La vraie question est : qu’est-ce qui a réellement cassé ?

Parce qu’un exploit sur un bridge, un vault, un smart contract modifié, un module applicatif, une intégration EVM ou une appchain souveraine n’a pas la même signification qu’une faille dans le Cosmos Hub ou dans IBC en tant que protocole central.

C’est moins spectaculaire qu’un post viral. Mais c’est plus utile pour comprendre le risque.

IBC n’est pas un bridge classique

IBC, ou Inter-Blockchain Communication, est un protocole d’interopérabilité. Il permet à des blockchains de communiquer et de transférer des données ou des actifs entre elles. La documentation officielle explique qu’IBC définit des structures de données, des abstractions et une sémantique permettant à différents registres distribués de communiquer, sous certaines conditions techniques. (docs.cosmos.network)

Le modèle repose notamment sur des light clients. Dans la documentation IBC, les paires de clients sont décrites comme une primitive de connexion : deux chaînes communiquent via une paire de light clients, une sur chaque chaîne. La documentation dédiée aux light clients précise aussi qu’IBC utilise ces clients légers pour fournir une interopérabilité trust-minimized entre blockchains souveraines. (docs.cosmos.network) (docs.cosmos.network)

Ce point est important, car beaucoup d’utilisateurs mettent tout dans le même panier : IBC, bridges, wrappers, smart contracts, vaults, minting contracts, relayers, front-ends et appchains.

En pratique, ce sont des couches différentes.

Cela ne rend pas IBC magique. Cela ne veut pas dire que toutes les applications construites autour d’IBC sont sûres. Cela veut simplement dire que si un contrat modifié, un registre d’actifs, un vault, un module applicatif ou une logique de minting est défectueux, il faut localiser la faille au bon endroit.

Même autoroute technique. Pas la même responsabilité.

Cosmos SDK : souveraineté, flexibilité, responsabilité

Le Cosmos SDK est un framework open source permettant de construire des blockchains applicatives. Sa documentation officielle le décrit comme un framework pour construire des blockchains application-specific et des digital ledgers, avec un haut niveau de contrôle sur l’access control, la sécurité, la logique métier et la gouvernance. (docs.cosmos.network)

Cette flexibilité est précisément ce qui a fait la force de Cosmos. Une équipe peut construire une blockchain spécialisée plutôt qu’une simple application sur une chaîne généraliste. Elle peut adapter des modules, ajouter des fonctionnalités spécifiques, choisir sa politique économique, gérer son set de validateurs, connecter IBC, intégrer un bridge, ajouter une couche EVM ou modifier des contrats.

Mais cette liberté a un prix. Chaque modification, chaque bridge, chaque contrat, chaque wrapper, chaque module spécifique et chaque intégration cross-chain ajoute une surface d’attaque.

La souveraineté ne signifie pas “sécurité garantie par défaut”. Elle signifie souvent : vous êtes libres de construire, mais vous êtes aussi responsables de ce que vous déployez.

C’est là que les incidents récents doivent être lus.

Le point commun : les couches ajoutées autour de Cosmos

Dans les cas documentés ici, les failles pointent surtout vers des couches ajoutées ou modifiées par les projets : bridges, contrats de minting, vaults, registres d’actifs, intégrations EVM, systèmes de signature ou modules applicatifs.

Les sources consultées ne montrent pas une compromission du Cosmos Hub ni une faille générale d’IBC core. Elles montrent plutôt une chose plus froide : quand des projets construisent des couches complexes autour de Cosmos, ces couches portent leurs propres risques.

Ce n’est pas anodin. Les bridges et les couches cross-chain complexes font partie des surfaces d’attaque les plus régulièrement exposées dans la crypto, comme le montrent les bases de données d’exploits et plusieurs incidents récents. DefiLlama suit par exemple les pertes liées aux hacks DeFi par type de technique et par catégorie, avec plusieurs milliards de dollars historiquement perdus sur des bridges. (defillama.com)

La critique pertinente n’est donc pas : “tout Cosmos est cassé”.

La critique pertinente est plutôt : certains projets ont construit des architectures complexes autour de Cosmos, parfois modifiées, parfois mal surveillées, parfois trop peu financées, et ces couches ont cédé.

Gravity Bridge : risque bridge, clé, contrat

Gravity Bridge est l’un des cas les plus cités. L’incident est réel : les rapports disponibles parlent d’environ 5,4 millions de dollars drainés en mai 2026. Les analyses publiques décrivent un retrait d’actifs depuis le contrat Ethereum principal de Gravity Bridge, avec des requêtes non autorisées validées par des signatures liées à une clé compromise. (beincrypto.com) (finance.yahoo.com)

Le classement du risque est donc clair : bridge, signature, contrat Ethereum-side.

C’est grave, parce qu’un bridge qui perd plusieurs millions de dollars touche directement la confiance des utilisateurs. Mais ce n’est pas le même type de risque qu’une faille de consensus ou qu’un arrêt du Cosmos Hub.

Secret Network : quand une implémentation autour d’IBC casse

L’exploit Secret / Axelar est probablement l’exemple le plus pédagogique, justement parce qu’il touche une connexion IBC et peut donc être facilement mal compris.

L’analyse de Common Prefix décrit un exploit sur un contrat CW20-ICS20 modifié déployé sur Secret Network. Le contrat n’aurait pas vérifié correctement le canal source des paquets IBC entrants avant de minter des tokens. Cela aurait permis à un attaquant de créer un canal contrôlé et de faire minter de vrais saTokens sans actifs réels en contrepartie. Le montant drainé est estimé autour de 4,67 millions de dollars. (commonprefix.com)

Crowdfund Insider rapporte également que l’attaquant aurait créé une fausse chaîne Cosmos et établi un canal IBC non autorisé vers un contrat CW20-ICS20 modifié sur Secret Network, dont les vérifications essentielles du source channel auraient été désactivées ou commentées. (crowdfundinsider.com)

Le problème décrit vient donc d’un contrat modifié côté Secret, qui ne validait pas correctement le canal source. C’est très grave, parce qu’un contrat responsable du minting d’actifs bridgés doit être extrêmement strict. Mais c’est précisément le genre d’incident qui montre la différence entre un protocole d’interopérabilité et une implémentation applicative construite autour de lui.

Une mauvaise implémentation autour d’IBC peut être catastrophique. Cela ne veut pas dire que tous les transferts IBC reposent sur cette même erreur.

THORChain : vault, node operator et signature threshold

THORChain est un autre cas souvent cité.

Le 15 mai 2026, THORChain a subi un exploit majeur. Le rapport officiel de THORChain indique qu’environ 10,7 millions de dollars ont été drainés depuis un vault, et que l’attaquant était un nouveau node operator ayant exploité une vulnérabilité du schéma de signature threshold GG20. (thorchain.org)

TRM Labs parle également de plus de 11 millions de dollars drainés à travers plusieurs chaînes, dont Bitcoin, Ethereum, BNB Chain, Base, Avalanche, Dogecoin, Litecoin, Bitcoin Cash et XRP. (trmlabs.com)

Ici, le sujet est l’architecture propre de THORChain : vaults, signatures threshold, opérateurs de nodes, mécanismes de sécurité cross-chain.

Cela rappelle une réalité connue : les protocoles cross-chain complexes portent une surface d’attaque élevée, surtout lorsqu’ils gèrent des actifs sur plusieurs réseaux avec des logiques de vaults et de signatures distribuées.

Quicksilver : qATOM n’est pas ATOM

Quicksilver est un autre incident cité dans le post initial.

SlowMist décrit une vulnérabilité de type Unchecked Proof Minting. Selon cette analyse, l’attaquant a forgé des preuves pour minter environ 505 000 qATOM et 10 millions de qOSMO non couverts. La chaîne a été arrêtée, et la perte réellement drainée aurait été limitée à environ 3 500 dollars. (hacked.slowmist.io)

DefiLlama Hacks liste également Quicksilver Zone parmi les incidents de juin 2026, avec une perte d’environ 3 500 dollars et une classification liée à une logique protocolaire. (defillama.com)

Ce cas montre à quel point les raccourcis peuvent être trompeurs.

La faille est grave : permettre le minting de tokens représentatifs sans collatéral valide est un problème critique. Mais qATOM n’est pas ATOM natif. Le fait qu’un protocole mint un qATOM non couvert ne signifie pas que l’ATOM du Cosmos Hub a été falsifié. Cela signifie que la logique applicative de Quicksilver a été exploitée.

Il faut donc séparer l’actif dérivé, la logique applicative et la chaîne sous-jacente.

Namada et SagaEVM : incidents réels, conclusions limitées

Namada a confirmé en juin 2026 enquêter sur un exploit de protocole. Les sources publiques indiquent que l’équipe travaille à clarifier l’incident, mais les détails techniques et l’impact financier complet ne sont pas publiquement établis de manière suffisamment claire au moment de notre analyse. (x.com) (binance.com)

C’est un signal négatif pour la confiance dans l’appchain concernée. Mais sans détails techniques complets, il faut éviter de transformer cet incident en conclusion générale sur tout Cosmos.

SagaEVM mérite aussi d’être séparé du bruit.

Un advisory publié sur le dépôt cosmos/evm indique qu’en janvier 2026, Cosmos Labs a été informé d’une activité suspecte sur un réseau utilisant une implémentation affectée, avec une perte financière sur Saga EVM Network. Le root cause identifié est une mauvaise gestion d’état dans des chemins d’exécution EVM imbriqués impliquant la precompile ICS20. (github.com)

Halborn explique également que le hack SagaEVM venait d’une vulnérabilité dans le code de precompile EVM hérité d’Ethermint, liée à l’usage d’une EVM forkée dans le protocole. (halborn.com)

Mélanger EVM, modules Cosmos, minting, precompiles et bridge logic augmente mécaniquement la surface d’attaque. C’est un vrai sujet technique, et il mérite d’être traité comme tel.

Le vrai problème : la surface d’attaque

Si l’on regarde ces incidents calmement, un pattern apparaît.

Gravity Bridge : bridge, clé, contrat Ethereum.
Secret : contrat CW20-ICS20 modifié et validation de canal insuffisante.
THORChain : vault, node operator, signature threshold GG20.
Quicksilver : minting non couvert via preuves forgées.
Namada : exploit protocolaire en cours de clarification.
SagaEVM : implémentation EVM, precompile, bridge minting.

Ce ne sont pas les mêmes causes. Ce ne sont pas les mêmes couches. Ce ne sont pas les mêmes responsabilités.

Le vrai sujet est que beaucoup de projets ont ajouté autour de Cosmos des bridges, des contrats, des modules EVM ou des logiques applicatives qui portent leurs propres risques. Et ces risques, dans la crypto, on les connaît depuis longtemps : les bridges et les couches cross-chain complexes sont des cibles privilégiées.

La question importante devient donc :

les projets Cosmos ont-ils toujours les moyens techniques, financiers et humains de maintenir correctement des architectures aussi complexes ?

C’est là que le lien avec notre première partie devient évident.

En période de liquidité faible, les équipes réduisent les coûts. Les audits deviennent plus difficiles à financer. Le monitoring peut être allégé. Les validateurs partent. Les relayers sont moins nombreux. Les front-ends vieillissent. Les contrats restent en production plus longtemps que prévu. Les upgrades sont repoussées. Les équipes pivotent.

Ce n’est pas propre à Cosmos. Mais dans Cosmos, cette complexité est plus visible, parce que beaucoup de projets portent leur propre chaîne, leur propre sécurité, leurs propres intégrations et leur propre logique applicative.

Le Hub subit aussi l’effet d’accumulation

Il serait trop facile de dire : “ces incidents sont externes au Hub, donc le sujet est clos.”

Ce n’est pas notre position.

Techniquement, les responsabilités doivent être placées au bon endroit. Mais commercialement et narrativement, l’effet d’accumulation existe.

Un utilisateur non technique ne se demande pas si la faille vient d’un contrat CW20-ICS20 modifié, d’un vault THORChain, d’une clé de bridge ou d’un module EVM. Il voit “Cosmos project hacked”. Puis un autre. Puis un autre.

Et le doute s’installe.

C’est injuste techniquement, mais réel commercialement.

C’est pour cela que l’écosystème doit mieux communiquer en cas d’incident : ce qui a été touché, ce qui ne l’a pas été, quels actifs sont concernés, quelle couche est responsable, et pourquoi l’impact ne doit pas être généralisé à tout l’écosystème.

Le silence, la confusion ou les explications trop tardives laissent le terrain au FUD.

Ce que cela implique pour les validateurs

Pour les validateurs et opérateurs, ces incidents rappellent une évidence : opérer une appchain n’est pas juste lancer un binaire et attendre les rewards.

Chaque chaîne a ses modules, ses risques, ses upgrades, ses bridges, ses relayers, ses paramètres de slashing, ses RPC, ses indexeurs et parfois ses contrats critiques.

Quand les revenus validateurs baissent et que le coût d’opération reste élevé, la tentation est forte de réduire l’effort. C’est précisément là que le risque augmente.

Un écosystème de chaînes souveraines ne peut pas fonctionner durablement si les projets n’ont pas les moyens de payer correctement la sécurité, les audits, les opérateurs, le monitoring et la maintenance.

La souveraineté coûte cher.

Et si personne ne paie ce coût, quelqu’un finit par le payer autrement.

Souvent l’utilisateur.

Conclusion : les hacks sont graves, l’amalgame est faux

Les hacks cités dans le post initial ne doivent pas être minimisés. Gravity Bridge, Secret / Axelar, THORChain, Quicksilver, Namada ou SagaEVM révèlent de vraies faiblesses dans certaines architectures, certains contrats, certains bridges, certains vaults et certaines implémentations.

Ils prouvent surtout une chose : dans un écosystème modulaire, chaque couche doit être comprise, auditée, maintenue et financée.

Cosmos donne aux projets la liberté de construire leur propre chaîne, leur propre logique et leurs propres connexions. Cette liberté crée de la puissance. Elle crée aussi de la responsabilité.

La vraie conclusion est donc plus froide : les incidents récents montrent que l’écosystème Cosmos doit mieux financer, mieux auditer, mieux monitorer et mieux expliquer ses couches critiques.

Ce n’est pas un enterrement du Hub.

C’est un rappel opérationnel.

Et pour un écosystème qui a fait de la souveraineté son argument principal, c’est probablement le rappel le plus important.