Why a mobile HD wallet loses access to funds
A mobile HD wallet keeps all access to funds in a single root secret: from it, a chain of keys for addresses is deterministically derived, and the mnemonic phrase remains the only carrier that can be restored on another device.
While the app lives on one phone, the scheme is unnoticed. The failure manifests at the moment of restoration or update and looks like a missing balance, although the funds never went anywhere.
The most common cause is a desynchronized address index. The wallet issues the user a new receiving address, but during restoration it scans fewer positions than were actually used and stops at the first empty gap.
Transactions exist on the network, but the interface shows zero: the user perceives this as loss of access and comes with a complaint about the product, not their own backup.
The second class of failures is a reused key chain. Reinstalling over an old profile, two copies of the app writing to the same local storage, or a backup taken in incomplete form lead to addresses diverging, and part of the history remains outside the current branch.
The industry standard here is the BIP family of standards: they define derivation rules, but do not protect against errors in applying them.
The third failure is incorrect migration between storage versions. The encryption scheme or key derivation path changes, old records cannot be read, the app starts with an empty profile and does not report this explicitly.
Below, we analyze how these scenarios are closed at the level of storage architecture and address accounting.
What reworking the wallet architecture changes
Reworking the wallet architecture changes how an HD wallet stores key material, restores state, and synchronizes with the network. The result is measured in minutes of downtime and in the number of scenarios that cease to be possible.
Restoring access in minutes instead of support correspondence
At the core are the mnemonic phrase and deterministic address derivation: the user enters it on a new device and gets the same set of addresses without contacting support. Access restoration time drops from hours of correspondence to a few minutes. We verify:
- Reinstallation and entering the phrase restore all addresses and transaction history; the scenario is covered by an automated test on a clean device.
- Instructions for the “lost phone” case are in the app, not in support correspondence.
- After returning to the network, missed blocks are caught up without manual intervention.
Eliminated class of failures: key leakage during backup
Backup stops copying private keys: only an encrypted container or the phrase, which the user stores separately, is saved. This removes an entire class of failures — key compromise through cloud copies and system device snapshots.
We verify requirements against external security guidelines, such as OWASP Mobile Application Security. Checklist:
- Keys do not get into cloud copies and system snapshots.
- Encryption strength is verified by tests for weak and repeated passwords.
- Rollback to a previous app version does not break access to created addresses.
Key storage modes: comparison of approaches
The private key storage mode defines the threat model: where the key lives, who signs with it, and what happens if the device is compromised. Below are five options that are actually chosen between when designing an HD wallet.
| Option | When it fits | Limitations |
|---|---|---|
| Key in app memory | Prototype, closed environment, no strength requirements | Key gets into a memory dump, no protection if the device is lost |
| Key in the device's secure storage | Mass-market wallet: key is bound to the device | Restoration only by mnemonic phrase, platform binding |
| External signer | Signing is moved to a separate component | A secure channel is needed, signing latency grows |
| Multisignature with role separation | Corporate scenarios, sole control is excluded | More complex role accounting and recovery if a part is lost |
| View-only mode | Monitoring balance and history without signing | No signing inside the app, dependency on the signer |
When each mode is justified
For a consumer wallet, a key in the device's secure storage and a watch-only mode on a second device are sufficient. Corporate schemes require multisignature with role separation; services with automatic withdrawal of funds require an external signer. Modes are combined: view-only without signing rights is granted to support and analytics.
The cost of an error in choosing a mode
The error is not visible in tests: the app works, transactions go through. It is revealed at the moment of an incident — when a device is lost, a backup leaks, or an employee leaves with a key.
Rework affects address derivation and migration of already created wallets, so the mode is fixed before the first release.
Work stages: audit, key scheme, verification, handover
The order of work is structured so that the irreversible parts — the key scheme and the signing module — are designed after we understand the current storage and restoration requirements.
Below is the sequence the project follows: each stage ends with an artifact that can be verified before moving to the next.
- Wallet audit. We analyze the current secret storage, the method of obtaining addresses, operation logs, and how access is restored today when a device is lost. The output is a map of bottlenecks and a list of decisions that cannot be changed after release.
- Key scheme. We fix the key tree and derivation paths, distribute branches for networks and address types, and describe the mnemonic derivation procedure and its storage rules. Here we also determine which keys do not leave the device's secure area at all.
- Signing module and access policies. We implement transaction signing inside an isolated module, configure limits, confirmation of large operations, and separation of rights between roles. The signing log contains no secrets but allows restoring the chronology of events.
- Restoration and migration. We describe transferring the wallet to a new device, changing the password, and correct rollback to the previous state if an update was interrupted. We verify that previously created addresses remain accessible.
- Testing on failure scenarios. We run through device loss, connection interruption in the middle of a transaction, corrupted storage, and app reinstallation. Each scenario has an expected result and clear interface behavior.
- Documentation handover and training. We hand over the key scheme, signing policies, restoration instructions, and analysis of known limitations. We train the team so that changes are made according to regulations, not by editing on the fly.
Handover artifacts: schemes, policies, procedures
Handover does not end with transferring the repository. The client must be left with a set of documents by which their engineers can build a release, grant access to a new employee, and restore a user's wallet without us.
Technical part
- Key chain scheme: how branches for coins and accounts are derived from the mnemonic phrase, which paths are considered main, and which are reserved for service addresses.
- Signing module configuration: key derivation parameters, local storage encryption mode, operation confirmation rules and limits after which additional consent is required.
- Storage access policies: a role matrix under which signing and backup export are unavailable to one person, and actions are written to an immutable log.
- Migration instructions: the procedure for transferring existing wallets and re-entering the mnemonic phrase so that addresses and balances remain the same.
Organizational part
- Access restoration procedure: separate scenarios for a lost device, forgotten password, and partially lost backup — indicating who performs each step and within what timeframe.
- Key revocation and rotation procedure: what is considered a compromise, who makes the decision to change, how old addresses are retired, and what happens to incomplete operations.
- Release checklist: build checks on the test network, wordlist checksum verification, running restoration from backup, and final checks before publishing to app stores.
The set is maintained together with the code: a change to the key scheme or access policies requires updating the document in the same change, otherwise it becomes invalid.
Case study: restoring access without re-releasing the app
A non-custodial HD wallet stores keys only on the device, so loss of access is not a server failure but a restoration scenario: the mnemonic phrase, word order, and choice of derivation scheme from Bitcoin Improvement Proposals.
This was exactly the step where the client's problems accumulated: the signing logic worked, but the user often could not restore their wallet.
What was before
The share of support requests about loss of access accounted for about a quarter of all tickets. Restoration was done manually: correspondence, screenshots, an engineer checked the words and manually tried variants of derivation schemes, responding on average after several days.
Less than half of those who contacted support had access restored on the first attempt — the rest wrote again, and some left and did not return.
What happened after
We added step-by-step phrase parsing: input normalization, wordlist hints, and explicit diagnostics — which word fails validation and why. The derivation scheme is selected automatically from a list of known ones, and the user immediately sees the variant with a non-zero balance.
Restoration time shrank to a few minutes, the share of successful first-attempt attempts grew to 96%, and the volume of manual support operations fell by an order of magnitude.
The migration took place without re-releasing the app: only the restoration module changed, it arrived with the next update, and existing wallets continued to work as before.
A similar scenario was discussed in a publication — description of implementation and measurements before and after.
How an HD wallet differs from a single-address wallet
An HD wallet is not 'many wallets in one', but a single seed from which a key tree is deterministically derived. A single-address wallet stores a single pair: change the address — get a new wallet and a new backup.
In an HD wallet, the seed is encoded by a mnemonic phrase, and keys are derived along paths — account, coin, branch, index.
Restoration. A single phrase is enough to restore the entire tree, including addresses the app has not yet shown — and the backup does not grow with their number.
With a single wallet, the backup is compact exactly until the first new address: after that it needs to be reissued, while the previous version quietly turns into garbage.
Transaction privacy. A single address links all incoming funds into one visible chain: an observer sums up turnover, counterparties, and remaining balance.
A new address for each incoming payment breaks the link — history can only be reconstructed from external signs, not from the wallet structure.
User support shifts because of this: one phrase covers the “lost device” scenario, but the cost of an error in the derivation path and network choice grows — with a formally correct phrase, a person sees an empty balance.
| Feature | Single address | HD wallet |
|---|---|---|
| Restoration | by key, backup is updated on change | one phrase restores the whole tree |
| Address reuse | one for all operations | new one for each incoming payment |
| Backup size | fixed, becomes outdated on change | does not grow with the number of addresses |
| Transaction privacy | incoming payments are linked into a chain | links are broken across addresses |
| Support effort | simple requests, frequent access losses | fewer losses, higher cost of path errors |
Common technical questions and applicability boundaries
Below are five questions that most often arise before the start. They concern not the choice of technologies but the boundaries of responsibility: the answers determine both the architecture and how the app will behave a year after release.
Private keys do not leave the user's device: the server side is responsible only for exchange rates and balance aggregation. This limits some scenarios, but it removes an entire class of risks — leakage through our server.
We already have a released app — does it need to be rewritten from scratch?
No. We look at the key storage scheme and the format of derived addresses: if they are compatible with the standard, the core remains, and the network layers and interface change. It only makes sense to rewrite the core that does not provide access to derived keys.
Who stores the user's keys?
Only the user themselves. The seed phrase is generated on the device and stored in secure storage; we do not have a copy — we physically cannot restore access for the user. Therefore we embed backup into the first launch, rather than hiding it in settings.
What happens if the device is lost?
Restoration proceeds by seed phrase on a new device: addresses are derived again from the same root, balances are pulled from the network. Nothing is required on our side, but this scenario is tested separately — it is verified differently from a normal login.
How are new networks added?
Through the network description and the derived key path: the core does not change; configuration and the transaction signing module for that network are added. If the network has a different address or signature format, the scope of work is estimated separately.
How is the correctness of key generation verified?
By comparison with reference test vectors: the same seed must produce the same addresses under BIP-39 and BIP-44. Plus a set of restoration tests — an error in a derived key leads to irreversible loss of access, not a clear error in the logs.
Let's discuss the task and come back with an estimate and plan
The analysis begins with your storage scheme: how the mnemonic phrase is formed, where the keys live, how transactions are signed, and what is already covered by checks. The scope of work and which risks become security requirements depend on these details.
After contacting us, you receive:
- analysis of the current key storage and address derivation scheme — what we keep, what we rebuild for BIP-39/BIP-44;
- list of risks: mnemonic phrase leakage, weak local storage protection, lack of checks during restoration;
- wallet architecture option — hot and cold loops, key isolation, network interaction;
- sequence of work and an implementation plan with a verifiable result at each iteration;
- team composition: mobile platform developers, cryptography engineer, QA engineer;
- handover format — documentation, builds, update and support procedure;
- timelines: a range with assumptions it depends on, not a single convenient number.
The more precisely you describe the current scheme and constraints, the fewer assumptions will remain in the estimate. Describe the task — we will come back with a work estimate, timelines, and an implementation plan.