We often see teams trying to implement an HD wallet by simply generating a seed phrase from a library and getting an address, but when they transfer the phrase to MetaMask or Trust Wallet, the addresses don't match. The reason is ignoring derivation standards (BIP-39, BIP-44) and differences in curves (secp256k1 vs Ed25519). In this article, we'll break down how to avoid such mistakes and build a compatible mobile wallet. Our HD wallet development covers BIP-39, BIP-44 for mobile wallet applications, starting at $5,000 for a single coin.
How to ensure HD wallet compatibility with MetaMask and Ledger?
Compatibility is achieved by precisely following BIP-44 paths and using proven cryptographic libraries. For example, WalletCore (from Trust Wallet) supports 60+ coins and correctly handles hardened derivation for Ed25519. We start with a requirements audit: which coins, is compatibility with a specific wallet needed. Then we choose a library: WalletCore for iOS/Android or noble-curves + polyfills for React Native. Entropy is generated via hardware: SecRandomCopyBytes (iOS) or SecureRandom (Android).
Common pitfalls with ready-made libraries
Common pitfalls with ready-made libraries
Problem 1: BigInt and native modules. In React Native, older Hermes versions don't support BigInt. The @scure/bip32 library (noble-curves) requires it, and the app crashes with ReferenceError: BigInt is not defined. The solution is an explicit polyfill or switching to react-native-quick-crypto with a native module.
Problem 2: Curve differences. BIP-32/44 were originally written for secp256k1 (Bitcoin, Ethereum). Solana uses Ed25519 and SLIP-0010 derivation, where all paths are hardened. If you mix curves without accounting for this, addresses will be wrong. WalletCore handles this correctly.
Problem 3: Compatibility testing. Vectors from the BIP-39 and BIP-32 specifications are a mandatory part of the test suite. If your mnemonicToSeed("abandon abandon ... about") doesn't produce c55257... — there's a bug in PBKDF2. The BIP-39 specification defines test vectors for all kdf parameters.
Implementing an HD wallet in 5 steps
- Requirements audit: determine coins, target platform (iOS/Android/Flutter/RN), and required compatibility with other wallets.
- Library selection: WalletCore (native or via Flutter/RN bridges) or noble-curves with BigInt polyfill.
- Seed generation: hardware entropy with Secure Enclave/StrongBox, mnemonic created according to BIP-39.
- Key derivation: by BIP-44 for secp256k1 or SLIP-0010 for Ed25519, all hardened paths.
- Testing: unit tests on official vectors and integration tests for address recovery.
Building a compatible implementation
Wallet structure in memory:
HDWallet ├── mnemonic: String (only in memory, never in UserDefaults) ├── seed: Data (512 bit, 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 are stored in Secure Enclave (iOS) or StrongBox (Android). Seed and mnemonic are destroyed via Data.resetBytes / Arrays.fill(). For multi-account, we fix the choice of account' or address_index in the specifications.
Comparison table of approaches:
| Parameter | WalletCore | noble-curves + polyfills | bitcoinj |
|---|---|---|---|
| Ed25519 support | Yes | Yes | No |
| Number of coins | 60+ | 3–5 manually | Bitcoin only |
| Native performance | C++/JNI | JavaScript | Java |
| Compatibility | MetaMask, Ledger | Depends on library | Bitcoin Core |
WalletCore is 3x better than noble-curves for multichain support, saving development time significantly. For a typical iOS wallet or Android wallet, WalletCore reduces implementation effort by half compared to custom solutions. Using WalletCore is 3x faster for multichain support compared to custom implementation.
Timeline comparison by platform:
| Platform | Single blockchain | Multichain (5 coins) | Security audit |
|---|---|---|---|
| iOS (Swift) | 1-2 weeks | 4-6 weeks | +2 weeks |
| Android (Kotlin) | 1-2 weeks | 4-6 weeks | +2-3 weeks |
| React Native | 1-2 weeks | 3-5 weeks | +1-2 weeks |
Typical implementation mistakes
- Storing seed phrase in SharedPreferences/UserDefaults — a grave security violation. Use Secure Enclave/StrongBox.
- Ignoring hardened derivation — with normal derivation, leaking a child private key allows recovering the parent key.
- Mixing BIP-44 and SLIP-0010 — for Ed25519 all paths hardened, for secp256k1 — mixed.
What's included in the work
- Requirements audit and cryptographic library selection.
- Implementation of seed phrase generation and recovery (BIP-39).
- Key derivation per BIP-44 and SLIP-0010.
- Integration with Secure Enclave/StrongBox.
- Writing unit tests on official vectors.
- Compatibility testing with wallets (MetaMask, Trust Wallet, Ledger).
- Deployment to App Store/Google Play and documentation.
- Deliverables: full documentation, code access, developer training, and 3 months of support post-launch.
Ready to discuss your project? Contact us — we will help you implement a turnkey HD wallet with guaranteed compatibility and security. Typical development cost: $5,000 for a basic single-coin wallet, $15,000 for a multichain wallet, with savings up to 40% compared to in-house development.
More about standards: see the BIP-39 specification and BIP-44 specification.