Multichain wallet: where signing and balance accounting break
The first blockchain in a multichain wallet almost always works predictably: one account model, one transaction signing scheme, one way to calculate balance.
The second and third networks break these assumptions — and this shows up not in the interface, but in two places: transaction assembly and signing, and balance accounting.
Addresses and keys in different networks are structured differently: a hex string, base58, bech32 with a checksum — one mnemonic generates different derivation paths, and an address cannot be verified by simply comparing length.
If the signing layer was written for one network, its account model and operation numbering order are pulled into it, and transaction signing becomes valid not where it is expected.
Balance accounting is more complicated: "balance" is at least three different numbers. Confirmed on the node, available for spending taking into account already sent and not yet included operations, and awaiting finality.
If the wallet shows one of them as the total, a state discrepancy occurs: the debit went through, but the amount did not change, or more is available than actually exists.
A separate problem is stuck transactions. In networks with an account model, a skipped operation number blocks the entire queue behind it, and without an explicit replacement or resend, the wallet simply stops moving funds.
Where finality is probabilistic, a block rollback zeroes out already recorded debits and adds duplicates of unaccounted operations.
We examine how this is addressed: a unified signing layer with a description of each network, independent balance accounting per channel, and controlled handling of stuck and rolled-back operations.
What a unified signing and accounting layer across all networks provides
A unified signing layer removes the main cause of discrepancies between networks: each has its own address format, its own key model, and its own outgoing transaction counter.
When this logic lives in one module, adding a new network comes down to describing its rules in configuration, rather than a separate code branch.
The time to connect a new network is measured in days, not weeks: an engineer adds the signature formation scheme and the node selection rule — the rest works as is.
Operation accounting is built around a unified state journal: a transaction is recorded at each step — formed, signed, sent, confirmed.
If confirmation does not arrive within the estimated window, the operation does not hang in uncertainty but returns to reconciliation and is resent with the correct counter.
The share of stuck operations drops to single-digit percentages, and the most expensive failure class disappears — counter reuse and double sending.
Fault tolerance rests on several nodes per network: the signing layer compares block height and state discrepancy, and when a node degrades, switches the flow to a backup.
Recovery time after a node failure is minutes, and downtime duration does not grow with the number of connected networks.
A separate failure class is also addressed, where the signature went out but the transaction was lost: the journal stores the signed package, and it is delivered to the network again.
Total five measurable effects: time to connect a new network, share of stuck operations, recovery time after a node failure, downtime duration, and the eliminated failure class.
All of them are read from a single monitoring screen, so degradation is visible before users write about it.
Ways to connect a multichain wallet: comparison of modes
A multichain wallet signs transactions in several networks at once, and the key decision here is where the signing module lives and how isolated it is from the rest of the code.
This determines the operating modes, the attack surface, and how to later change the scheme without rewriting the client.
There are three options: the choice is determined by the number of platforms, requirements for owner confirmation of the operation, and load.
| Option | When it fits | Limitations |
|---|---|---|
| Built-in signing module | One client, one platform, short path to release | Key lives in process memory; changing the scheme is an app release; scales poorly to several platforms |
| Separate signing service | Several clients, unified policies and operation journal | Trust channels, client authentication, queue and audit; the service itself becomes a point of failure |
| Hybrid with hardware keys | Large amounts, owner confirmation of the operation | Threshold on number of operations, firmware updates, some scenarios require the owner's presence |
The modes are compatible with each other if the signing contract is moved into a separate layer: the built-in module and the signing service implement one interface, and hardware keys connect as another executor.
Then switching between schemes is a replacement of the implementation, not a rewrite of business logic and address accounting.
Implementation stages: from network audit to handover of regulations
The order of work is arranged so that irreversible decisions — key storage scheme, signature format, accounting model — are made only after a complete picture across all networks has been assembled. First inventory, then design, and only then code. Below are the seven stages that multichain wallet implementation goes through.
- Integration audit. We gather what already exists: which networks we connect, through which nodes and services we get balances and history, where keys are stored, what access restrictions exist. The output is a dependency map and a list of risks with effort estimates.
- Flow diagram. We capture on the diagram account creation, transaction signing, top-up, balance accounting, and operation history. A discrepancy not caught at this step results in reworking the wallet core.
- Signing and accounting setup. We create a unified signing interface for different curves and transaction formats, separate the hot and cold key environments, and set up transaction counter accounting for each network.
- Testing on test networks. We run the full cycle: creation, top-up, transfer, rollback of a failed operation. Test networks allow repeating the scenario as many times as needed and catch format discrepancies before release to the main network.
- Load testing. We feed a real traffic profile — peak balance requests, concurrent signatures, behavior when a node is unavailable. We look at response time and failure rate, and fix bottlenecks before release.
- Documentation. Regulations for working with keys, flow diagram, configuration description, instructions for adding a new network by your own team.
- Handover to the customer's team. Walkthrough with engineers, issuance of accesses and regulations, we fix the rollback point to the previous version and the update procedure.
Delivery scope: configurations, keys, diagrams, and regulations
A finished wallet without configurations and regulations does not survive at the customer's site: at the first node failure or team change, the logic starts being reconstructed from chat history.
Therefore we close the delivery not with a build, but with a set of artifacts by which the product can be launched, extended, and handed over to another team.
- Network connection configurations — node addresses for each network, failover order when the primary is unavailable, timeouts and retries, request limits, switching points between test and production environments.
- Access policies and roles — permission matrix for operators and services, separation of the right to sign a transaction and to change configuration, mandatory logging of actions with the executor identifier.
- Integration diagrams — diagrams of interaction between the wallet core and billing, indexer, and external services: request formats, events and notifications, data flow for addresses, balances, and operation history.
- Key regulations — who initiates key creation, how the mnemonic phrase or secret sharing scheme share is stored and restored, rotation procedure, and sequence of actions in case of compromise.
- Support documentation — architecture description, deployment and rollback instructions, list of metrics and alert thresholds, typical errors and what the on-call shift should do.
- Set of acceptance scenarios — wallet recovery from backup, sending a transaction in each supported network, behavior when a node is unavailable and when state is out of sync.
We hand this over as a block: we go through each item together with the customer's engineers, show which parameter is responsible for what and what will happen if its value is incorrect, so that the configuration does not remain a "black box".
Need such a scope for your multichain wallet — describe the task, and we will come back with an estimate and plan.
Case study: how the share of stuck operations was reduced
The wallet works with three network families — EVM, Solana, and Cosmos, and each has its own operation confirmation model.
Because of this difference, transactions hung in an intermediate state: the node went into synchronization, the network rejected the signature, and the user saw "sent" where there was no debit.
Each case was analyzed manually using logs, balances between networks diverged, and support could not answer whether the operation had completed.
We moved processing to a unified operation status and automatic retry with an idempotent key: attempts go with increasing delay and a hard limit, and exceeding it moves the operation to an explicit "requires investigation" status.
Diagnostics rest on a single identifier — it shows the network, attempt number, node response, and failure reason. The most sensitive area turned out to be Solana: confirmation there comes in waves, and without a key, retry produced duplicates.
What was chosen for resending
| Option | When it fits | Limitations |
|---|---|---|
| Timer-based retry without a key | one-off operations in one network | duplicate debits with an unstable node |
| Automatic retry with an idempotent key | multichain with a high share of retries | state reconciliation needed after the attempt limit |
| Fully manual investigation | rare large transfers | does not scale to an operation stream |
Result after implementation
The share of stuck operations decreased from approximately 7% to 0.4% of the daily flow, average diagnosis time — from several hours to a couple of minutes.
Background reconciliation of balances between networks runs on a schedule and flags discrepancies before the user notices them.
What to do if the solution is already deployed for one network?
If the wallet already works for one network, the problem is usually not in the interface: signing logic, address format, and account state model are wired through the entire product — from key storage to operation history.
Adding a second network "next to it" does not work: each new network brings conditional branches in the shared code. Below is the procedure for moving to several networks without rewriting the product.
Refactoring starts not with code, but with boundaries. Key storage, encryption, biometrics, domain entities of the account and transaction remain in place — they do not depend on the network.
We change only the areas where the decision "how to sign and how to send" is made: this gives a minimum of edits in already tested scenarios.
The first step is moving the signing layer into a separate module behind a stable contract: input is a signing request, output is a signed payload.
Implementations are hidden behind adapters, because cryptographic schemes, key derivation paths, and address format are different for each network — EVM networks have one, Solana and Cosmos have others.
The product continues to work on the current network: the interface already exists, and there is only one adapter so far.
Next, the transaction and state accounting layer is moved out: payload assembly, fee calculation, confirmation tracking, balances, and tokens. Here the common scenario "prepare → sign → send → wait" works, and network differences go into implementations.
Backward compatibility rests on the fact that old addresses, keys, and history remain valid: data schema migration proceeds as a separate reversible step, not together with refactoring.
The order is as follows: fix boundaries and contracts, move out the signing layer, cover it with tests on the current network, then add the first new network as an adapter, and only after that touch the interface and state.
Each subsequent network is connected by a module, not by branches throughout the code, and rollback to the previous version remains functional.
Limitations of the approach and common technical doubts
The scheme is not suitable where instant access to assets without the owner's involvement is needed: custodial storage and access recovery via a support request is a different architecture, and we discuss this at the estimation stage, not after release.
Networks whose addressing model differs from EVM, Solana, and Cosmos require a separate solution — signing and transaction assembly for them are built anew.
Below are the doubts that most often come up during technical reviews.
Where are private keys stored?
Keys are generated and remain on the user's device; only the signed transaction goes outside. The server has neither the recovery phrase nor a copy of it, so infrastructure compromise does not give access to assets.
What happens when the network is unavailable?
Signing is performed locally and does not require a connection. The transaction is queued for sending, the client switches to a backup node, and the balance from the cache is marked as unconfirmed — the user will not mistake a stale value for fact.
How much work does connecting a new network take?
The network is connected by an adapter in the translation layer: the interface, storage, and recovery logic do not change. We roll out new networks in iterations, without rewriting the wallet core.
How is access restored if the device is lost?
The base path is a recovery phrase of 12 or 24 words. Additionally, we design key sharing between several holders and test the scenario on test networks before release, so that recovery does not remain theoretical.
Let's discuss the task: what is needed for an estimate and plan
To come back with a project estimate, work scheme, and stage-by-stage work plan, rather than with clarifying questions, we need a short set of inputs.
Describe the task in words — we will work out the rest together: it is enough to list the networks, usage scenarios, and current state of the code, if any.
What helps estimate the scope more accurately:
- List of networks and standards: EVM-compatible, Solana, Cosmos — which are first in line, and which are "for future growth".
- Key storage model: non-custodial wallet, hardware signer, multisig — architecture and scope of security checks depend on this.
- Platforms: mobile apps, web, browser extension — and whether synchronization between them is needed.
- Scenarios: sending and receiving assets, staking, exchange, connecting to external services through the wallet.
- Integrations: network nodes and access providers, transaction history indexers, analytics, customer checks if necessary.
- Constraints: security and audit requirements, launch deadlines, who on the customer side makes product decisions.
- Current state: ready code, prototype, design — or starting from scratch.
Based on these inputs, we assemble a work scheme: which modules we separate, what we do first, where the bottlenecks in terms of deadlines are. We come back with a stage-by-stage plan, team composition, and acceptance criteria for each stage.