The bug lives at the seam between two ledgers. The EVM StateDB tracks only an account's spendable balance, while vesting accounts in Cosmos SDK state hold both a spendable and a locked balance, and both x/staking and the staking precompile permit the locked portion to be delegated [11]. When a vesting account delegates more than its spendable balance, the post-delegation write-back subtracts the full delegated amount from the smaller spendable figure, and because the subtraction is unchecked the balance wraps to roughly 2^256 [12].
Reconciliation then mints on a positive delta and burns on a negative one, which gives the attacker two directions: move a finite amount out of the wrapped account, or send a victim account 2^256 minus its balance so reconciliation burns the victim's real holdings [13]. On 0.6.x the mint and burn hit the backing SDK ledger, so a large mint overflows total supply and halts the chain [14]. On 0.7.x balances are set directly in x/bank, and any change surviving a uint256 to int256 conversion is accepted [15]. Both halves ran inside a single transaction with a net supply change of zero, issued from a contract deployed onto a precomputed address that had been turned into a vesting account first [16]. The precondition is a chain that permits permissionless vesting-account creation [17]; vesting accounts defined in genesis are unaffected [18].
The timeline is where the cost was set. The report reached Cosmos Labs on April 25 and was assessed as posing no risk to funds on live networks [6]. That leaves 116 days between the report and the August 19 release of v0.6.2 and v0.7.2 [1]. Only six of those days fall after August 13, the date Cosmos Labs says it confirmed every Cosmos EVM chain was affected regardless of decimal configuration [2]. Draining began August 20, one day after the patch shipped [3], and ran six days [4]. The post-mortem landed August 28, three days after the last recorded drain [6].
Cosmos Labs' explanation is specific. It could not reproduce the flaw on 18-decimal networks and "incorrectly concluded that it affected only non-18-decimal networks" [7]. Once corrected, the fix still went out through the public silent patch process the company reserves for issues that do not cause fund loss on production chains [8], because, in its words, the patch "had already been publicly available on the main branch without known exploitation" [9]. Its own bug bounty policy, last synced July 27, says network-wide risk triggers emergency mitigations, private fix distribution, or coordinated upgrades before any public disclosure [10]. That sync date sits between the April 25 report and the August 13 confirmation, so the stricter policy was the one in force when the routing decision was made [5].
Operators backporting rather than upgrading have one more trap. A cherry-pick that patches only the exported helper can leave a duplicated unexported copy live while every test passes, so the advice is to verify the live code path on a fork [20]. Two further fixes are absent from the advisory itself: the locked-balance snapshot and the module-account guard [21].
