Design Crypto Wallet

A Self-Custodial Crypto Wallet

This question is the deliberate inverse of the exchange, and leading with that contrast is the strongest opening. An exchange holds your keys; a self-custodial wallet like MetaMask or Ledger Live exists precisely so that it never does. The user controls a BIP-39 seed phrase, and the entire product is built around one hard constraint: the plaintext private keys never leave the user's device and never touch your servers. Everything you build — the backend, the APIs, the indexers — is supporting infrastructure around a signing operation that happens client-side.

That constraint flips the usual server-centric design on its head. Your servers store only ciphertext vault blobs and public addresses — never a seed, never a private key. The wallet client derives a tree of keys from one mnemonic, holds them in a secure enclave or an encrypted keystore, and signs transactions locally; what crosses the network is only signatures and public data. The custody your backend holds is therefore zero, which is the whole point: a server breach leaks encrypted blobs an attacker cannot use, not user funds. State this invariant first and the interviewer knows you understand the threat model.

So what does the backend actually do? It is a read-and-relay plane, not a custody plane. It serves multi-chain balance and transaction history (by indexing chains so the client does not have to), relays signed transactions to the right chain's RPC nodes for broadcast, tracks pending transactions and confirmations, and brokers dApp connections over WalletConnect. The scale drivers are reads, not writes — portfolio refreshes, history queries, dApp sessions — plus the reliability of the broadcast path. Size for RPC egress, indexer lag, and the device unlock rate, not for a transactions-per-second number.

The reason this question separates strong candidates is the threat model, because in self-custody the user is the security boundary and the failures are adversarial and human. The signing UI must show a human-readable preview so a user is not tricked into approving a malicious transaction (the phishing-approval attack). A stuck nonce must not silently block an account. An RPC provider lying about block height, or a reorg flickering a balance, must be detected rather than trusted. And large transfers should demand hardware co-signing while small ones stay on-device. Having these detection-and-mitigation pairs ready — and never confusing wallet UX with exchange custody — is what proves you have built a wallet, not drawn a diagram.