A crypto wallet does not store coins; it stores or controls the keys that authorize transactions on a blockchain. Building one is mostly a key-management and security problem, and the first decision, who holds the keys, shapes everything else.
Three custody models
| Model | Who controls keys | Strengths | Trade-offs |
|---|---|---|---|
| Custodial | The operator, on servers or with a custody provider | Password resets, simple UX, easy fiat integration | Regulated as custody in most places; a breach exposes every user |
| Self-custody (seed phrase) | The user, via a BIP-39 mnemonic | No operator risk; works with every dApp | Lost phrase means lost funds; phishing of phrases is endemic |
| MPC or smart account | Split between user device, operator and/or guardians, or governed by contract logic | Recovery without a single secret, spending policies, gas sponsorship | More moving parts, vendor dependence, per-chain support gaps |
Custodial wallets resemble a bank account; self-custody resembles cash. MPC (multi-party computation) splits a signing key into shares so no single device or server ever holds it whole. Smart accounts on EVM chains, standardized around ERC-4337 and extended by EIP-7702 (which arrived with Ethereum's Pectra upgrade in 2025), move the logic into a contract: social recovery, session keys, batched transactions and paying fees in tokens.
What a self-custody wallet has to do
Key generation and storage
Entropy comes from the operating system's secure random generator. The mnemonic (BIP-39) derives a master seed, from which accounts are derived along standard paths (BIP-32/44, with chain-specific paths for Solana, Cosmos and others). On mobile, the seed should be encrypted with a key held in the Secure Enclave or Android Keystore and unlocked by biometrics. On desktop and browser extensions, encryption with a user password and a strong key-derivation function is the baseline.
Transaction building and signing
The wallet fetches nonces and fee estimates, builds the transaction, shows the user what it does, and signs locally. "What it does" is the hard part: decoding contract calls, simulating the result, and warning about unlimited token approvals or EIP-712 permit signatures that drain funds. Many users have lost assets by signing messages they could not read.
Chain data
Balances, token lists, NFT metadata, history and prices come from RPC nodes and indexers. Most teams use provider APIs rather than running nodes for every chain, which is cheaper but creates a privacy and availability dependency.
dApp connectivity
Browser extensions inject an EIP-1193 provider and announce themselves via EIP-6963; mobile wallets connect through WalletConnect. If dApp access is central to your product, see the MetaMask-style wallet guide for extension architecture.
Build process
- Pick the custody model and confirm its regulatory consequences where you operate.
- Pick chains deliberately. Each non-EVM chain (Bitcoin, Solana, Cosmos, TON) needs its own derivation, signing, fee and data logic.
- Use audited cryptography libraries. Never implement elliptic-curve math yourself.
- Design transaction review: decoding, simulation, approval warnings, address-poisoning detection.
- Build backup and recovery flows and test them with real non-technical users.
- Commission a security review of key storage, signing, update channels and any smart account contracts, plus a smart contract audit where contracts are involved.
Security failure modes to design against
- Weak randomness. Wallets that generated keys from poor entropy have been drained years later.
- Supply-chain attacks. A compromised dependency or update channel can exfiltrate seeds. Pin dependencies, sign builds, and limit who can publish releases.
- Blind signing. Showing raw hex for a contract call invites theft. Simulate and explain.
- Clipboard and address poisoning. Attackers send dust from look-alike addresses so users copy the wrong one from history.
- Server-side custody breaches. For custodial and MPC designs, the operator's infrastructure is a target; isolate signing services.
Cost and timeline
A reasoned estimate: a mobile self-custody wallet supporting EVM chains, with token and NFT display, swaps through an aggregator API and WalletConnect, needs roughly two mobile engineers, one backend engineer, a designer and part-time QA for four to six months. Each additional non-EVM chain adds weeks. MPC via a vendor SDK speeds key management but adds per-user fees. Security review budgets should be planned from the start, not tacked on.
For wallets centered on a specific ecosystem, related guides cover Web3 wallets for dApp users and general blockchain wallet architecture.
Frequently asked questions
Is it safer to build custodial or non-custodial?
Neither is universally safer. Custodial concentrates risk and regulation on you; self-custody shifts risk to users who may lose phrases. MPC and smart accounts try to balance the two.
Can I fork an open-source wallet?
Yes, if the license allows. Check it carefully: some popular wallets use licenses that restrict commercial forks. You also inherit responsibility for keeping up with security fixes.
Do I need my own blockchain nodes?
Not at first. Hosted RPC and indexing providers are standard. Run your own nodes later for reliability, privacy or chains with poor provider coverage.
What does account abstraction change for wallets?
It lets an account be a contract with its own rules, enabling recovery without seed phrases, spending limits, batched actions and sponsored gas. It also means contract bugs can lock or lose funds, so audits matter.