Design a Crypto Wallet (Self-Custodial)

Problem statement

Design a self-custodial crypto wallet that gives users full control of private keys derived from a BIP39 mnemonic seed phrase. The product must generate and store keys locally, support multiple blockchains (Bitcoin, Ethereum, and other EVM and non-EVM chains), display balances and history across accounts, let users sign and broadcast transactions, manage BIP44 derivation paths, integrate hardware wallets and password-based encryption, and provide backup and recovery flows that survive device loss without ever exposing plaintext key material to a server.

The defining constraint is authority: whoever holds the signing key owns the assets. Therefore the architecture is not a backend with clients; it is a local trust boundary (the device, its secure enclave, and optionally a hardware secure element) surrounded by a coordination plane (chain access, fee markets, metadata, encrypted backup, price and confirmation feeds) that must remain useful while being permanently untrusted with keys. Every design decision below follows from that split.

Why this problem is distinctive

A payments app can rotate a compromised server key. A self-custodial wallet cannot rotate a leaked seed: the mnemonic IS the account, forever, on every chain it derives into. Loss is irreversible (no support team can restore it), and theft is instantaneous and global (mempools do not respect fraud alerts). Meanwhile the usability bar is consumer-grade: MetaMask reported monthly active users growing from 19 million in September 2023 to over 30 million by January 2024, and Trust Wallet reported crossing 200 million downloads by March 2025. Those populations include first-time users who will write a seed on a screenshot, paste it into a phishing site, or lose their phone. The design must therefore treat user error as a threat model input, not an edge case.

The second distinctive property is heterogeneity. Bitcoin's UTXO model, Ethereum's account-and-nonce model with EIP-1559 fee markets, and dozens of other chains differ in address formats, signing schemes (ECDSA secp256k1, Ed25519, Schnorr), transaction encodings, and finality behavior. Ethereum alone processed a 2024 average of about 1.6 million transactions per day with a record day above 2.2 million in December 2025, while Bitcoin ran near 700-800 thousand transactions per day in 2025. A wallet is a compiler from human intent into many mutually incompatible chain dialects, plus a synchronizer of eventually consistent chain state.

The four architectural planes

1. Key plane (local, never delegated): entropy generation, mnemonic, BIP32/44 derivation, keystore encryption (Argon2id + AES-256-GCM), secure enclave or StrongBox wrapping, hardware wallet APDU sessions, signing orchestration, key destruction.
2. Chain plane (remote, untrusted): node/RPC access, sync engine (SPV, compact filters, or indexer), fee estimation, broadcast, confirmation and reorg tracking.
3. Product plane (local-first, server-assisted): multi-chain accounts, balances, history, address book, labels, encrypted zero-knowledge cloud backup, recovery, migration.
4. Trust plane (cross-cutting): supply-chain integrity of the wallet build, dApp origin policy, transaction simulation and security alerts, address-poisoning defense, clear signing on hardware, privacy minimization, and observability that never leaks addresses or balances.

A strong interview answer keeps these planes separate, states the invariant "the server never sees plaintext keys or the mnemonic", and then designs each plane's failure behavior independently.