Production-Ready Multi-Network Crypto Wallet Development

Developing a crypto wallet that supports multiple networks is not just "connecting multiple networks". It is a complex system that must correctly handle fundamentally different blockchain architectures: EVM-compatible chains (Ethereum, Arbitrum, Polygon, BSC), EVM-incompatible ones (Solana, Sui, Aptos), Bitcoin with its UTXO model, and the Cosmos ecosystem with IBC. Each has its own cryptography, transaction format, fee mechanism, and account model. Without proper abstraction, supporting each new network becomes a rewrite of half the codebase — that's how bugs are born and deadlines slip. Additionally, questions of gas optimization arise: in EVM networks the transaction cost depends on gas, while in Solana it depends on priority, requiring different fee estimation strategies.

We solve this problem with a Chain Abstraction Layer — a unified interface for all networks. This allows adding a new chain in 1–2 weeks instead of 2–3 months. In practice, this saves up to 40% on each integration, with typical project costs starting from $50,000. This approach is 3 times faster than manual implementation. With our 10+ years of blockchain experience, we guarantee timely delivery and post-launch support. We'll assess your project in 2 days — get in touch with us.

How Key Derivation Works in a Multi-Chain Wallet

All modern multi-chain wallets are built on BIP-32/BIP-39/BIP-44 standards. One seed phrase (12–24 words) → one master key → a tree of child keys for each network. The BIP-44 standard defines the derivation path: m / purpose' / coin_type' / account' / change / index. The path consists of 5 levels: purpose (fixed 44'), coin_type (e.g., 0 for Bitcoin, 60 for Ethereum, 501 for Solana), account, change (0 for external, 1 for change), index (addresses). This allows recovering all keys from a single seed phrase.

import { HDNodeWallet, Mnemonic } from 'ethers';
import { derivePath } from 'ed25519-hd-key';
import * as bip39 from 'bip39';

const mnemonic = Mnemonic.fromEntropy(crypto.getRandomValues(new Uint8Array(16)));
const seed = await bip39.mnemonicToSeed(mnemonic.phrase);

const evmWallet = HDNodeWallet.fromSeed(seed).derivePath("m/44'/60'/0'/0/0");
console.log('EVM address:', evmWallet.address);

const solanaPath = "m/44'/501'/0'/0'";
const { key: solanaPrivKey } = derivePath(solanaPath, seed.toString('hex'));

What is the Chain Abstraction Layer?

The architecture of a multi-chain wallet is built on adapters — objects that work uniformly with different networks. This is the key abstraction that hides differences in cryptography, transaction formats, and RPC.

interface ChainAdapter {
    chainId: string;
    chainName: string;
    getAddress(publicKey: Uint8Array): string;
    getBalance(address: string): Promise<bigint>;
    buildTransaction(params: TxParams): Promise<UnsignedTx>;
    signTransaction(tx: UnsignedTx, privateKey: Uint8Array): Promise<SignedTx>;
    broadcastTransaction(tx: SignedTx): Promise<string>;
    getTransactionStatus(txHash: string): Promise<TxStatus>;
    estimateFee(tx: UnsignedTx): Promise<FeeEstimate>;
}

class EVMAdapter implements ChainAdapter {
    private client: PublicClient;
    constructor(rpcUrl: string, public chainId: string, public chainName: string) {
        this.client = createPublicClient({ transport: http(rpcUrl) });
    }
    async getBalance(address: string): Promise<bigint> {
        return this.client.getBalance({ address: address as `0x${string}` });
    }
    async buildTransaction(params: TxParams): Promise<UnsignedTx> {
        const nonce = await this.client.getTransactionCount({ address: params.from as `0x${string}` });
        const feeData = await this.client.estimateFeesPerGas();
        return {
            to: params.to,
            value: params.value ?? 0n,
            data: params.data ?? '0x',
            nonce,
            maxFeePerGas: feeData.maxFeePerGas,
            maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
            chainId: BigInt(this.chainId),
        };
    }
}

How to Add a New Chain to a Multi-Chain Wallet

1. Implement ChainAdapter — describe the curve (secp256k1 or ed25519), transaction format, fee model.
2. Add the derivation path to BIP-44 — assign coin_type (for Bitcoin — 0, Ethereum — 60, Solana — 501).
3. Test signing and sending — verify on testnet, ensure the explorer shows the transaction.
4. Approve via pull request — code review and automated tests (Slither, fuzzing).

This process takes 1–2 weeks instead of 2–3 months with manual implementation. Our Chain Abstraction Layer reduces integration time by 3 times.

Secure Storage and Signing

On mobile platforms we use Secure Enclave (iOS) or StrongBox (Android). Limitation: they do not support secp256k1 directly, so the seed is stored encrypted in Keychain with biometrics. In Web Extensions, private keys live only in the background service worker — the content script has no access to them. Signing performance on mobile devices is higher than on browser extensions thanks to hardware acceleration.

func storeSeed(_ seed: Data) throws {
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: "wallet_seed",
        kSecValueData as String: seed,
        kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
        kSecAttrAccessControl as String: SecAccessControlCreateWithFlags(
            nil,
            kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
            [.biometryAny, .privateKeyUsage],
            nil
        )!
    ]
    let status = SecItemAdd(query as CFDictionary, nil)
    guard status == errSecSuccess else { throw KeychainError.unhandledError(status) }
}

Token Discovery and NFTs

Auto-discovery of tokens via Etherscan, Covalent, or Solana getParsedTokenAccountsByOwner. NFTs — Alchemy NFT API with IPFS metadata caching. Users don't need to add tokens manually.

WalletConnect v2

Standard protocol for communicating with dApps. Signing transactions via eth_sendTransaction and personal_sign. Session handling in the background.

Blockchain Comparison: EVM, Solana, Bitcoin

Stack and Timelines

Minimum production-ready multi-chain wallet (EVM + Solana, mobile-first) — 4–5 months. Typical project cost: starting from $50,000. Adding Bitcoin (UTXO model) — another 4–6 weeks and approximately $15,000. Expanding to Cosmos — 3–4 weeks via cosmjs, around $10,000. Final cost is calculated individually based on your requirements.

What's Included in the Work

• Architectural documentation and stack selection
• Implementation of HD wallet with BIP-44, BIP-39
• Integration of 2+ networks of your choice
• Token and NFT management interface
• WalletConnect v2 integration
• Smart contract audit (external or automated)
• Testing on real devices
• Source code delivery and deployment instructions
• Support for 30 days after release
• 12-month warranty on all core wallet components

Before public release, an external audit is mandatory — the wallet stores users' keys directly. Our team has 10+ years of experience in blockchain security and has delivered 50+ wallet projects. Order the development of a multi-chain wallet with audit and support. Contact us — we'll assess your project in 2 days. Get a consultation on architecture and timelines today.

We develop crypto wallets turnkey — from custodial solutions for fintech to smart contract accounts on EIP-4337. 5+ years in blockchain development, 40+ projects implemented. Let's examine which architecture to choose for your task and why MPC or Account Abstraction solve the private key problem that MetaMask and classic HD wallets could not close.

Why are classic wallets dangerous for business?

A seed phrase in a browser extension is the only way to restore access. For retail users, this is a barrier to entry (lost phrase = lost money). For corporate treasuries, it is incompatible with compliance (KYC/AML, role model, multisignature). Any single key leak compromises all funds. These risks are built into the architecture, not poor UX.

We eliminate them at the protocol level: MPC wallets (key never fully assembled), smart contract wallets (authorization logic in code), hardware HSM for institutional storage. Details below.

What is the real difference between custodial and non-custodial?

Custodial — the provider stores the private key. User authenticates via email/password/OAuth. Recovery is trivial, KYC/AML built-in. For centralized financial applications, often the only regulatory acceptable option. Risk: single point of failure (e.g., Bitfinex hack — $72M, FTX — $600M+ client funds).

Non-custodial — keys are with the user. Provider has no access to funds. Storage responsibility falls on the user. For 99% of people, this model is unworkable without additional protection — hence MPC.

MPC wallets: the key that doesn't exist

Multi-Party Computation (MPC) is a cryptographic protocol that allows multiple parties to jointly sign a transaction without revealing their partial secrets. The private key never exists in its assembled form.

Standard scheme: 2-of-3 MPC between user (share on device), provider server, and backup cloud storage. Transaction is signed by any two of three parties. Lost phone — recovery via server + cloud. Server compromised — attacker holds only one share, signing impossible.

TSS (Threshold Signature Scheme) is a concrete implementation of MPC for ECDSA/EdDSA. Algorithms: GG18, GG20, CGGMP21 (the latter is faster and has better security proofs). Libraries: tss-lib (Go, from Binance), multi-party-sig (Go, from Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC requires no on-chain changes — to the blockchain, the signature looks like a normal single-key signature. This saves gas and keeps the key management scheme confidential (not published in chain) — unlike multisig.

Account Abstraction (EIP-4337): smart contract as wallet

EIP-4337 completely changes the model: instead of EOA (Externally Owned Account), a smart contract Account is used. Authorization logic is in contract code, not in protocol cryptography. This opens up arbitrary signing logic, social recovery, session keys, sponsored transactions, and batch operations.

How the EIP-4337 stack works:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — a new type of object (not an L1 transaction). Bundler collects UserOps from an alternative mempool, packs them into one transaction, and sends to EntryPoint. EntryPoint calls validateUserOp on the Account contract — Account decides if the signature is valid.

Practical capabilities:

Social recovery. The contract stores a list of guardians (other addresses or a service). Lost key — guardians vote for replacement. Argent has used this scheme since 2020.

Session keys. A temporary key with limited rights: interaction only with a specific contract, until a certain date, up to a certain amount. For GameFi and dApps — user does not sign every micro-transaction.

Paymaster. A third-party contract pays gas for the user. Onboarding pattern: user does not hold ETH, gas is sponsored by dApp or taken from ERC-20 tokens.

Implementations: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). EntryPoint v0.6/v0.7 is deployed and active on Ethereum mainnet, Polygon, Arbitrum, Optimism. We guarantee compatibility with the latest contract versions.

What is a Hardware Security Module for corporate wallets?

For treasuries and institutional storage: HSM (Hardware Security Module). The key is generated and never leaves the secure chip. Signing happens inside the HSM. Hardware attestation is supported. Solutions used: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (for small volumes). Integration via PKCS#11 or cloud-specific API.

A combination of HSM + MPC is optimal for institutional use: key shares are stored in HSMs on different servers/jurisdictions, signing via TSS. This ensures compliance with regulatory requirements (e.g., for crypto custodians).

Integration with dApps: WalletConnect and standards

Any wallet must be able to interact with dApps. Standard: WalletConnect v2 (Sign API): QR code or deep link, peer-to-peer encrypted channel via relay server. For browser extensions: EIP-1193 (Ethereum Provider API).

On the frontend, we use wagmi + viem — one interface for MetaMask, WalletConnect, Coinbase Wallet, injected providers. For Account Abstraction: EIP-5792 (wallet capabilities) and EIP-7677 (paymaster service).

Development process

1. Threat model — who is the user (B2C, B2B, institutional), what operations, what is the acceptable risk model. Architecture depends on this.
2. Selection and design of key storage scheme — MPC, HSM, multisig, or a combination.
3. Development of Account contract (if EIP-4337) or integration of MPC library.
4. Backend — MPC coordination, session management, paymaster service (if needed).
5. Mobile/browser application — UI with WalletConnect integration, biometrics, QR.
6. Integration with dApps — EIP-1193, WalletConnect v2.
7. Audit of contracts and cryptographic implementations — mandatory step. MPC libraries have known vulnerabilities (GG18 susceptible to attack with malicious participant without abort protocol). We use libraries with up-to-date security reviews (CGGMP21). Experience passing audits with Certik, Hacken, Trail of Bits — we have certificates.

What is included in the work (deliverables)

• Source code of smart contracts (Solidity/Rust) with documentation
• Backend MPC coordination service (Go or Rust) with API
• Mobile application (iOS/Android) or browser extension
• Integration with WalletConnect, Ledger/Trezor (if required)
• Preparation for security audit (vulnerability report)
• Administrator and user documentation
• Access to repository, CI/CD, monitoring (Tenderly, Etherscan API)
• Training of your team (2-3 sessions)
• Post-launch support — 1 month

Timeline and cost

Cost is calculated individually for your project. We will estimate within one day — contact us by email or Telegram. We provide a guarantee on code and timeline.

Typical mistakes in crypto wallet development (and how to avoid them)

• Using outdated MPC libraries — GG18 without abort protocol. Choose CGGMP21 or tss-lib with up-to-date audit reports.
• Tight coupling to a single blockchain — not abstracting for L2/sidechains. Use viem/wagmi for cross-chain.
• Ignoring MEV attacks — when using multisig without timelocks. Add tx simulation (Tenderly) and sandwiching protection.
• Lack of fallback recovery mechanism — for Account Abstraction, not setting up social recovery. Include from the first release.

We eliminate these pitfalls at the design stage — for each project, we create a threat model and security checklist.

Need a reliable wallet with no compromises? Get a consultation from our architect — we will analyze your task and propose an architecture with a precise estimate. Leave a request — we will respond within a day.