Building a blockchain wallet is mostly a key-management and security project with a user interface on top. The decisions that determine cost, risk and regulatory exposure are made before any screen is designed: who holds the keys, how they are generated and recovered, which chains you support, and how transactions are signed.
Decision 1: who controls the keys
| Model | How it works | Best for | Main risk |
|---|---|---|---|
| Custodial | You hold keys server-side, usually in HSMs or an MPC system; users log in with a password | Exchanges, fintech apps, users new to crypto | You are a honeypot and, in many jurisdictions, a regulated custodian |
| Non-custodial seed phrase | Keys generated on device from a BIP-39 mnemonic, derived via BIP-32/BIP-44 | Crypto-native users, self-custody products | Users lose or leak their phrase; device malware |
| MPC (threshold signatures) | Key shares split between device, server and/or backup; no full key ever exists in one place | Consumer apps that want self-custody without seed phrases; institutions | Complex cryptography; vendor lock-in; recovery design |
| Smart account | A contract account (ERC-4337, or an EOA delegating code under EIP-7702) with programmable signers, limits and recovery | EVM apps wanting passkeys, gas sponsorship, session keys | Contract bugs; chain-specific; bundler and paymaster dependencies |
These combine. A common 2026 design is an MPC or passkey signer controlling a smart account, giving seedless onboarding plus on-chain recovery. If you hold user funds or can move them unilaterally, assume you are within reach of custody and money-transmission rules, and get legal advice early.
Decision 2: which chains and why
Each chain family brings its own cryptography, address format and transaction model. EVM chains share secp256k1 keys and one address across networks, so supporting ten EVM chains is mostly configuration. Bitcoin adds UTXO selection, multiple address types and PSBTs. Solana uses ed25519 and a different transaction format. Polkadot uses sr25519 and SS58 addresses (see Polkadot wallet development). Every additional chain family adds a signing library, node or RPC dependency, fee estimator, indexer and test suite. Start with the chains your users actually hold assets on.
Decision 3: form factor
Mobile apps get secure enclaves and biometrics; browser extensions are how most dApps expect to find wallets; embedded wallets live inside a single app and are invisible to users. Desktop and hardware integrations matter for high-value users. The form factor dictates how you connect to applications: an injected provider (EIP-1193, with EIP-6963 discovery so multiple extensions coexist), WalletConnect for mobile, or an SDK for embedded wallets. The Web3 wallet guide covers dApp connectivity in more depth.
Decision 4: how users understand what they sign
Most wallet-related losses come from users signing something malicious, not from broken cryptography. A good wallet decodes transactions into plain language, renders EIP-712 typed data clearly, warns about unlimited token approvals and setApprovalForAll, simulates transactions to show balance changes, and flags known drainer addresses. This layer often takes more engineering than sending tokens.
Security essentials
- Generate keys with a vetted cryptographic library and the platform's secure random source; never roll your own.
- Store secrets in the Secure Enclave, Android Keystore or StrongBox, or encrypted with a key derived from user authentication.
- Keep keys out of logs, crash reports, analytics and clipboard history.
- Pin dependencies and review updates; supply-chain attacks on wallet libraries have happened.
- Commission an independent security assessment of the app and, for smart accounts, an audit of the contracts (see smart contract audits).
Build sequence
- Choose custody model, chains and form factor; document the threat model.
- Implement key generation, storage, backup and recovery, and test recovery on real devices.
- Add chain clients, balance and history indexing, and fee estimation.
- Build send, receive, swap or staking flows plus transaction decoding and simulation.
- Integrate dApp connectivity, then run a security assessment and a staged rollout.
Effort and cost drivers
As a rough guide, a non-custodial EVM-only mobile wallet with send, receive and WalletConnect is achievable by three to four engineers in three to four months. Each extra chain family, MPC, smart accounts with paymasters, fiat on-ramps, swaps and hardware-wallet support adds weeks to months. Ongoing costs are significant: RPC and indexing infrastructure, monitoring, chain upgrades and app-store maintenance never stop. White-label wallet SDKs and embedded-wallet providers cut the initial build sharply in exchange for per-user fees and dependency on the vendor.
For a consumer cryptocurrency wallet specifically, the cryptocurrency wallet guide goes deeper on features and app-store realities.
Frequently asked questions
Is a non-custodial wallet free of regulation?
Often lighter, but not automatically exempt. Features such as built-in swaps, fiat ramps or the ability to freeze funds can change the analysis.
MPC or smart accounts?
MPC works on any chain because it produces ordinary signatures. Smart accounts offer richer on-chain logic but only on chains that support them. Many products use both.
Can I build on an open-source wallet?
Yes, and many teams do. Check the license, the code quality and whether you can keep up with upstream security fixes.