Bitcoin is back at 75k, and there is not much to say about the price action itself. What was waiting this morning was another security incident in wallet infrastructure.

Keplr’s social-login wallets were compromised, with assets drained from several thousand accounts. The official explanation points to a vulnerability in Web3Auth’s infrastructure[1]. Most of the users who lost funds did nothing wrong; they simply chose convenience when they created the wallet with a Google or Apple login.

The detailed cause has not yet been disclosed, and the vendors involved are trading blame. Following that thread, it is worth setting the key-management models of several mainstream wallets side by side to see what they actually imply.

Start with the traditional self-custody baseline: write the seed phrase down on paper and keep that paper safe.

It is a simple model. The key is in your hands and nobody else knows it. The security boundary is you: do not lose the paper, do not photograph it, do not tell anyone. The weakness is human fallibility — a fire, a house move, a trip through the laundry can all erase that sheet. But the virtue is that the risk sits in one visible place. You can see it and you know exactly what it is. Because it is so plain, you give it 120 percent of your attention and guard it with everything you have.

With that baseline, consider how several popular wallet apps handle custody of the private key or seed phrase. This is not about centralized exchanges, which take full control of the assets. The models discussed here hold custody of the seed phrase without holding full control of the assets.

First, the Uniswap wallet. Its approach is straightforward: encrypt the seed phrase and back it up to your own iCloud or Google Drive[2].

Apple’s servers hold a blob of ciphertext; the password that opens it lives in your head. To recover, you sign in to your cloud account and enter the dedicated password used to encrypt the seed phrase — a different password from your Apple ID. The cloud provider only ever sees ciphertext, which in theory it cannot decrypt. The risk has moved to the account side: a stolen Apple ID, an intercepted verification code, a phishing site that captures the password — any of these can put the backup in someone else’s hands. Still, the risk stays in familiar territory. A cloud account and a password are things you use every day.

On the cloud side there is only one risk: that Apple’s or Google’s storage service is breached. Choosing those two over some other cloud provider is itself a bet on their security capabilities, and it is exactly why the choice was made.

Next, social login in MetaMask, the classic web3 wallet known as the little fox. Its design is considerably more involved: the encrypted seed phrase is stored on MetaMask’s own servers, while the decryption key is split into shares held by different server nodes. Recovery requires two things — a Google, Apple, or Telegram login credential, and a password you set[3]. Only with both can the key be reassembled.

MetaMask is careful to point out that even if every server were compromised, an attacker would hold only fragments and would still have to crack your password. That is true, but only under certain conditions. In routine online recovery, the login credential is the first gate, server-side rate limiting is the second, and the password is only the third; a weak password is not immediately broken. Once the share-holding nodes fall, however, the attacker can take the fragments offline and brute-force them on their own hardware. Rate limiting disappears, and password strength becomes the only line of defense.

Finally, the scheme used by Keplr, the wallet at the center of this incident. The key is split into three shares — one on the user’s device, one on a cloud server, and one kept as a recovery backup — and the server takes part in reassembling them after login[4]. The design says any two of the three can reconstruct the private key. But if two of those shares are in practice controlled by the same provider, the three-share threshold collapses into a single point of compromise. It is tempting to suspect that is where this incident originated, though the real answer has to wait for the vendors to disclose more technical detail.

Put the four side by side and a counterintuitive pattern appears.

From the first model to the fourth, there are more locks, more components, more complexity, and louder claims that sophisticated cryptography improves security. Yet what the user can actually see and judge shrinks at every step. A key copied onto paper: you know where it is. Ciphertext in iCloud: you still know it sits with Apple. With MetaMask, the ciphertext is on a server, the fragments are on nodes, the password is in your head, and you need to understand four separate roles before you can describe the arrangement. By the time you reach Keplr, users who lose funds do not even know whom to hold accountable.

As complexity rises beyond the user’s comprehension, the attack surface exposed to an attacker grows with it. Paper and pencil carry one risk: theft or fire. An iCloud backup adds a cloud account. The MetaMask scheme adds a login provider, share-holding nodes, and password strength. The Keplr scheme adds an entire infrastructure. Every added layer spreads trust dependencies across more levels and more parties instead of removing trust.

That diffusion of trust can be fatal. A simple piece of arithmetic: if one person holds the key, the system fails only when that person fails. If two parties are involved, the system fails when either one fails. The probability that at least one of two people errs is plainly higher than the probability that one person errs alone. Components in series only drive reliability down, never up.

So why design it this way? Because in the first model the chance of human error is genuinely high. One word copied wrong, a sheet mislaid, a family member tossing it out as scrap paper — these happen every day. Social login cuts the user’s error rate sharply, at the price of introducing the service provider’s risk. On paper the trade may be worth it. The trouble is that neither of those two probabilities is visible to the user, and neither can be verified.

And here is the irony. When a scheme needs ten pages of documentation to explain why it is safe, an ordinary user has already lost the ability to judge it. All that remains is belief, and belief is not security. It is a bet.

It brings to mind a line from Satoshi Nakamoto’s Bitcoin whitepaper: “With the possibility of reversal, the need for trust spreads.” Nakamoto was writing about online payments, but private-key recovery is itself a reversible process, and by the same logic it spreads the need for trust.

That spread is, in itself, an expansion of the attack surface. Every link that requires trust is a possible point of entry for an attacker.

The custody methods that survive the test of time tend to be simple, direct, easy to understand, built from the fewest links, and demanding the least trust. Simple is not crude: it means keeping the complexity in the implementation while leaving the ability to judge with the user.

If a wallet cannot say plainly who holds the key, then its self-custody and its security are nothing more than marketing. To truly own something, you have to be able to point at it and say: this is mine, and I know with absolute certainty where it is.

References

  • [1] Keplr’s official statement on the social-login wallet incident, which attributes the compromise of several thousand accounts to a vulnerability in Web3Auth’s infrastructure. Detailed technical findings had not been published at the time of writing.
  • [2] The Uniswap wallet backup design: an encrypted seed phrase stored in the user’s own iCloud or Google Drive, recoverable with a cloud login plus a separate encryption password.
  • [3] MetaMask’s description of social-login recovery: an encrypted seed phrase on MetaMask servers, a decryption key split across server nodes, and recovery requiring a login credential together with a user-set password.
  • [4] The Keplr three-share key design: one share on the user’s device, one on a cloud server, one kept as a recovery backup, with the server participating in reassembly after login and any two shares sufficient to reconstruct the private key.