The ‘LSM Recovery Batch’ After Web3Auth Breach: The Staked ATOM Mystery on Cosmos Hub

A Quiet Transaction That Spoke Volumes

At 5:18 a.m. ET on Nov. 7, a small but unusually structured transaction landed on Cosmos Hub. It did not involve a massive dollar amount, and it did not cause a market panic. But in the Cosmos ecosystem, it quickly became one of the most talked-about on-chain events of the day. The transaction carried the memo “lsm recovery batch,” and its 27 messages formed a striking pattern: a tiny self-transfer, six changes to staking-reward withdrawal addresses, ten operations to tokenize staked ATOM positions, and ten transfers of the resulting share tokens. Every withdrawal address and every tokenization-record owner pointed to the same destination. The transaction looked like a coordinated effort to consolidate staked ATOM positions into a single account. The timing made it even more notable. Just hours earlier, Web3Auth had disclosed a security issue and paused its embedded-wallet service. Keplr, one of the Cosmos ecosystem’s most recognized wallets, had warned that some users who signed in with Google or Apple may have had their private keys exposed. Now, here was a batch transaction that appeared to move multiple staking positions connected to that vulnerable login path into one address. The memo suggested a recovery effort, but the on-chain record alone could not prove who was behind it. In that way, the transaction became a perfect example of the blockchain’s greatest strength and its deepest limitation: the ledger shows exactly what happened, but it does not always explain why.

How the Cosmos Liquid Staking Module Actually Works

To understand why this transaction mattered, it is necessary to understand the Cosmos Hub’s liquid staking module, commonly known as the LSM. In a typical proof-of-stake network, delegating tokens to a validator means locking those tokens up for a defined period. On Cosmos, that unbonding period lasts 21 days, and during that window the staked ATOM cannot be transferred freely. That rule helps maintain network security, but it also creates friction for users who want to move positions quickly. The LSM was designed to change that. It allows a staked delegation to be converted into transferable share tokens that represent a claim on the bonded ATOM. Those share tokens can be transferred from one address to another, used in DeFi protocols, or held as a certified claim on the original stake. The important nuance is that the underlying ATOM remains bonded with the validator. It does not become spendable just because the share tokens are moved. When the share tokens are eventually redeemed, the process restores an ordinary staking delegation rather than releasing liquid ATOM to the wallet. That detail is central to what the Nov. 7 batch actually did. It did not unlock staked ATOM and send it out as spendable funds. Instead, it changed who controlled the claim on those staked positions. For a recovery operation, that would have been a logical first step: take the positions out of the hands of potentially compromised accounts and place them under a single protective umbrella. For an attacker, tokenizing a stolen delegation would also work, because the resulting share token is portable and can be moved to an address the attacker controls. The same mechanism can be used to rescue assets or to carry them away, depending entirely on who is signing the messages.

What the Seven Signatures Do—and Do Not Prove

The batch carried seven direct-mode signatures. One came from the fee-paying account, and the other six came from the delegators whose staking positions were being moved. In Cosmos, transactions can be signed in multiple ways. Direct-mode signatures mean each signer directly attested to the exact contents of the transaction. The batch did not use an authz execution wrapper, which would have allowed one account to act on behalf of another through a pre-approved authorization grant. The decision to use direct signatures is significant, because it indicates that whoever assembled the transaction had access to the appropriate signing keys at the time the batch was created. But it does not prove that the account owners knew what was being signed, that they approved the transaction, or that their keys had not been exposed. Keplr had already warned that private keys linked to Google and Apple social-login accounts may have been exposed during the Web3Auth incident. If those keys were in the wrong hands, the attacker could have produced perfectly valid signatures too. The memo “lsm recovery batch” added another layer of meaning, but a memo is only a note written into the transaction data. Anyone can write anything in a memo. A legitimate recovery operator, a hacker with a cynical sense of humor, or an automated cleanup script could all use the same label. On-chain follow-up data offered only partial clarity. A subsequent balance query showed that the destination account still held the full amount of share tokens it had received from the source address highlighted by Stan, an on-chain observer who drew attention to the batch. No immediate onward movement had been made at the time of that check. That silence can be read in two ways. It could mean the recipient is a recovery operator carefully deciding what to do next. Or it could mean an attacker is waiting for the right moment to act.

Web3Auth, Keplr, and the Social-Login Risk

The security context behind all of this began on Nov. 6, when Web3Auth disclosed a security issue and paused its embedded-wallet service. Web3Auth is not a blockchain wallet in the traditional sense. It is an authentication infrastructure provider that wallet applications use to let people sign in with familiar credentials such as Google, Apple, or email. That convenience has made social-login wallets popular, especially among new crypto users, but it also introduces a central point of vulnerability. If the authentication layer is compromised, the impact can spread across every application that relies on it. Keplr, a leading wallet in the Cosmos ecosystem, is one of those applications. Keplr later described a Web3Auth infrastructure vulnerability that exposed private keys for some users who had signed in with Google or Apple. The exact number of affected users was not immediately known, but the warning was serious enough to prompt an immediate response. Keplr said its assistance with recovery efforts meant some social-login accounts may show reduced or empty balances. That phrasing was important, because an empty balance after a security incident does not automatically mean theft. Funds can also be moved to a safer address as part of a recovery operation. In the case of the “lsm recovery batch,” the six delegators involved may have been affected by the Web3Auth vulnerability, but that connection has not been confirmed. The recipient could be a recovery operator, a security firm, or an attacker. The public ledger does not resolve that question.

Keplr’s Guidance and the Urgency of Moving Funds

On Nov. 7, the same day the batch transaction was recorded, Keplr issued guidance for anyone who had created a wallet using Google or Apple sign-in. The message was direct: do not send new funds to those accounts. Move any remaining liquid assets to an account backed by a recovery phrase or a hardware wallet. Keplr was also careful to reassure users that wallets created with a recovery phrase or hardware wallet were not affected by the vulnerability. That distinction redrew the line between self-custody and third-party dependency. Social-login wallets have long been marketed as a simpler way to enter the crypto space. The promise is that users do not need to memorize a seed phrase or protect a hardware device; they can simply use the same authentication method they use to check email. The Web3Auth incident challenged that promise. When a wallet’s authentication layer is compromised, everything built on top of that layer becomes uncertain. Keplr’s advice was designed to prevent users from making a bad situation worse. Sending new funds into a potentially compromised account would simply put more assets at risk. Moving remaining liquid assets to a recovery-phrase or hardware-wallet account reduces the attack surface and returns control to the individual user. It is also a reminder that the old crypto maxim—“not your keys, not your coins”—applies not just to private keys, but to every third party involved in managing them. For anyone unsure whether their account was affected, the safest first step is to check official Keplr and Web3Auth channels, avoid unsolicited links, and carefully review wallet history for transactions that were not authorized.

Recovery Addresses, Unknown Actors, and the Road Ahead

Web3Auth, for its part, said it was preparing a verified list of recovery addresses. The goal of that list was to help users distinguish protective transfers from potentially malicious transactions. The company also issued a warning that may seem counterintuitive during a security incident: “Please do not assume that an unfamiliar destination address is associated with the attacker.” The warning matters because panic often drives assumptions. After a breach, observers may look at an outgoing transaction and assume any unknown address is the attacker’s. But recovery operations can send funds to addresses that look unfamiliar, especially if security teams are moving assets out of compromised infrastructure. The only way to know for sure is to compare those addresses against an official and verified source. Until Web3Auth publishes its list, the responsible approach is to treat unfamiliar movements with caution while avoiding premature conclusions. The “lsm recovery batch” sits directly in the middle of that uncertainty. It moved staked ATOM share tokens into a single destination, used the word “recovery” in its memo, and included multiple direct signatures. It could be exactly what it appears to be: a carefully assembled rescue operation after the Keplr and Web3Auth incident. It could also be a sophisticated transfer designed to consolidate stolen positions before a follow-up transaction. The batch itself does not offer enough information to make a final judgment. What it does offer is a useful lesson for the broader crypto community. On-chain data records the movement of assets, but it does not reveal intent. Meaning has to come from context, and in this case, the context is still being written. Until the involved teams clarify the situation, the 27-message transaction on Cosmos Hub will remain what it has been from the start: a sharp reminder that transparency and certainty are not the same thing.