Mobile HD Wallet Development (BIP-39/BIP-44)
Client wants to store multiple blockchain accounts in one app and give user single seed phrase of 12 or 24 words. Sounds simple — until you reach key derivation, different curves (secp256k1 vs Ed25519), SLIP44 coin indices and how Flutter or React Native handle big integers natively.
Why "Just Generate Keys" Doesn't Work
BIP-39 — mnemonic standard. Take 128 or 256 bits entropy, add checksum, split into 11-bit groups, map to wordlist (English — standard, other languages — optional bonus). From mnemonic via PBKDF2-HMAC-SHA512 with salt "mnemonic" + passphrase and 2048 iterations — get 512-bit seed.
Then BIP-32: from seed via HMAC-SHA512 — master private key + master chain code. Entire tree built recursively — child key derivation via hardened (index ≥ 0x80000000) or normal paths. Hardened derivation matters: normal derivation leaking child private key + chain code allows parent key recovery. Account-level (m/44'/coin'/account') — hardened mandatory.
BIP-44 fixes path: m / 44' / coin_type' / account' / change / address_index. Ethereum coin_type = 60, Bitcoin = 0, Solana — 501. Not details — this is what makes your wallet compatible with MetaMask, Trust Wallet, Ledger Live.
Where Implementation Actually Breaks
BigInt and Native Libraries. JavaScript in React Native lacks native BigInt before Hermes 0.11+. Library @scure/bip32 uses noble-curves, requiring BigInt. On old Hermes builds, app crashes at first derivation with ReferenceError: BigInt is not defined. Solution — explicit polyfill or transition to react-native-quick-crypto + native module.
Compatibility Testing. Test vectors from BIP-39 and BIP-32 specs — mandatory part of test suite. If your mnemonicToSeed("abandon abandon ... about") doesn't output c55257... from official vector — bug in PBKDF2. Not obvious in manual testing.
Solana and Ed25519. Solana uses SLIP-0010 derivation for Ed25519, not standard BIP-32. @solana/web3.js Keypair.fromSeed() takes 32 bytes, not extended key. Path m/44'/501'/0'/0' — all hardened, normal derivation for Ed25519 undefined. Mixing secp256k1 and Ed25519 in one HD tree without accounting — source of invalid addresses.
Flutter. Package bip39 on pub.dev abandoned since 2021. bip_wallet works, but doesn't cover Solana. For production, build native plugin via platform channels: Swift/Kotlin implementation via WalletCore from Trust Wallet — has BIP-39, SLIP-0010, support for 60+ coins with correct coin_type indices.
How We Build Implementation
Foundation on iOS — WalletCore (C++/Swift) via Swift Package Manager. On Android — same WalletCore via JNI or bitcoinj for Bitcoin-specific part. Entropy from SecRandomCopyBytes (iOS) or SecureRandom (Android) — not Math.random() and not from time.
Wallet structure in memory:
HDWallet
├── mnemonic: String (in memory only, never in UserDefaults/SharedPreferences)
├── seed: Data (512 bits, ephemeral)
└── accounts: [CoinType: [HDAccount]]
├── ETH: account 0 → m/44'/60'/0'
├── BTC: account 0 → m/44'/0'/0'
└── SOL: account 0 → m/44'/501'/0'/0'
Private keys live in Secure Enclave (iOS) or StrongBox (Android) after initial derivation. Seed and mnemonic destroyed from memory via Data.resetBytes / Arrays.fill(seed, 0).
For multi-account, increment account' index in BIP-44 path, not address_index. MetaMask uses address_index, Trust Wallet — account'. Both valid, mutually incompatible — fix in requirements before starting.
Process
Start with requirements audit: which coins, which derivation paths needed, need compatibility with specific external wallet. Then — choose crypto library (WalletCore, noble-curves + polyfills, bitcoinj), write unit tests on BIP-32/BIP-39 official vectors, native entropy generation, Secure Enclave/StrongBox integration for storage, UI layer with seed confirmation.
Separate stage — recovery testing: seed-phrase → same addresses. Tested on real device, not just simulator.
Timeline — 1 week (single blockchain, React Native + Hermes, no Secure Enclave) to 3 months (multichain, Flutter, native plugins, full security audit). Cost individual after analyzing requirements.