In the first part of our summer dossier, we laid out one essential distinction: Cosmos Hub, ATOM, IBC, Cosmos SDK and Cosmos appchains are not the same thing.

This is not a purist detail. It is the difference between proper analysis and a market shortcut.

In the post that reignited the debate, several hacks are cited as proof that the Cosmos ecosystem is collapsing: Gravity Bridge, Secret Network, Quicksilver, Namada, THORChain, Saga, and others.

Some of these incidents are real. Some are serious. Some clearly reveal weaknesses in design, maintenance, monitoring or technical governance.

So the question is not whether hacks happened. They did.

The real question is: what actually broke?

Because an exploit on a bridge, a vault, a modified smart contract, an application module, an EVM integration or a sovereign appchain does not have the same meaning as a failure in the Cosmos Hub or in IBC as a core protocol.

That is less spectacular than a viral post. But it is more useful if we want to understand the risk.

IBC is not a classic bridge

IBC, or Inter-Blockchain Communication, is an interoperability protocol. It allows blockchains to communicate and transfer data or assets between each other. The official documentation explains that IBC defines data structures, abstractions and semantics that allow different distributed ledgers to communicate, under specific technical conditions. (docs.cosmos.network)

The model notably relies on light clients. In the IBC documentation, client pairs are described as a connection primitive: two chains communicate through a pair of light clients, one on each chain. The light client documentation also explains that IBC uses these clients to provide trust-minimized interoperability between sovereign blockchains. (docs.cosmos.network) (docs.cosmos.network)

This matters because many users put everything into the same bucket: IBC, bridges, wrappers, smart contracts, vaults, minting contracts, relayers, front-ends and appchains.

In practice, these are different layers.

That does not make IBC magic. It does not mean every application built around IBC is safe. It simply means that if a modified contract, an asset registry, a vault, an application module or a minting logic is defective, the failure has to be located at the right layer.

Same technical highway. Different responsibility.

Cosmos SDK: sovereignty, flexibility, responsibility

Cosmos SDK is an open-source framework for building application-specific blockchains. Its official documentation describes it as a framework for building application-specific blockchains and digital ledgers, with a high level of control over access control, security, business logic and governance. (docs.cosmos.network)

That flexibility is precisely what made Cosmos powerful. A team can build a specialized blockchain instead of a simple application on a general-purpose chain. It can adapt modules, add specific features, choose its economic policy, manage its validator set, connect IBC, integrate a bridge, add an EVM layer or modify contracts.

But that freedom has a cost. Every modification, every bridge, every contract, every wrapper, every specific module and every cross-chain integration adds attack surface.

Sovereignty does not mean “security guaranteed by default”. It often means: you are free to build, but you are also responsible for what you deploy.

That is how the recent incidents should be read.

The common thread: layers added around Cosmos

In the cases documented here, the failures mostly point to layers added or modified by individual projects: bridges, minting contracts, vaults, asset registries, EVM integrations, signature systems or application modules.

The sources reviewed do not show a compromise of the Cosmos Hub or a general failure of IBC core. They show something colder: when projects build complex layers around Cosmos, those layers carry their own risks.

This is not trivial. Bridges and complex cross-chain layers are among the most regularly exposed attack surfaces in crypto, as shown by exploit databases and several recent incidents. DefiLlama, for example, tracks DeFi hack losses by technique and category, with billions of dollars historically lost on bridges. (defillama.com)

So the relevant critique is not: “all of Cosmos is broken”.

The relevant critique is closer to this: some projects built complex architectures around Cosmos, sometimes modified, sometimes poorly monitored, sometimes underfunded, and those layers failed.

Gravity Bridge: bridge, key, contract risk

Gravity Bridge is one of the most cited cases. The incident is real: available reports refer to roughly $5.4 million drained in May 2026. Public analyses describe asset withdrawals from Gravity Bridge’s main Ethereum contract, with unauthorized requests validated through signatures linked to a compromised key. (beincrypto.com) (finance.yahoo.com)

The risk classification is therefore clear: bridge, signature, Ethereum-side contract.

That is serious, because a bridge losing several million dollars directly damages user trust. But it is not the same type of risk as a consensus failure or a Cosmos Hub halt.

Secret Network: when an implementation around IBC fails

The Secret / Axelar exploit is probably the most useful example, precisely because it touches an IBC connection and can therefore be misunderstood easily.

Common Prefix describes an exploit on a modified CW20-ICS20 contract deployed on Secret Network. The contract allegedly failed to properly verify the source channel of incoming IBC packets before minting tokens. This allowed an attacker to create a controlled channel and mint real saTokens without real backing assets. The amount drained is estimated at around $4.67 million. (commonprefix.com)

Crowdfund Insider also reports that the attacker allegedly created a fake Cosmos chain and established an unauthorized IBC channel to a modified CW20-ICS20 contract on Secret Network, where essential source-channel checks had reportedly been disabled or commented out. (crowdfundinsider.com)

The problem described therefore comes from a modified contract on the Secret side, which did not properly validate the source channel. This is serious, because a contract responsible for minting bridged assets must be extremely strict. But it is exactly the kind of incident that shows the difference between an interoperability protocol and an application implementation built around it.

A bad implementation around IBC can be catastrophic. That does not mean every IBC transfer relies on the same mistake.

THORChain: vault, node operator and threshold signatures

THORChain is another frequently cited case.

On 15 May 2026, THORChain suffered a major exploit. THORChain’s official report states that around $10.7 million was drained from a vault, and that the attacker was a new node operator who exploited a vulnerability in the GG20 threshold signature scheme. (thorchain.org)

TRM Labs also reports more than $11 million drained across several chains, including Bitcoin, Ethereum, BNB Chain, Base, Avalanche, Dogecoin, Litecoin, Bitcoin Cash and XRP. (trmlabs.com)

Here, the issue is THORChain’s own architecture: vaults, threshold signatures, node operators and cross-chain security mechanisms.

It is a reminder of a known reality: complex cross-chain protocols carry a large attack surface, especially when they manage assets across several networks with vault logic and distributed signatures.

Quicksilver: qATOM is not ATOM

Quicksilver is another incident cited in the original post.

SlowMist describes an Unchecked Proof Minting vulnerability. According to that analysis, the attacker forged proofs to mint around 505,000 qATOM and 10 million qOSMO without backing. The chain was halted, and the amount actually drained was reportedly limited to around $3,500. (hacked.slowmist.io)

DefiLlama Hacks also lists Quicksilver Zone among June 2026 incidents, with a loss of around $3,500 and a classification related to protocol logic. (defillama.com)

This case shows how misleading shortcuts can be.

The vulnerability is serious: allowing representative tokens to be minted without valid collateral is a critical issue. But qATOM is not native ATOM. The fact that a protocol minted unbacked qATOM does not mean Cosmos Hub ATOM was falsified. It means Quicksilver’s application logic was exploited.

The derivative asset, the application logic and the underlying chain have to be separated.

Namada and SagaEVM: real incidents, limited conclusions

Namada confirmed in June 2026 that it was investigating a protocol exploit. Public sources indicate that the team was working to clarify the incident, but the full technical details and financial impact were not clearly established publicly at the time of our analysis. (x.com) (binance.com)

This is a negative signal for confidence in the affected appchain. But without full technical details, it should not be turned into a general conclusion about all of Cosmos.

SagaEVM also deserves to be separated from the noise.

An advisory published on the cosmos/evm repository states that in January 2026, Cosmos Labs was informed of suspicious activity on a network using an affected implementation, with financial loss on Saga EVM Network. The identified root cause was incorrect state management in nested EVM execution paths involving the ICS20 precompile. (github.com)

Halborn also explains that the SagaEVM hack came from a vulnerability in EVM precompile code inherited from Ethermint, linked to the use of a forked EVM inside the protocol. (halborn.com)

Mixing EVM, Cosmos modules, minting, precompiles and bridge logic mechanically increases attack surface. That is a real technical issue, and it should be treated as such.

The real issue: attack surface

If we look at these incidents calmly, a pattern appears.

Gravity Bridge: bridge, key, Ethereum contract.
Secret: modified CW20-ICS20 contract and insufficient channel validation.
THORChain: vault, node operator, GG20 threshold signatures.
Quicksilver: unbacked minting through forged proofs.
Namada: protocol exploit still under clarification.
SagaEVM: EVM implementation, precompile, bridge minting.

These are not the same causes. They are not the same layers. They are not the same responsibilities.

The real issue is that many projects added bridges, contracts, EVM modules or application logic around Cosmos, each carrying its own risk. And those risks are well known in crypto: bridges and complex cross-chain layers are favored targets.

The important question therefore becomes:

Do Cosmos projects still have the technical, financial and human resources required to properly maintain architectures this complex?

This is where the link with Part 1 becomes clear.

In a low-liquidity environment, teams cut costs. Audits become harder to finance. Monitoring can be reduced. Validators leave. Relayers become less numerous. Front-ends age. Contracts stay in production longer than expected. Upgrades get delayed. Teams pivot.

This is not unique to Cosmos. But in Cosmos, this complexity is more visible, because many projects carry their own chain, their own security, their own integrations and their own application logic.

The Hub also suffers from the accumulation effect

It would be too easy to say: “these incidents are external to the Hub, so the topic is closed.”

That is not our position.

Technically, responsibility has to be placed at the right layer. But commercially and narratively, the accumulation effect exists.

A non-technical user does not ask whether the failure came from a modified CW20-ICS20 contract, a THORChain vault, a bridge key or an EVM module. They see “Cosmos project hacked”. Then another. Then another.

And doubt settles in.

That may be technically unfair, but it is commercially real.

This is why the ecosystem needs better incident communication: what was touched, what was not touched, which assets were affected, which layer was responsible, and why the impact should not be generalized to the entire ecosystem.

Silence, confusion or late explanations leave room for FUD.

What this means for validators

For validators and operators, these incidents are a reminder of something basic: operating an appchain is not just launching a binary and waiting for rewards.

Each chain has its modules, risks, upgrades, bridges, relayers, slashing parameters, RPCs, indexers and sometimes critical contracts.

When validator revenues fall and operating costs remain high, the temptation to reduce effort is real. That is exactly where risk increases.

An ecosystem of sovereign chains cannot work sustainably if projects do not have the means to properly pay for security, audits, operators, monitoring and maintenance.

Sovereignty is expensive.

And if nobody pays that cost, someone usually pays it another way.

Often the user.

Conclusion: the hacks are serious, the shortcut is wrong

The hacks cited in the original post should not be minimized. Gravity Bridge, Secret / Axelar, THORChain, Quicksilver, Namada and SagaEVM reveal real weaknesses in certain architectures, contracts, bridges, vaults and implementations.

They mainly prove one thing: in a modular ecosystem, each layer has to be understood, audited, maintained and funded.

Cosmos gives projects the freedom to build their own chain, their own logic and their own connections. That freedom creates power. It also creates responsibility.

The colder conclusion is this: the recent incidents show that the Cosmos ecosystem needs to better fund, audit, monitor and explain its critical layers.

This is not a funeral for the Hub.

It is an operational reminder.

And for an ecosystem that made sovereignty its core argument, it is probably the most important reminder of all.