Short answer
The answer in plain English
The attacker exploited a mismatch between Cosmos vesting balances and the smaller spendable balance seen by Cosmos EVM. Subtracting a valid delegation from that smaller unsigned value caused an underflow to an enormous number. A second overflow then erased a victim balance while leaving the attacker with the corresponding real tokens. Six independent chains were exposed because each had compiled the same vulnerable module into its software.
Why it matters
What to understand
The 2026 Cosmos EVM incident did not require stolen validator keys or a victim signature. A vesting account, a deterministic contract address, and unchecked 256-bit arithmetic corrupted the EVM-side balance long enough to redirect genuine tokens. The exploit illustrates correlated dependency risk: chains can have separate validators and governance yet remain jointly vulnerable through shared code and incomplete downstream security contacts.
Visual guide
How the pieces fit together
The failure occurred between two ledgers
Six blockchains were attacked through one reusable software component in August 2026. The incident did not begin with a stolen validator key or an administrator password. On MANTRA Chain, funds even moved from a burn address that had no usable private key. The software changed ownership because its balance arithmetic was wrong.
Cosmos SDK chains are independent networks with their own validators, governance, fees, and upgrade decisions. Cosmos EVM is an optional module that adds an Ethereum Virtual Machine, allowing Solidity contracts and familiar Ethereum tools to interact with Cosmos features such as staking and token transfers.
That convenience creates a difficult accounting boundary. The EVM keeps Ethereum-style state, while the Cosmos x/bank module maintains the native ledger. Both views must agree after a transaction. The bug appeared when a special account type exposed different balances to the two sides.
Vesting accounts created the blind spot
A Cosmos vesting account can hold spendable tokens and locked tokens. The spendable amount can move normally. Locked tokens remain subject to vesting conditions, although Cosmos rules may still allow them to be delegated for staking.
Cosmos EVM’s StateDB modeled only the spendable balance, while the staking system understood both spendable and locked portions. Imagine that StateDB sees 10 spendable tokens but the Cosmos account also holds 90 locked tokens. A 50-token delegation can be valid on the Cosmos side. When StateDB reconciles the event, however, it tries to subtract 50 from the 10 it knows about.
That should produce an error. Instead, the vulnerable code performed unsigned 256-bit subtraction without a sufficient underflow check. Because an unsigned integer cannot represent minus 40, the result wrapped around to a number close to 2²⁵⁶—an artificial balance with 78 decimal digits.
How the artificial number captured real tokens
The attacker first calculated a future smart-contract address, created a vesting account at that address, and then deployed the contract there. The attacker signed transactions for the contract it controlled; it did not impersonate the later victim.
The contract called the staking precompile, a bridge that lets Solidity code use Cosmos staking functions. A delegation larger than StateDB’s spendable view triggered the underflow. In the same transaction, the attacker transferred a carefully sized part of the wrapped balance to an address holding legitimate tokens.
That receiving balance overflowed in the other direction and wrapped to zero. The two arithmetic errors roughly canceled from the perspective of total supply, but the attacker finished with tokens that had belonged to the victim address. It was not an obvious permanent mint. The ledger’s calculator was corrupted temporarily, used to zero a real balance, and returned to a superficially plausible total.
On MANTRA, the exploit moved roughly 720.9 million OM from a burn address and a legacy genesis multisignature address. The first transfer escaped monitoring because the burn address was assumed to be incapable of spending. That assumption held at the signature layer but failed when the ledger itself assigned a new owner.
Independent chains can share one failure mode
Cosmos Labs described attacks against MANTRA, TAC, KiiChain, and three additional networks. The chains did not share consensus. What they shared was a vulnerable version of the cosmos/evm dependency compiled into their node software.
Reuse is not inherently unsafe. It lets teams build on reviewed consensus, staking, wallet, and virtual-machine components. The tradeoff is correlated risk: one defect can travel into many systems, and an upstream maintainer may not know every downstream operator. Cosmos Labs said it coordinated with 40 chains during the response and found 11 deployments not registered for its security communications.
The disclosure timeline shows why that gap matters. The underflow was reported through the bug-bounty program in April. A fix reached the main development branch in May, but active release branches were not immediately updated because early testing underestimated production exposure. Patched versions 0.6.2 and 0.7.2 arrived on August 19, shortly before the first known MANTRA drain.
A silent patch can deny attackers a ready-made explanation while operators upgrade. It can also look routine to teams that do not understand the urgency. Once a downstream pull request publicly described the path, vulnerable networks had far less time.
Why stopping a chain can be the least bad option
Validators can coordinate a halt to stop new blocks, freezing the vulnerable path while operators test and install patched software. Bridges and exchanges generally pause related transfers too. A halt cannot recover assets that have already crossed elsewhere, but it can prevent remaining funds from leaving.
The official advisory directed operators to versions 0.6.2, 0.7.2, or later and said there was no configuration-only mitigation. Networks unable to upgrade immediately were advised to stop.
The lasting lesson is broader than Cosmos. Independence at the consensus layer does not remove dependency risk at the software layer. A reliable security program needs an inventory of deployed components, current emergency contacts, monitoring of supposedly impossible state changes, and an upgrade process that can treat a shared invariant failure as urgent.
