How to Build a Non-Custodial Wallet Infrastructure

A non-custodial wallet is a user-controlled digital asset interface where the private keys—and therefore full ownership—are held by the user, not a third party. This is the core principle of self-sovereignty in Web3. In contrast to custodial solutions like centralized exchanges, non-custodial wallets shift the responsibility of security and key management to the end-user. The infrastructure to support such wallets involves multiple interacting components, including key generation, secure storage, transaction signing, and blockchain communication via RPC nodes.

Building this infrastructure requires a clear separation of concerns. The client-side component, often a web or mobile application, handles the user interface, key derivation (e.g., from a seed phrase), and transaction construction. The server-side or backend-for-frontend (BFF) component typically manages non-sensitive operations like fetching blockchain data, gas estimation, and relaying signed transactions to the network. Crucially, private keys and seed phrases must never leave the user's trusted environment, adhering to the principle of client-side signing.

Key management is the most critical challenge. Developers must implement robust methods for key generation (using libraries like ethers.js or web3.js), secure storage (using the Web Crypto API or platform-specific secure enclaves), and recovery (via standardized mnemonics BIP-39). For example, generating a new wallet with ethers is straightforward: const wallet = ethers.Wallet.createRandom();. However, securely persisting the wallet.mnemonic.phrase across user sessions is a complex security problem with significant implications.

The wallet must also interact with various blockchains. This requires integrating with RPC providers (like Chainstack, Alchemy, or public endpoints) to query state, broadcast transactions, and listen for events. Multi-chain support adds complexity, necessitating management of different chain IDs, native currencies, and transaction formats. A well-architected wallet abstracts these RPC calls behind a consistent interface, handling network switching and potential provider failures gracefully.

Finally, the user experience must balance security with usability. Features like transaction simulation, readable contract interaction previews, and fee customization are essential. Developers must also plan for account abstraction via ERC-4337, which allows for social recovery, sponsored transactions, and batch operations, representing the next evolution of non-custodial wallet infrastructure. This guide will walk through implementing these components step-by-step.

A non-custodial wallet's core function is to let users control their cryptographic keys, which are the sole proof of ownership for blockchain assets. This is fundamentally different from centralized exchanges or custodial services. The infrastructure you build must never have access to the user's private key. Instead, it provides tools for key generation, secure storage, transaction signing, and blockchain communication. Key concepts include public-key cryptography (PKI), hierarchical deterministic (HD) wallets defined by BIP-32/44, and mnemonic phrases (BIP-39).

You must understand how wallets interact with different blockchains. For Ethereum and EVM-compatible chains, this involves using the JSON-RPC API to query chain state (e.g., eth_getBalance) and broadcast signed transactions. For UTXO-based chains like Bitcoin, you need to handle unspent transaction outputs (UTXOs). A critical component is the Provider or Signer abstraction, as used in libraries like ethers.js and web3.js, which separates the logic for reading chain data from the logic for authorizing transactions.

Security is paramount. The infrastructure must be designed around the principle of never exposing plaintext private keys or mnemonics in memory longer than necessary. This involves using secure enclaves (where available), implementing proper key derivation paths, and understanding common attack vectors like phishing, side-channel attacks, and faulty random number generation. Familiarity with standards like BIP-32 (HD Wallets), BIP-39 (Mnemonics), and BIP-44 (Multi-Account Hierarchy) is non-negotiable for interoperability.

From a development perspective, core prerequisites include proficiency in a backend language (Node.js, Go, Rust), understanding asynchronous programming for handling blockchain RPC calls, and knowledge of secure software development practices. You will also need to integrate with specific network providers or nodes, such as running a Geth/Erigon client for Ethereum or using services like Infura, Alchemy, or QuickNode for managed node access.

Finally, consider the user experience (UX) implications of non-custodial design. Your infrastructure must handle complex states like network congestion, transaction replacement (e.g., EIP-1559), and fee estimation. It should also provide clear interfaces for backup and recovery processes, as the user bears ultimate responsibility for their seed phrase. The upcoming sections will build on these concepts to implement a functional wallet system.

A non-custodial wallet infrastructure is a system that allows users to manage their own cryptographic keys and assets without a trusted intermediary. The core architectural principle is key sovereignty: the user's private keys are generated, encrypted, and stored on their device, never transmitted to a central server. This architecture typically comprises a client-side SDK (like Web3.js, ethers.js, or WalletConnect) for blockchain interaction, a secure key management module, and a backend service layer for non-sensitive operations such as gas estimation, transaction relaying, and fetching blockchain state. The backend never handles private keys.

The client-side architecture is critical. It involves a secure enclave for key generation using libraries like @safe-global/safe-core-sdk or ethers.Wallet.createRandom(). Keys must be encrypted at rest using a user-derived secret, often a password or biometric key. For enhanced security and recovery, consider implementing social recovery via smart contract wallets (like Safe{Wallet}) or multi-party computation (MPC) solutions (such as those from ZenGo or Fireblocks). These distribute key shards, removing single points of failure. The frontend must also integrate with wallet connection protocols to enable interactions with decentralized applications (dApps).

The backend service layer supports the wallet without compromising custody. Essential services include a node provider gateway (using services like Alchemy, Infura, or QuickNode for reliable RPC access), a transaction relayer to sponsor gas fees for users (via meta-transactions or paymasters), and an indexing service to efficiently query token balances and transaction history. This layer can also manage non-critical user preferences and notification systems. All communication between client and server must be authenticated, typically using session tokens derived from a cryptographic signature of a challenge message, proving key ownership without exposing it.

Security considerations dictate the entire design. The client must guard against phishing (using domain verification like EIP-4361), malicious dApps (with transaction simulation tools like Tenderly), and device compromise (via hardware security modules or passkeys). The backend must implement rate limiting, monitor for anomalous activity, and ensure all dependencies (RPC providers, relayer services) are highly available and secure. Regular third-party audits of both smart contract and application code are mandatory. This layered, defense-in-depth approach is what separates a production-grade wallet infrastructure from a simple proof-of-concept.

Finally, the infrastructure must be designed for scalability and multi-chain support from the outset. Use abstracted provider interfaces to easily add support for new EVM chains, Solana, or Cosmos SDK chains. Implement a modular architecture where chain-specific logic (like gas estimation or transaction building) is pluggable. For user experience, consider aggregating balances across chains and using cross-chain messaging protocols (like LayerZero or Axelar) for native asset transfers. The goal is to provide a seamless, secure, and chain-agnostic interface that empowers users with true ownership of their digital assets.

Non-custodial wallets shift the responsibility of private key management from a central service to the end-user. Your infrastructure must generate and store these keys securely, as their compromise results in irreversible fund loss. The core components are a key generation engine, a secure storage module (like a Hardware Security Module or HSM), and a transaction signing service. Unlike custodial solutions, your system never has direct access to the plaintext private key, only facilitating its secure use.

Key generation is the first critical step. For Ethereum and EVM chains, you typically use the ethers.js library. Never use Math.random(). Instead, use cryptographically secure random number generators. For example, generating a wallet with ethers.Wallet.createRandom() uses crypto.getRandomValues under the hood. For hierarchical deterministic (HD) wallets following BIP-32/39/44 standards, libraries like @scure/bip39 and @scure/btc-signer provide secure, audited implementations for generating mnemonics and derived keys.

Secure storage is non-negotiable. For server-side signing, Hardware Security Modules (HSMs) like those from AWS CloudHSM or Google Cloud KMS provide FIPS 140-2 Level 3 validated hardware isolation. The private key is generated within and never leaves the HSM's secure boundary; your application requests signatures via an API. For client-side applications, the Web Crypto API offers secure key generation and storage within the browser's isolated context, though seed phrase backup remains the user's responsibility.

Transaction signing must be decoupled from key storage. Implement a signing service that receives transaction payloads, requests a signature from the secure storage module (e.g., HSM or encrypted keystore), and broadcasts the signed transaction. This service should run in a tightly controlled network segment. Audit logs for all signing requests are essential. For user-facing apps, leverage WalletConnect or similar protocols to delegate signing to established mobile wallets like MetaMask, which is often more secure than embedding key management in a web app.

Always implement multi-factor authentication (MFA) and rate limiting on all administrative and signing endpoints to prevent brute-force attacks. Use transaction simulation services like Tenderly or OpenZeppelin Defender before signing to detect malicious payloads. Your architecture should assume breaches: use air-gapped systems for high-value keys, multi-signature schemes requiring M-of-N signatures for treasury wallets, and regular key rotation policies for operational keys.

Finally, security is iterative. Conduct regular third-party audits of your cryptographic code and infrastructure. Use monitoring and alerting for anomalous signing activity. The goal is to create a system where a compromise of your application server does not lead to a compromise of user funds, adhering to the core principle of non-custodial ownership.

A transaction relayer is a backend service that pays gas fees on behalf of users, enabling gasless transactions and a seamless onboarding experience. This is a core component of modern non-custodial wallet infrastructure, often implemented using ERC-4337 (Account Abstraction) standards. Instead of users needing native ETH for gas, they sign a user operation which is bundled and submitted by the relayer. The relayer's role is to validate, sponsor, and broadcast these operations to the blockchain, abstracting away gas complexity.

To build a relayer, you first need to set up a Paymaster contract. This smart contract holds the funds used to pay for sponsored transactions and defines the sponsorship rules. A basic paymaster uses a deposit method to fund its account on an EntryPoint contract. You must also implement validation logic in the validatePaymasterUserOp function to decide which user operations to sponsor, such as whitelisted addresses or specific dApp interactions. Security here is critical to prevent draining of the relayer's funds.

The backend service listens for incoming user operations. A typical stack uses Node.js with the userop.js library or Python with account-abstraction packages. The service must: - Receive and validate the user operation signature. - Simulate the transaction using eth_call to ensure it won't revert. - If valid, wrap the operation into a bundle and send it to a bundler service or directly to a supported EntryPoint contract. The relayer then pays the gas fee from its paymaster deposit. Open-source bundlers like Stackup's or Pimlico's can be integrated to handle this process.

Managing security and scalability is paramount. Implement rate limiting and fraud detection to prevent abuse. Use a multi-signature wallet or governance module to manage the paymaster's treasury. For production, consider using relay services from providers like OpenZeppelin Defender or Gelato to handle transaction delivery and monitoring, reducing your operational burden. Always estimate gas accurately and maintain a sufficient balance in your paymaster contract across all supported chains (Ethereum, Polygon, Arbitrum).

Finally, integrate the relayer with your frontend application. Using SDKs like AA-SDK or Thirdweb, you can enable users to send gasless transactions with a few lines of code. The flow is: user signs a meta-transaction, your dApp sends it to your relayer API endpoint, the relayer processes it, and returns a transaction hash. This infrastructure eliminates a major UX hurdle, allowing users to interact with your dApp without ever needing to purchase or manage gas tokens.

A gas abstraction system decouples the payment of transaction fees from the end-user initiating the transaction. In traditional Web3 wallets, users must hold the native token (like ETH on Ethereum) to pay for gas, creating a significant onboarding barrier. By designing a system where a third party—a relayer or paymaster—can sponsor these fees, you enable users to interact with dApps using only the tokens required for the transaction itself. This is a foundational component for mainstream adoption, allowing for credit card payments, subscription models, and enterprise-grade user experiences.

The core architecture relies on two primary standards: ERC-4337 (Account Abstraction) and ERC-2771 (Meta-Transactions). ERC-4337 introduces a higher-layer mempool for UserOperation objects and smart contract accounts (Smart Accounts), enabling native social recovery and batched transactions. ERC-2771 allows a trusted forwarder to relay a user's signed transaction, appending the relayer's address. For a non-custodial system, you must implement a secure Paymaster contract that validates user requests and reimburses the relayer, often using a deposit in the native token. The user's signature is always verified, ensuring they never relinquish custody of their assets.

Implementing a basic paymaster involves a smart contract with a validatePaymasterUserOp function. This function checks if the sponsoring entity agrees to pay for the transaction. A simple version might whitelist specific dApp addresses or token swaps. For example, a paymaster could be configured to sponsor all gas fees for swaps involving a specific stablecoin on Uniswap v3. The contract holds a balance of ETH, which is deducted to pay the bundler (the network participant that includes the UserOperation in a block). Security here is paramount; the validation logic must be robust against exploitation to prevent draining the paymaster's fund.

On the client side, your wallet infrastructure must generate EIP-712 compliant signatures for UserOperation objects. Libraries like UserOp.js (from the ERC-4337 team) or SDKs from Stackup, Biconomy, or Candide can abstract this complexity. The flow is: 1) The dApp requests a transaction, 2) Your wallet SDK constructs a UserOperation, 3) A relayer network (like Pimlico or Stackup's network) picks it up, 4) The paymaster validates and sponsors it, 5) A bundler executes it on-chain. You must manage gas estimation accurately, as the paymaster stakes its funds on covering the actual execution cost.

Key design considerations include gas policy management and economic sustainability. You need a policy engine to decide which transactions to sponsor—based on user reputation, dApp partnership, or transaction type. Sustainability often involves a hybrid model: sponsoring initial user onboarding while eventually charging dApps a small fee per sponsored transaction or using gasless transactions only for specific actions. Furthermore, you must plan for multi-chain support; a paymaster contract and relayer network are needed on each EVM-compatible chain you target, such as Polygon, Arbitrum, and Base.

For production, integrate with services that handle relay network reliability, fee estimation, and paymaster management. Providers like OpenGSN (for ERC-2771), Pimlico (for ERC-4337), and Biconomy offer modular APIs. Always audit your paymaster contract and client-side signing logic. The end goal is a seamless wallet experience where users sign transactions without thinking about gas, while your infrastructure handles fee payment securely and efficiently in the background, unlocking new use cases for decentralized applications.

A non-custodial wallet infrastructure is a backend system that allows users to retain full control of their private keys while your application provides a seamless interface for blockchain interactions. Unlike custodial solutions where you manage keys on behalf of users, this architecture delegates signing authority to the client side, fundamentally reducing your liability and aligning with Web3 principles. Core components include a secure key management service for generating and storing encrypted key shares, a multi-chain node relay to broadcast transactions, and a state synchronization engine to track balances and events across networks like Ethereum, Polygon, and Solana.

The foundation is a Hierarchical Deterministic (HD) wallet system, typically using BIP-32, BIP-39, and BIP-44 standards. When a user creates an account, your backend generates a cryptographically secure mnemonic seed phrase client-side. This seed is never transmitted in plaintext; instead, it is encrypted by the user's password into a keystore file (e.g., using WebCrypto API) before being stored. For enhanced security, consider implementing multi-party computation (MPC) or threshold signature schemes (TSS), where the private key is split into shares held separately by the user and your service, requiring collaboration to sign.

Node orchestration is critical for reliability and performance. You must manage connections to full nodes or node-as-a-service providers (like Alchemy, Infura, or QuickNode) across multiple chains. Implement a load balancer and fallback mechanism to switch providers during outages. For transaction submission, use a nonce management system to track pending transactions and prevent conflicts. Here's a simplified example of a node relay service in Node.js using the Ethers library:

javascriptCopy
import { ethers } from 'ethers';
class NodeRelay {
  constructor(rpcUrls) {
    this.providers = rpcUrls.map(url => new ethers.JsonRpcProvider(url));
    this.activeProvider = this.providers[0];
  }
  async sendTransaction(signedTx) {
    for (const provider of this.providers) {
      try {
        return await provider.broadcastTransaction(signedTx);
      } catch (error) {
        console.log(`Failed with ${provider.connection.url}, trying next.`);
      }
    }
    throw new Error('All node providers failed.');
  }
}

Your infrastructure must also maintain a real-time view of user portfolio states. This involves indexing blockchain data for addresses associated with your platform. You can subscribe to events via WebSocket connections to nodes or use specialized indexing services like The Graph or Subsquid. For example, to track ERC-20 token balances, your service listens for Transfer events to and from user addresses and updates a local database. This decoupled state layer allows your frontend to query balances and transaction history instantly without relying on slow, direct RPC calls for historical data.

Security and operational audits are non-negotiable. Conduct regular smart contract audits for any in-house contracts (e.g., for gas sponsorship or batch transactions) and penetration testing on your key management API. Implement rigorous rate limiting, monitor for anomalous withdrawal patterns, and maintain clear transaction logging for non-repudiation. The infrastructure's success is measured by its uptime, transaction success rate, and most importantly, its unwavering commitment to the non-custodial model where users maintain sovereign control over their assets.