Since the beginning of this series, we have tried to separate facts from noise.

Several attacks have been presented as “Cosmos hacks” even though they involved smart contracts, bridges, or independent applications. The Cosmos Hub, ATOM, and IBC were not necessarily responsible.

This time, the situation is different.

Between August 20 and 22, 2026, several blockchains using Cosmos EVM were exploited or forced to halt their networks.

The Hub was not hacked. ATOM was not directly affected. But the vulnerability did concern an official component of the Cosmos Stack.

Several chains affected by shared infrastructure

Cosmos EVM makes it possible to add an Ethereum-compatible environment to a blockchain built with the Cosmos SDK. It provides access to Solidity, MetaMask, and EVM tooling while retaining Cosmos-specific features such as staking and IBC.

The technology is used or integrated by several networks, including MANTRA, TAC, KiiChain, Mezo, Stable, and the XRP Ledger sidechain.

This adoption demonstrates genuine commercial and technical interest in the Cosmos Stack. But shared infrastructure also creates shared risk.

MANTRA detected an attack on August 20. Two wallets belonging to its internal infrastructure were affected, with no reported losses for users. The chain was halted for approximately 30 hours before restarting with a patched binary. The team has since published a full incident report.

On August 22, KiiChain suffered 18 successive exploits. According to its official statement, the attacker withdrew 148.3 million KII before the chain was halted.

This nominal amount does not necessarily reflect the value actually sold or permanently lost. Some of the tokens reportedly remained frozen on the network. Nevertheless, the scale and repeated nature of the incident remain significant.

TAC also halted its network after an attacker exploited the Cosmos EVM precompile layer to drain one account. In its report, the team specified that the vulnerability was located in the shared module rather than in TAC-specific code.

Nesa also reported malicious activity linked to Cosmos EVM.

The technical details appear to vary between chains. We should therefore avoid claiming that every attack relied on exactly the same combination of flaws before Cosmos Labs publishes its overall incident report.

Patches published before the attacks

The public timeline nevertheless raises several questions.

Cosmos EVM versions v0.6.2 and v0.7.2 were released on August 19. The official GitHub repository stated that they contained important security fixes and recommended that chains upgrade quickly.

However, these updates were state-breaking. Chains therefore had to prepare a new binary, test it, and coordinate its activation with their validators.

MANTRA was attacked on August 20. KiiChain and TAC announced their incidents on August 22.

On August 24, Cosmos Labs issued a general warning, recommending that chains still running vulnerable versions halt block production and apply the patches.

This public timeline does not reveal which private warnings may have been sent earlier, which chains received them, or how urgently the risk was communicated.

KiiChain argues that the disclosure process did not give projects enough time to secure their networks. According to its team, publishing a patch in a public repository may also have allowed attackers to study the changes and reconstruct the vulnerability.

At this stage, that is KiiChain’s position. Cosmos Labs has announced that a full report will be published once the incident is completely contained.

That report should clarify:

• when the vulnerability was discovered;
• which chains were contacted before the patches were published;
• what level of risk was communicated;
• and why several networks had not yet applied the fixes when the attacks occurred.

As an operator, we know that a state-breaking upgrade cannot be installed instantly. It must be integrated, tested, and coordinated across the validator set.

That is precisely why the quality and timing of security warnings are just as important as the patch itself.

Already adopted, but not yet stable

Another point is worth remembering.

Cosmos EVM is still released under v0.x versions. Its official repository states that the code is still being audited and tested, that incompatible changes may occur, and that Cosmos Labs will only consider it stable with a future v1 release.

This does not mean projects should not use it. Many technologies are deployed before reaching their first stable version.

But it does add important context to adoption announcements.

The presence of major projects among Cosmos EVM’s users demonstrates real demand. It does not yet prove that the framework has reached full maturity.

Cosmos Labs is positioning its technology partly toward financial and institutional projects. For these clients, performance alone is not enough: stability, audits, communication, and emergency procedures are also part of the product.

The Hub was not hacked

We should also avoid going too far in the opposite direction.

The Cosmos Hub does not currently run Cosmos EVM. The cosmoshub-4 chain, ATOM balances, and the Hub’s consensus were not compromised. IBC has not been identified as the original cause of the attacks.

It would therefore be incorrect to say that “the Cosmos Hub was hacked.”

But it would be equally inaccurate to claim that the incident has nothing to do with Cosmos simply because it occurred on other chains.

Cosmos EVM is maintained by Cosmos Labs and presented as a strategic product within the Cosmos Stack.

The distinction matters: the Hub is not responsible for the incident, but the incident does concern an official Cosmos technology.

A direct consequence for the Hub’s future

Cosmos Labs is still exploring the possibility of placing an EVM within the Hub’s orbit, either directly on the chain or through an ATOM-powered sidechain.

A native EVM could create stronger links between applications, liquidity, and ATOM. It would also increase the Hub’s complexity and attack surface.

A sidechain would provide greater technical isolation, but it would preserve some of the ecosystem’s current fragmentation.

The August incident does not settle this debate. It does, however, introduce an essential requirement: any integration must rely on a sufficiently stable and audited version, supported by security procedures appropriate for the importance of the Hub.

The point is not to reject Cosmos EVM, but to ensure that technical timelines are not dictated solely by commercial expectations.

This time, FUD is not enough of an explanation

For several months, Cosmos has suffered from a constant mixture of real problems and exaggerated conclusions.

Some use every closure, departure, or hack to announce the death of the entire ecosystem. Others respond almost automatically that the Hub is still running and that the criticism is nothing more than FUD.

The Cosmos EVM incident fits comfortably into neither narrative.

It does not prove that the Cosmos Hub is dead. But this time, the vulnerability concerned a product maintained and promoted by Cosmos Labs. Several chains were exploited, and the coordination of the fixes is now the subject of legitimate questions.

Simply replying that “it was not the Hub” is therefore not enough.

The main damage may even extend beyond the losses directly observed. Cosmos Labs is currently building its new strategy around trust: institutional trust in the Cosmos Stack, project trust in Cosmos EVM, and ATOM holders’ trust in its ability to turn this adoption into activity for the Hub.

That credibility is now being tested.

ATOM is not technically responsible for the vulnerability. But its future partly depends on a roadmap led by Cosmos Labs. An incident affecting one of the company’s strategic products therefore inevitably influences how that roadmap is perceived.

The market does not always distinguish as precisely between the Cosmos Stack, Cosmos Labs, the Hub, and ATOM as we have tried to do throughout this series. A crisis affecting one can quickly influence the perception of the others.

That may not always be fair. Economically, however, it is a reality.

Since the beginning of this series, we have corrected accusations when Cosmos was blamed unfairly. We must apply the same standards when a vulnerability genuinely affects its code.

Cosmos Labs must now provide a complete timeline, explain its disclosure process, and demonstrate that its client chains can continue to entrust critical parts of their infrastructure to it.

The report will also test the more transparent communication Cosmos Labs has promised in recent months.

Being independent does not mean being systematically opposed. It means being able to acknowledge achievements, identify failures, and wait for the facts before assigning responsibility.

In the ninth and final article, we will return to the central question: is the Hub genuinely beginning to recover, or does its new value proposition still rely too heavily on trust that remains to be rebuilt?