On Nov. 7, a Cosmos Hub transaction turned 2,265.59 staked ATOM from six accounts into transferable staking claims and sent the resulting tokens to one address. The batch was recorded at 5:18 a.m. ET and contained 27 messages. They included a small self-transfer, six staking-reward withdrawal-address changes, 10 stake-tokenization operations, and 10 transfers of the share tokens. Every withdrawal address and every tokenization record pointed to the same recipient. The memo said lsm recovery batch, though that label alone does not prove who ran it.
What the transaction did
One delegator posting as Stan said 356.009956 ATOM was tokenized without his approval. He said he never signed the transaction and never granted authz permissions to anyone. Onchain records match the account and amount he described. The batch carried seven direct-mode signatures: one for the fee-paying account and one for each delegator. That explains how it acted for multiple accounts. It does not establish who controlled the keys or whether each owner approved. It did not use an authz execution wrapper.
The Hub’s liquid staking module converts a delegation into tokens that represent a claim on staked ATOM. Ownership can change without waiting through the normal 21-day unbonding period. The underlying ATOM stays bonded. Redeeming the tokens restores a staking delegation; it does not release immediately spendable ATOM.
Breach and recovery questions
Web3Auth disclosed a security issue on Nov. 6 and paused its embedded-wallet service. Keplr later described a Web3Auth infrastructure vulnerability that exposed private keys for some users who signed in with Google or Apple. Keplr said recovery work may leave some social-login accounts with reduced or empty balances. Web3Auth warned that some recovery transfers have been mistaken for attacker activity and is preparing a verified list of recovery addresses. It told users not to assume an unfamiliar destination is linked to an attacker.
Whether the six accounts in this batch were affected by that breach is unconfirmed. So is whether the single recipient is an attacker or a recovery operator. A later balance query showed the destination still held the full share-token amount sent from Stan’s account. That fact is consistent with a recovery process, but it does not settle the question. Perhaps that is why the case has drawn so much attention: the same onchain pattern can support more than one explanation.
What users were told
Keplr advised Google- and Apple-login users not to send new funds to affected accounts and to move remaining liquid assets to a recovery-phrase or hardware-wallet account. It said wallets created with a recovery phrase or hardware wallet were not affected. The transaction’s purpose remains unresolved.
