Source publication: November 10, 2026, at 14:04:29 (UTC+8). Based on Liu Jiaolian’s analysis published by TechFlow.
The research question: who can reconstruct the key?
Social login makes wallet creation easier, but what dependencies does it introduce into key recovery?
Liu Jiaolian examines that question following a reported incident involving Keplr’s social-login wallets. According to the article, assets were transferred out of several thousand accounts, and the official explanation pointed to a vulnerability in Web3Auth’s infrastructure. Most affected users, the author writes, had simply created wallets using Google or Apple login.
The article says detailed technical findings had not yet been disclosed and describes vendors as shifting responsibility. That limits the conclusions available: the incident provides context for comparing recovery architectures, but does not establish which architectural weakness caused the losses.
The comparison excludes centralized exchanges that hold full control over customer assets. Instead, it considers arrangements for storing or recovering key material without ostensibly handing over complete asset control.
1. A paper recovery phrase: a visible responsibility
The baseline is a recovery phrase written on paper and kept by the user.
Its principal advantage in the author’s analysis is legibility: the user knows where the recovery material is and who must protect it. Loss, accidental disposal, fire, theft or disclosure can undermine that arrangement. Photographing or sharing the phrase also defeats the intended protection.
This model minimizes reliance on recovery-service providers, but concentrates responsibility on the individual. Its simplicity does not eliminate the possibility of human error.
2. Uniswap Wallet: encrypted cloud backup
As described in the article, Uniswap Wallet encrypts the recovery phrase and backs it up to the user’s iCloud or Google Drive account.
Recovery requires access to the cloud account and a separate password chosen to encrypt the phrase—not the Apple ID password. The cloud provider holds ciphertext that, in principle, it cannot decrypt without that password.
The relevant dependencies therefore include cloud-account security, the encryption password and the storage provider. Account theft, intercepted verification codes or phishing could expose parts of the recovery process. Obtaining an encrypted backup is not, by itself, the same as obtaining the plaintext phrase.
For the author, the practical benefit is that users are dealing with relatively familiar controls: an account and a password.
3. MetaMask social login: online controls versus offline guessing
The article describes MetaMask’s social-login arrangement as storing an encrypted recovery phrase on MetaMask servers, with the decryption key split across server nodes.
Recovery requires both a Google, Apple or Telegram login credential and a user-selected password. The author reports MetaMask’s position that even a compromise of its servers would leave attackers needing to crack the password.
The important distinction is between two attack conditions:
- Online recovery: identity-provider authentication and server-side rate limits constrain access before the password becomes the remaining barrier.
- Offline guessing after a compromise: under the scenario described by the author, attackers who obtain the necessary fragments could attempt password guesses on their own machines, outside those rate limits.
The article’s concern is therefore not simply whether a password exists, but which protections remain if infrastructure is compromised.
4. Keplr’s reported arrangement: a threshold depends on control
The article describes the arrangement used by Keplr as splitting key material into three shares: one on the user’s device, one on a cloud server and one serving as a recovery backup. Any two shares can reconstruct the private key, with server participation after login.
The author raises a conditional concern: if one provider actually controls two shares, a two-of-three threshold may still leave a single provider-level point of compromise.
Liu Jiaolian suspects this could be relevant to the incident, but explicitly acknowledges that further technical disclosure is needed. The supplied article does not establish that this was the attack path.
What the comparison supports—and what it does not
The article’s central argument is that additional recovery components can make trust dependencies harder for users to see. Social login may reduce mistakes involving handwritten phrases while introducing dependencies on identity providers, recovery services and supporting infrastructure.
That is a trade-off, not a quantified security ranking. The article provides no measured failure probabilities or detailed incident findings with which to determine which model is safest overall. Its argument about additional failure points is most applicable where compromising any one dependency defeats the system; the Keplr discussion itself shows why actual control over threshold shares matters.
The useful evaluation question is narrower than whether a wallet advertises “self-custody”: who holds each recovery component, which combinations authorize reconstruction, and what remains protected when a provider fails? Until those relationships are clear, users cannot readily assess the security boundary they are being asked to trust.