Multi-chain wallet (Ethereum, BSC, Polygon, Solana, TON)

Multi-chain wallet: where the logic breaks as networks grow

A multi-chain wallet doesn't break on the first network, but on the third or fourth. As long as a single chain is supported, the logic of signing, balance accounting, and transaction tracking lives in one place and works predictably.

As soon as Ethereum, BSC, Polygon, Solana, and TON are added, each network brings its own rules: a different address format, its own fee model, its own moment of transaction finality. And that's when failures start surfacing that simply don't reproduce in single-network tests.

The first and most noticeable one is balance desynchronization.

The wallet shows a balance on one network, while the debit goes through on another; after sending tokens, the interface still holds the old amount for some time, because updates across networks arrive with different delays.

The user sees an "incorrect" balance and either repeats the operation or loses trust in the app. The cause is not a single shared data bus, but fragmented requests to each network without a single state reconciliation point.

The second class of failures is stuck transactions. In networks with different loads, a fee that is adequate for one chain turns out to be insufficient for another, and the operation gets stuck waiting for a long time.

Without proper status handling, such transactions are neither replaced nor canceled — they just hang, and the user can't tell whether the funds were debited or not.

The third is signing errors. Different networks require different signature formats and different key derivation schemes, and a single mistake in this layer leads to the transaction being rejected by the network or signed with the wrong key.

Below we break down how these failures are closed at the architecture level, rather than with point fixes.

What a unified multi-chain wallet architecture delivers

A unified wallet architecture is built around a single signing layer and a single state-tracking layer, while network differences are pushed out into adapters.

Ethereum, BSC, Polygon, Solana, and TON operate through different account models and signature formats, but the client sees one balance, one history, and one sending flow.

This is the main measurable effect: a new network is connected via an adapter rather than by rewriting the core — the time to add one shrinks from weeks to days, while the logic for confirmations, retries, and fee display remains shared.

The second effect is the share of successful transactions.

When an incorrect nonce, a stale gas price, or a rejected node is handled in one place rather than differently on each screen, the user gets a clear reason for the failure and a correct retry instead of "transaction failed." In practice, this raises the share of operations brought through to confirmation and reduces the flow of support requests for typical failures.

The third is recovery time after a node or provider failure.

Adapters are isolated, so the failure of one data provider does not bring down the other networks: traffic switches to a backup source, state is pulled from the local cache, and the queue of unconfirmed operations is replayed once connectivity returns.

The class of failure narrows from "the wallet is down" to "one network is temporarily unavailable."

Such an architecture pays for itself not on its own, but over the long run: each subsequent network and each new feature fits into ready-made layers rather than dragging a rebuild of the product along with it.

Implementation approaches: built-in modules, external services, hybrid

When an application supports Ethereum, BSC, Polygon, Solana, and TON simultaneously, the key choice is where the transaction signing logic and network handling live.

This determines launch timelines, control over keys, and how the wallet will behave when a sixth or seventh network is added. Let's break down three schemes that are realistically chosen at the start.

Built-in modules provide maximum control: private keys never leave the device, signing is done locally, and the wallet's behavior does not depend on third-party services.

The price is that each network requires its own logic for handling addresses, fees, and transaction formats, so as the number of networks grows, the time to add the next one increases non-linearly.

External services remove this burden: connecting a new network often comes down to configuration rather than development. But control over keys is diluted — some operations go through a third-party perimeter, and any failure on the service side becomes a wallet failure.

The hybrid is a compromise, and it is most often the one chosen: keys and signing remain within the application's secure perimeter, while reading balances and sending transactions go through external nodes. This preserves control over keys, and adding a network does not turn into a separate project.

Implementation stages: from auditing the current scheme to handing over the regulations

We start with an audit of the current scheme: we look at how keys are stored now, who and how initiates signing, which networks are already connected, and where the balances diverge.

At this stage we record the risks — from a single shared key for all networks to the absence of an operations log — and only after that do we design the target architecture of the multi-chain wallet.

1. Audit of the scheme and inventory of assets. We compile a list of networks (Ethereum, BSC, Polygon, Solana, TON), address types, and current key storage. The output is a map: where the assets are, who has access, which operations bypass the wallet.
2. Designing the key and access model. We determine which networks run on a shared seed phrase, which require a separate one, and how the operator and administrator roles are separated. We lay out what goes into secure storage and what remains in the hot perimeter.
3. Setting up transaction signing. We assemble the signature for each network taking into account its format: different addressing schemes, different fee fields, different nonce requirements. We verify that the signature is generated locally and the private key never leaves the secure perimeter.
4. Testing transactions on test networks. We run the full cycle — assembly, signing, sending, confirmation — on each blockchain separately. We separately test failure scenarios: a rejected transaction, one stuck in the mempool, insufficient funds for the fee.
5. Operational regulations. We describe the procedure for adding a new network, key rotation, access recovery, and incident response. The regulation must be readable by an on-duty engineer without additional explanation.
6. Handing over documentation and training the team. We deliver architecture diagrams, operation instructions, and verification checklists. We conduct a walkthrough on live scenarios so that the client's team can maintain the wallet independently.

Each stage is closed with a verification — without it we do not move on to the next. This way the output is not a set of scripts but a working system with clear control points and predictable behavior in the event of a failure.

Access policies and key management in a multi-chain wallet

Key management is the part of a wallet where a configuration error costs the most: a single leaked seed file zeroes out the entire balance across all networks at once.

That is why we hand over to the client not a "working application," but a set of artifacts that the team can use to safely operate and evolve the product without us.

• Key storage scheme — where the private key lives (secure device storage, hardware module, encrypted server-side storage), how the hot and cold perimeters are separated, and what happens if a device is compromised.
• Access policies — a role matrix: who signs transactions, who changes limits, who only views balances; rules for confirming large operations and separation of duties among administrators.
• Network configurations — files with connection parameters for Ethereum, BSC, Polygon, Solana, and TON: node addresses, backup providers, fees, timeouts, and failover rules when the primary channel is unavailable.
• Backup and recovery regulations — how and how often encrypted copies are saved, where they are stored, and how access recovery is verified on a test perimeter.
• Signing flow diagram — a diagram showing the path of a transaction from the interface to submission to the network: where limits are checked, where confirmation is triggered, and where the event is logged.
• Key rotation documentation — a step-by-step procedure for scheduled key replacement and revocation of compromised keys without service downtime.
• Operations audit log — which events are recorded, in what format, how long they are retained, and how they are exported for incident investigation.

Each artifact is coordinated with your security service and delivered in working form — not as a draft, but as a document by which a new engineer is onboarded into the project within days.

Case study: how we cut the share of stuck transactions by three times

The task came from a team running a multi-chain wallet with support for Ethereum, BSC, Polygon, Solana, and TON. Users complained about "stuck" transactions: funds were debited from the account, but confirmation on the network never arrived.

The share of successful transactions held at 82%, and support was drowning in identical requests — every second ticket was about "the money left but never arrived."

What it was before

The analysis revealed three causes.

The first was a single confirmation timeout for all networks: where blocks come out fast, the transaction was already in a block, but the wallet was still waiting and showing the status "processing." The second was an incorrect fee calculation during peak load: the transaction went out with an underestimated rate and hung in the mempool for hours.

The third was manual recovery: an engineer pulled up the history from logs, which took up to 40 minutes per request.

What was changed

We set up a separate confirmation policy for each network and added automatic recalculation of the fee based on the current load before sending.

We introduced background status monitoring: if a transaction is not confirmed within the estimated window, the system automatically resends it with a correct rate, and the user sees a clear status instead of endless waiting.

What it became

The share of successful transactions grew from 82% to 96%. The time to add a new network dropped from two weeks to three days — the network configuration is described declaratively, without changes to the core.

The recovery time for a stuck operation fell from 40 minutes to 5: the scenario is handled by automation, and an engineer gets involved only for non-standard cases. The flow of support requests on this topic dropped by roughly three times.

The project was led by a Trust Wallet-class multi-chain signature scenario — we moved the logic onto our own architecture and closed off the class of stuck transactions at the sending level, rather than by sorting out the consequences.

How is a multi-chain wallet different from a set of separate wallets?

Separate wallets are several independent key stores, each with its own format, its own seed phrase, and its own signing method.

The user maintains N applications or N profiles with no shared state between them: balances are not aggregated, history is not collected, and transferring between networks requires manually moving an address from one window to another.

Mistakes at this junction are not uncommon, because address formats differ across networks and the human eye cannot tell them apart.

A multi-chain wallet is built around a single interface and a shared registry.

Key material is derived once from a single seed phrase along different paths, and each network gets its own correct address — while the user sees a single list of assets and a single transaction history.

The registry stores state across all networks in a unified model, so balance, fee, and transaction status are read the same way regardless of which network is under the hood.

End-to-end signing is the main technical difference. A transaction is assembled in a common layer, signed once, and sent to the required network in its own format: in some cases it is an account model with a nonce, in others UTXO-like logic or a different confirmation scheme.

The user confirms the action once, and the wallet itself adapts the signature to the network's requirements — without switching applications or re-entering a password.

Hence the difference in operation. A set of separate wallets yields N points of failure, N updates, and N places where a key can leak. A single wallet reduces this to one perimeter: one access policy, one audit, one recovery scenario.

Adding a new network is an extension of the registry and the signing adapter, not a new application that the user will have to learn from scratch.

What to do if one wallet is already deployed and networks need to be added

A multi-chain wallet extension almost never requires a rewrite from scratch — if the architecture separated the core and network adapters from the very beginning.

Keys, transaction signing, seed phrase handling, and local storage remain shared: they do not depend on which network you are signing in. Only the integration layer changes — the node client, address format, fee rules, and confirmation model.

If this layer is moved into a separate module with a unified interface, adding a network becomes a matter of connecting a new adapter rather than revising the entire application.

As a first step, we look at how ready the current core is for multiple networks at once. We check where assumptions about a single network are hardcoded in the code: address format, fee estimation method, transaction finalization point, reorganization handling.

Each such place is a point that will have to be generalized. Next, we describe a unified adapter contract: balance retrieval, transaction construction and signing, status tracking, and token handling.

After that, a new network is connected as an implementation of this contract, while the user interface and key storage logic remain unchanged.

Migration here is not a data transfer but an extension of the model. Existing wallets continue to work on the previous network, and the new one is added alongside: the same seed, a separate address derivation branch, its own token list, and its own transaction history.

The user does not lose access and does not recreate the wallet. We separately verify that address derivation for the new network produces correct values and that recovery from the seed phrase restores all networks at once.

Integration with external services — block explorers, price feed providers, exchange services — goes through the same adapter layer, so that a failure of one provider does not bring down the other networks.

We add isolation: errors in the new network do not affect the operation of already connected ones. Tests are extended to the new scenario — signing, sending, confirmation, rollback on rejection.

Practice shows: with a separated core, adding a network takes weeks rather than months and does not require freezing the current release.

If the core is monolithic, we first extract the adapter layer on the existing network — this is a safe refactoring without changing behavior — and then connect the new ones. This way, expansion proceeds without a rewrite and without risk to active users.

Let's discuss the task: we'll come back with an estimate and a plan

For the estimate to be realistic rather than an "industry average", we need to understand the boundaries of the task: which networks are in the first version, where the keys come from, who is responsible for the node infrastructure.

Below are the questions we ask at the start. The answers to them turn into a work plan with stages, timelines, and areas of responsibility.

• Which networks are mandatory in the first version, and which can be added later without reworking the architecture?
• How are keys stored: only on the user's device, or is recovery via a seed phrase and the cloud assumed?
• Are hardware wallets and connection of external signers needed?
• Who provides access to network nodes: in-house infrastructure or third-party providers, and are there fault-tolerance requirements?
• Which operations are critical: transfers, in-app exchange, staking, working with tokens of different networks' standards?
• Is support for multiple accounts, multisig, or roles for team access required?
• Which security checks are mandatory: code audit, penetration testing, a vulnerability bounty program?
• Are there regulatory requirements and rules for storing user data in specific jurisdictions?

After the review, we come back with a stage-by-stage estimate, a release plan, and a description of how support will be organized after launch. Describe the task in a convenient format — correspondence, a call, or a short description with example scenarios.