Why crypto wallet development comes down to key storage
Crypto wallet development as an extension begins not with the interface but with the question of where the private key lives and what happens if it is lost.
In an extension there is no trusted server-side boundary: code executes on the user's side, and storage is accessible to several contexts at once — the extension page, the injected script, and the background handler.
Therefore the decision about private key storage in an extension defines the threat model as a whole, and it cannot be reversed after release.
The first bottleneck is the lifecycle. The background handler is unloaded by the browser and started again; in-memory state is not preserved between awakenings.
If the key or the unlocking session existed only in memory, the user gets a wallet that arbitrarily "forgets" the password. If the key is written to local storage in plaintext, any script that gains access to the context takes it.
The second is updates and migrations. A new version arrives with a changed storage schema, and an error in migration causes loss of access to the wallet while the file is formally intact. Rollback does not help: old code cannot read the new format.
Browser extension vulnerabilities are added here too — excessive permissions, broad tab-reading permissions, insecure message passing between contexts.
The third is recovery. Recovery phrase, encrypting storage with a password, exporting keys: if these scenarios are not designed in advance, restoring access after the fact is impossible — the key material is already lost.
Next we break down how each of these areas is closed off engineering-wise.
What the solution gives: measurable effect for releases and incidents
The effect of wallet architecture is visible not in a demo but in operation: how often it breaks, how quickly an update ships, and in how many minutes a user restores access. Below are four metrics that we lock in before work starts so the result is verifiable.
A class of failures related to the key goes away
The private key never leaves the isolated extension context, signing goes through a separate process with a whitelist of methods, and the application page gets no access to storage.
An entire class of failures goes out of operation — key compromise through a script injected into the page — not just individual manifestations of it.
Transaction signing speed
Signing is computed locally, the queue of confirmation requests does not block the interface and does not depend on the response of external services.
In a typical scenario, the path from confirmation to a sent transaction takes fractions of a second and does not degrade as the number of networks in the wallet grows.
Wallet update release time
The manifest, state migrations, and build signing come from a single source in the pipeline. Releasing a wallet update stops being a multi-day manual operation: preparing a version takes hours, and rolling back to the previous one takes one command.
Access recovery time and share of manual operations
The recovery scenario is described and covered by an automated test on a copy of the profile, so access recovery time is measured in minutes, not in correspondence with support.
The share of manual operations decreases: the user goes through the steps themselves, and compatibility with familiar scenarios for connecting to decentralized applications — as with MetaMask — reduces the flow of requests at the first steps.
Crypto wallet development: key storage and signing modes
The choice of key storage mode determines not only the threat model but also the wallet's compatibility with existing infrastructure: payment scenarios, corporate access policies, audit requirements. Below are four options that are actually chosen between at the start, and their limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Service-side key storage | Mass operations, access recovery via ordinary authorization, users without experience with keys | The service becomes a single point of failure and a priority attack target; role separation, mandatory logging of every signature, and external access audit are required |
| Local key encryption | A self-custody wallet where the key never leaves the user's device | Losing the password means losing access; recovery is possible only via a pre-issued backup phrase |
| Multisignature | Shared account management, treasury operations, protection from unilateral decisions | Each operation requires collecting the required number of confirmations — this is slower and requires support for confirmation logic on the service side |
| External signer | Strict security requirements: the key is stored in a hardware module or a separate signing service | A limited set of supported networks and transaction formats; we test the integration separately for each scenario |
In practice, modes are combined: local encryption for everyday operations, an external signer for withdrawing large amounts, and multisignature for a shared account.
We verify compatibility with a full cycle on a test network: wallet creation, signing, rejection, access recovery, and moving keys between modes without losing transaction history.
Stages of work: audit, schema, build, verification, handover
Crypto wallet development follows the principle of "trust boundaries first, code later": reworking key storage on an already-built interface nullifies checks and costs weeks.
Therefore we lock the threat model and data flows before the first line of implementation, and each subsequent stage relies on the confirmed previous one.
Order of stages
- Requirements and threat analysis. We clarify supported networks and assets, the key storage location — encrypted local storage, hardware module, or external signer — and the method for confirming each operation.
- Key flow schema. We design seed phrase generation and import, password encryption, unlocking, signing, and site access rules. Separately — recovery and backup, so losing a device does not mean losing funds.
- Extension security audit. We check the attack surface: isolation of page and background handler contexts, minimal permissions in the manifest, protection against injection of someone else's script and substitution of a signing request.
- Build. We implement the core, interface, work with networks through several independent node providers, support for hardware signers, and key import from other wallets.
- Signing testing. We run not only successful operations: rejected signature, network switch at the moment of confirmation, insufficient funds, repeated sending, data substitution on the site side. Separately, we check that the key does not leak into logs or tab memory.
- Acceptance and code handover. We run automated tests and the build process, describe the storage format and extension update procedure, hand over source code, accesses, and documentation, and train the customer's team.
Delivery artifacts: code, schemas, access policies, procedures
Wallet delivery is not just a built extension archive ready to upload to the store. The customer receives a set of artifacts by which the team can continue development, pass audits, and maintain the product without contacting us for every step. Below is exactly what moves to your side.
- Repository and builds. Branches protected from direct pushes, mandatory review, pinned dependencies — the build is reproducible in a clean environment, not "works only on the author's machine."
- Build pipeline. Type checking, tests on cryptographic vectors, runs in several environments, automatic generation of a signed release package.
- Key flow schemas. Mnemonic generation, address derivation from the tree, transaction signing: where the key is stored encrypted, in which context it lives, and why it never leaves the extension.
- Access policies and roles. Permission matrix for production secrets, separation of access to nodes and external providers, a separate release signing key with a limited circle of holders.
- Wallet documentation. Architectural decisions and their rationale, storage design, build procedure for each browser and store publication, known limitations.
- Maintenance procedures. Frequency of updating dependencies and the manifest, rotation of signing keys, version revocation procedure, responses to incidents and requests about lost access.
Every artifact is transferred to your repositories and storages — without ties to our accounts and without closed sections that cannot be handed over to another team.
Case study: before and after — signing reliability and release speed
The wallet extension lived in a mode of constant fixes: transaction signing failed on some configurations, updates were built manually, and support was drowning in identical requests to restore access.
We analyzed bottlenecks from logs and recorded before metrics — so that after each change we could see the effect, not "it seems better now."
What it was
Share of failed signatures — about 6% of attempts. Causes varied: transaction nonce mismatch during parallel sends, stale balance cache, connection drop in the middle of the confirmation chain.
The consequence — around 140 support requests per week, more than half about lost access to an account.
What was changed and what became
The sending layer was rewritten: one transaction counter per account with a queue instead of parallel requests, rechecking network state after a drop, explicit enumeration of derivation paths instead of blind search — rare addresses stopped being lost.
Integration with Ledger hardware wallets was moved into a separate module with a predictable signing interface.
Access recovery was made deterministic: from the seed phrase, the extension itself goes through addresses and restores accounts, without correspondence with support.
Build and checks were moved to an automated run on a test chain — signing is tested on a configuration matrix before publication.
Share of failed signatures — 0.4%. Release of an update dropped from three weeks to four days together with a full run of checks.
Support requests fell to 30–40 per week, manual access recoveries — zero: rolling back to the previous version is done with one command and does not break key storage.
How does local key storage differ from server-side storage?
The signing key is the wallet: whoever owns it controls the assets. Therefore the fork is not in the extension interface, but in where the key material lies and who is responsible for its safekeeping — the user's device or our server.
With local storage, the key is encrypted with a password and remains in the extension's protected storage, and signing is assembled on the device — only signed data goes out.
Our side does not see the key, leakage from our storage is ruled out by design, but access recovery is possible only via a backup phrase saved by the user.
Server-side key storage provides synchronization between devices and access recovery via email or second-factor confirmation.
The price for convenience is a different threat model: a target for attack appears in our perimeter, and separation of employee permissions, an operations log for key material, and encryption on the service side are required.
The choice is dictated by the wallet's threat model: whether we protect against device loss or against our own operator.
A workable compromise — the key remains on the device, and the service holds a backup encrypted on the client: recovery works, and the copy cannot be read on our side.
Hence the obligations to the user: with a local scheme, support will not restore access or issue the key on request; with a server-side scheme, we become the holder of key material — with requirements for access and incident disclosure.
The fork is fixed in the architecture before release: on a live wallet it is changed together with user migration.
Technical doubts: keys, updates, code checks
Updating the extension in the browser must not turn into loss of access to funds.
Keys, addresses, transaction history, and network settings are stored locally on the device in encrypted form, and between versions they are transferred by a migration schema that runs once on the first launch of the new build.
Below are the doubts most often voiced before work starts, and how they are closed engineering-wise.
What happens to keys when a new version is released?
Keys are not recreated and do not leave the device. The update changes only the code and the format of local data: a transition schema reads the previous format, transfers records, and writes the new one, keeping a backup until successful transfer is confirmed.
If migration fails, the extension returns to the previous state rather than opening with an empty address list.
How to add a new network after release?
Networks are described declaratively — by a separate profile with connection parameters and address formation rules — so the core does not need to be rewritten.
Support for a new network is added by configuration plus testing of operation signing on a test perimeter; user keys and balances are not affected.
Can the wallet work without a server-side part?
Yes. The client accesses network nodes directly, and the extension stores only encrypted data on the device. The server-side part, if one is provided, is responsible only for delivering updates and reference metadata — and has no access to keys.
How does code audit and handover to the team work?
Source code, storage schema, key access policy, and audit report are transferred together with the project. Separately, we record the list of external dependencies and the procedure for tracking their updates, so maintenance does not require the constant involvement of our team.
Let's discuss the task: send inputs, we'll come back with a plan
To order crypto wallet development without a series of clarifying emails, the estimate must rely on facts, not assumptions. Below are the task inputs that most shorten the time to prepare a response and remove assumptions from the calculation.
- Target platforms and browsers, including mobile builds: the extension manifest format and available API set depend on this.
- Networks and assets: EVM-compatible, UTXO, or multichain; whether token and NFT accounting is needed.
- Key storage model: non-custodial, with hardware signing or multisignature, and access recovery scenarios.
- First release scenarios: transfers, exchange, connection to decentralized applications, staking.
- Security and access separation requirements: audit, transaction source verification, operation limits.
- Integrations: own node, transaction indexing service, quote provider, analytics — what already exists and what we do.
- Current product state: prototype, ready-made mockups, existing code that needs to be developed rather than rewritten.
In response, we send a solution diagram with component boundaries and key storage location, the scope of work by stage, a work plan with milestones, and open questions affecting timelines.
The wallet development estimate is built on task decomposition, so next to the stage range we indicate the assumptions under which it holds. Describe the task in free form — we will come back with an estimate and plan.