Web Wallet Development: Where Security Breaks
A web wallet operates in the most hostile environment possible: a private key coexists with the browser, third-party extensions, and the open internet.
Web wallet security problems almost always come down to three points of failure — storing keys in the service's memory, signing transactions on the client side, and the lack of isolation of the signing node. Each one alone is enough to lose user funds and trust in the product.
The most expensive scenario is custodial storage: the key or mnemonic phrase BIP-39 sits in the service database and ends up in memory dumps, logs, backups, and test environments.
Leakage of private keys is irreversible — addresses cannot be reissued, transactions cannot be revoked.
That is why the key storage architecture is designed so that the secret never exists in plaintext anywhere: ciphertext under the user's password, secret sharing between nodes, signing inside a module that does not release the key.
Second point — signing transactions on the client side. A malicious extension or injected script substitutes the recipient address between display and signing, and the user approves something they did not see on the screen.
This is closed by verifying parameters in a trusted layer, checking the address against a whitelist, and explicitly prohibiting blind signing.
Third point — lack of isolation of the signing node. When signing and the application layer live in the same process with shared permissions, compromising the web part immediately opens access to keys.
Signing is moved to a separate service or hardware module without direct network access, and the decision is made by policy: who is allowed, how many operations per day, what requires manual confirmation.
Below we break down how these points are closed by scheme, access rights, and operational rules.
Implementation Effect: Release Speed and Removed Risks
While there is only one network, architecture has almost no effect on pace.
As soon as there are three or four networks, each new integration brings changes to the core, a separate build, and a full regression — the release slips to the end of the cycle, and the chance of touching someone else's code grows with every change.
After rework, the network description is moved into declarative configuration: the core remains unchanged, and connecting a new network comes down to a set of parameters and checks.
This changes two metrics at once.
The time to launch a new network is reduced from weeks to a few days, and the share of manual operations during connection drops: the engineer no longer edits code but fills in the description and runs automated tests on a standard onboarding scenario.
Reducing the risk of compromise rests not on promises but on the trust boundary. Keys do not leave the secure perimeter, transaction signing is performed in an isolated process, and the client side has no access to secrets at all.
An entire class of failures — key leakage through the interface or logs — ceases to exist structurally, rather than through filters on top of the previous scheme.
Recovery time after a failure becomes predictable. State and configurations are versioned, rollback to the previous working version occurs without data migration, so the service returns to operation in minutes, not hours.
Support load also drops separately: typical requests — a stuck transaction, the wrong network, a missing balance — are resolved by automatic diagnostics before the on-duty engineer even reaches them.
Key Storage Models: Comparison and Limitations
The key storage model determines who controls the funds and what happens if one of the parties is compromised.
For a web wallet, this is not a choice of "secure or not" but a set of trade-offs between login convenience, signing cost, and the scope of the service's responsibility.
| Option | When it fits | Limitations |
|---|---|---|
| Custodial storage model | The service signs transactions and restores access; the user only needs to log in | Compromise or failure of the service zeroes out all clients' balances at once |
| Non-custodial wallet | The key is stored by the user; the service does not touch funds | Loss of the key is irreversible; phishing and malicious extensions hit the owner directly |
| Multisignature | Funds are controlled by several parties under an m-of-n rule | Signing is more expensive; the set of participants and key rotation must be agreed in advance |
| Splitting the key between parties | A single point of trust must be removed: parts are held by different custodians | Assembling parts during signing is a separate risk; a recovery procedure is needed |
| Hardware signing module | The key does not leave the module; signing is performed inside the perimeter | Hardware and its maintenance, a ceiling on bulk operations, updates are more complex |
In practice, schemes are combined: a non-custodial wallet with a hardware signing module of FIPS 140 class covers both storage and signing, while multisignature on top of key splitting removes dependence on a single holder.
We fix the chosen model in the architecture before the first line of code — otherwise changing the scheme later rewrites the entire signing layer.
Web Wallet Development: Stages of Engineering Work
The stages go in order: the signing scheme determines which environments and keys to isolate, and the set of scenario checks depends on them. Below is a typical route for a web wallet where private keys do not leave the user's device or a dedicated storage module.
- Audit of the wallet infrastructure. We analyze the current perimeter: where keys live, who has access to them, how roles are issued, what gets into the log. The result is a trust map and a list of places where signing can be intercepted or a transaction substituted.
- Designing the signing scheme and roles. We choose the model: key on the user's device, a threshold scheme with several custodians, or a dedicated signing module on the service side. We fix where a second confirmation is needed and where the operation proceeds automatically.
- Setting up environments. We separate development, test network, and production perimeter so that test keys do not enter the production environment. Configuration, access, and secrets are stored in one place and versioned.
- Scenario and load checks. We run access recovery, device change, rejected transaction, simultaneous signatures from several tabs. Separately — behavior when a network node fails and when a response is delayed.
- Smooth release. We open access to a share of users and monitor the share of successful signatures and network-side failures. Limits on transaction amount and signing frequency are enabled from day one.
- Handover and team training. We deploy the build and release on your side, hand over documentation on the signing scheme and roles plus the incident response procedure. We walk engineers through key rotation.
Handover Kit: Configurations, Schemes, Procedures
Handing over a wallet is not an archive of source code but a working perimeter that the customer's team can deploy and maintain without us.
We assemble the kit so that deploying a new environment takes hours and the first response to an incident does not require calling the author.
- Environment configurations — network parameters, fee limits, asset list, and node addresses for the test, pre-production, and production perimeters. A copy of the stand is brought up by replacing values, without code changes.
- Signing flow schemes — where the key is generated, where the private part is stored, how the transaction is signed, and what checks are in place at input and output. The scheme shows that key material does not leave the secure perimeter.
- Access policies and roles — who views balances, who initiates withdrawals, who confirms an operation. Rights are issued according to the minimum needed for the role, not "just in case" — a new employee does not receive extra capabilities.
- Incident response procedure — steps for suspected key compromise, a spike in atypical operations, or failure of an external service: who stops operations, how the decision is recorded, and what confirms return to normal mode.
- Support instructions — analysis of typical requests, what to look at in event logs, which errors the user resolves themselves, and when a request goes to the on-duty engineer.
- Procedure for key rotation and recovery from backups — with frequency, areas of responsibility, and mandatory verification on the stand before production use.
Case: How a Class of Failures Was Removed and Releases Were Accelerated
A retail crypto service with a non-custodial wallet Aurora Wallet released updates once every two weeks: build, manual verification of contract addresses, build signing, and production deployment followed a 42-point checklist.
When signing in parallel from several devices, session state diverged, and some transactions got stuck in the confirmation queue — analyzing such a case took support up to a day.
Metrics Before and After
| Metric | Before | After |
|---|---|---|
| Manual operations during release | 42 checklist steps | 4 verifiable steps |
| Update release time | about two days | 40 minutes |
| Paths covered by automated tests | 35% | 88% |
| Sticking during parallel signing | 3-5% of operations | 0 during the observation period |
| Rollback to the previous version | about two hours | minutes |
What changed fundamentally: signing was moved to an isolated module with unambiguous construction of signing data, and operations were transferred to a log with replay protection — a repeated request with the same identifier does not create a second transaction.
Network configuration and contract addresses were described declaratively, so the environment is brought up from the repository without manual edits, and a run on the test network became a mandatory stage before production.
The eliminated class of failures — state desynchronization during simultaneous signing — no longer reproduces either in the test network or in production.
Release stopped being an event with night duty: the team ships changes as they are ready and rolls them back in minutes if metrics diverge from expectations.
What to Do If the Wallet Is Already Launched and Running?
A running wallet is migrated to a new storage scheme without stopping the service: a parallel perimeter is brought up alongside, rather than replacing the production one.
Users continue to log in, receive addresses, and sign transactions — on their side, neither the interface, nor the backup phrase, nor the list of addresses changes. Migration proceeds in the background, in batches, while the old perimeter remains the source of truth.
Users' private keys are not recreated in this process — otherwise addresses and balances would change.
The storage and signing layer changes: secrets are re-encrypted under a new root key, and each migrated element is verified by the fact that the decrypted key produces the previous public address.
If verification fails, the element returns to the old scheme and is analyzed separately, while the rest of the batch continues.
Key rotation proceeds in stages: new storage encryption keys and service signing keys are put into operation, while the old ones remain available read-only for the duration of the migration window.
Compatibility with the current wallet is maintained by accepting both formats — previously released client builds continue to sign and do not require an update on the switch day.
We switch by user groups, not all at once: the new perimeter first runs on shadow traffic, where signing results in the two modes are compared byte by byte, and any discrepancy stops the rollout until analysis.
Rollback is a reverse switch on the service side, in which keys in the previous scheme remain valid, so not a single user operation is lost. After verification and an observation period, the old perimeter is decommissioned.
Technical Questions: Security, Integrations, Audit
Customer concerns come down to four topics: where keys live, what happens during a network failure, how integration is verified, and what goes into the report before release. Below are short answers to each.
Where are private keys stored and what happens if the device is compromised?
The key does not leave the client side: signing is assembled locally, and only the signed transaction goes to the server. For elevated requirements, we connect an external signing module or a hardware wallet — then access to the browser is not enough to sign a transfer.
How is integration with networks verified and what happens if a node is unavailable?
Each network is served by several independent nodes with failover, and transaction status is verified against several sources, not a single response. Before release, we run confirmation delays and resubmission — this is a frequent source of "missing" balances.
What is included in code and infrastructure verification before release?
Code review by third-party specialists, dependency checking, access recovery tests and rollback scenarios, revision of rights to servers and secrets. Separately, we make sure that logs do not contain keys and mnemonic phrases — a typical leak from careless logging.
Who has access to the infrastructure and how are updates released?
We grant access on a least-privilege basis, with two-factor verification and an action log; withdrawal of funds requires confirmation from several signatories. Updates go to the test network, then to a limited group, then to everyone — rollback takes minutes.
Let's Discuss the Task and Come Back with an Estimate and Plan
To come back with an estimate and work plan, rather than general wording, we need minimal technical context about the wallet. The more precise the inputs, the fewer assumptions in the estimate and timeline. Below is what is useful to send right away and what we will clarify in the first conversation.
- Supported networks and assets: native coins, tokens, whether balance and transaction history reads by address are needed, or only signing and sending.
- Key model: where the private key is stored — with the user on the device or on the service side, whether hardware wallets and access recovery are needed.
- Security requirements: multi-factor authentication, operation limits, logging, recipient address verification, personal data storage rules.
- User scenarios: wallet creation and import, sending, internal exchange, connection to external services via message signing.
- External integrations: own or third-party network nodes, quote providers, payment services, existing authorization and infrastructure.
- Constraints: browser extension, web application or mobile web, list of supported browsers, availability requirements.
- Current state: prototypes, design, code work, previously conducted security audit.
Then we come back with a stage-by-stage estimate, a team composition for your scope, and a clear plan: a lead blockchain engineer, client and server development, a security specialist, and a QA engineer.
The collaboration format is iterations with a result demonstration at the end of each, access to the repository and tasks, and we record scope changes in writing.
Describe the task in free form — we will come back with an estimate and work plan.