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. In a simplified example, the account holds 10 spendable tokens and 90 locked tokens. Delegating 50 can be valid for staking because that system sees the locked portion too. StateDB sees only 10 and tries to subtract 50 from it. The two systems disagree about the amount available for this particular operation.
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 canceled from the perspective of total supply, but the attacker finished with tokens that had belonged to the victim address. A supply check alone could miss the theft: the total could be unchanged even though the distribution among owners was wrong. Cosmos Labs’ post-mortem describes the paired operations as one supply-neutral transaction.
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 incident 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. These were the response instructions for the August incident, rather than a recommendation to deploy those historical releases today.
For operators, the unanswered inventory question was not “who shares our validators?” but “who runs this version of the same module?” The BounceBit authorization failure provides another case where chain independence did not protect the ledger from its own software. In Cosmos EVM, both the accounting assumptions and the path for reaching downstream operators needed scrutiny.
Visual guide
How the pieces fit together
