“Design a mobile crypto wallet” is a security-heavy mobile-system-design question. The interviewer is testing whether you understand the difference between a custodial and non-custodial wallet, how to use the secure hardware on the device, and the design of recovery without bricking funds. This is not a blockchain tutorial — it is a mobile-architecture interview.
Clarify scope
- Custodial (Coinbase-style) or non-custodial (MetaMask, Rainbow, Trust)?
- Single chain (Ethereum) or multi-chain?
- NFTs and dApps in scope?
- Hardware wallet integration?
Custodial vs non-custodial
Custodial: exchange holds keys. App is essentially a banking client over a custom backend. Easier UX, regulated, but the user does not “own” the funds in the cypherpunk sense.
Non-custodial: keys live on the device. You design key generation, storage, signing, and recovery. This is the harder design problem and the more common interview prompt.
Key generation
Use BIP-39 to generate a 12- or 24-word mnemonic seed. From the seed, derive HD keys using BIP-32 / BIP-44 (and chain-specific derivation paths). The seed is the recovery secret; lose it and funds are unrecoverable.
Key storage on device
Encrypt the seed and store the ciphertext in the OS keychain (iOS Keychain / Android Keystore). The decryption key is held in the Secure Enclave / StrongBox and only released after biometric or passcode authentication. Never store the seed in plaintext, in UserDefaults, or in a backed-up location without explicit consent.
Transaction signing
- App constructs an unsigned transaction (recipient, amount, gas, nonce)
- App requests Touch ID / Face ID confirmation
- On success, the OS releases the decryption key briefly; the app decrypts the seed in memory
- App derives the signing key, signs the transaction, zeros the seed bytes
- Signed transaction is broadcast to the chain
For maximum security, perform signing inside the Secure Enclave itself if the chain’s curve is supported (secp256r1 yes, secp256k1 not on Apple). Otherwise the in-memory window must be as short as possible.
Recovery
The user must back up the seed. Options:
- Write the 12 words on paper (the gold standard, terrible UX)
- iCloud Keychain backup (encrypted with the user’s passcode; convenient but Apple-account-tied)
- Social recovery: split the seed via Shamir Secret Sharing across trusted contacts
- Smart-contract account abstraction (ERC-4337) with multi-sig guardians
Modern wallets are converging on smart-contract accounts because pure-EOA recovery is brutal.
dApp connection
WalletConnect is the standard. The dApp encodes a session URI as a QR code; the wallet scans it, opens a session, and now signs requests over a relay. Show every signing request with a clear summary; never blind-sign.
NFT and asset display
- Index assets per chain via an indexer (Alchemy, Moralis, OpenSea API)
- Cache locally; refresh on visibility, on transaction confirmation, and on pull-to-refresh
- Spam-NFT defense: filter out airdrops and scam tokens
Multi-chain UX
One mnemonic, many chains. The app shows a unified asset list across chains; behind the scenes it derives separate keys per chain. The user sees one balance number; you fan out to multiple RPCs to compute it.
The hard parts
- Phishing protection: warn on unknown contracts, simulate transactions before signing
- Gas estimation: 1559 base fee + tip, plus chain-specific quirks; show a clear total
- Failed transactions: clear UI; the user paid gas even on failure
- Account-abstraction transition: support both EOA and smart-account flows
What interviewers reward
- Drawing the Secure Enclave boundary clearly
- Discussing recovery as a UX problem, not just a crypto problem
- Naming WalletConnect for dApp integration
- Discussing transaction simulation as a phishing defense
- Acknowledging account abstraction (ERC-4337) trends
Frequently Asked Questions
Should I implement key derivation myself?
No. Use a battle-tested library (libsodium, OpenSSL, or platform-specific). Subtle bugs in cryptography are catastrophic. Audit your dependencies.
What about iCloud backup of the seed?
Acceptable if encrypted with the user’s passcode using PBKDF2/Argon2 with high iteration counts. Make the user explicitly opt in. Document the threat model (Apple-account compromise = funds at risk).
How do I handle hardware wallet support?
Ledger Live SDK over BLE / USB-C. The wallet does not hold the seed; it sends unsigned transactions to the device which signs them. Use this whenever the user attaches a hardware wallet.