A Web3 wallet manages keys, connects to dApps, and shows users exactly what they are signing. In 2026 the interesting work is in account abstraction, passkey and MPC key management, and transaction previews that stop users from signing away their assets.
This page focuses on wallets as the gateway to dApps. For a general crypto wallet (holding and sending coins across chains) see the guide to cryptocurrency wallet development, and for a browser-extension product modeled on MetaMask, the MetaMask-like wallet guide.
Account models: the first decision
| Model | How it works | Strengths | Weaknesses |
|---|---|---|---|
| Externally owned account (EOA) with seed phrase | One private key controls the account, backed up as a 12/24-word phrase | Universal compatibility, simple | Lose the phrase, lose everything; no built-in recovery |
| MPC wallet | The key is split into shares held by device, server and/or backup; signing needs a threshold | No single point of key theft; recoverable | Depends on provider infrastructure; harder to audit |
| Smart account (ERC-4337) | The account is a contract with programmable validation: passkeys, multisig, spending limits, recovery | Batching, sponsored gas, social recovery, session keys | Higher deployment and gas overhead; needs bundler infrastructure |
| EOA upgraded via EIP-7702 | An existing EOA delegates to smart-account code (live on Ethereum since the 2025 Pectra upgrade) | Smart features without changing address | Delegation to malicious code is a new phishing vector |
The specifications are worth reading directly: ERC-4337 and EIP-7702. Consumer apps increasingly combine them: passkey sign-in, a smart account underneath, and a paymaster that sponsors the first transactions so users do not need to buy gas tokens before trying the product.
Connecting to dApps
- EIP-1193 defines the JavaScript provider interface dApps call to request accounts and signatures.
- EIP-6963 lets multiple browser wallets announce themselves without overwriting each other.
- WalletConnect pairs mobile wallets with desktop dApps over an encrypted relay.
- EIP-712 typed data lets wallets display structured messages (orders, permits) in readable form; EIP-4361 (Sign-In with Ethereum) standardizes login messages.
- EIP-5792 wallet call batching lets dApps request several calls at once, which smart accounts can execute atomically.
Wallets that support these well are easy for dApp developers to integrate; the Web3 dApp development guide covers the other side of that connection.
Security features that matter most
- Transaction simulation: run the transaction against current state before signing and show the asset changes in plain language ("you send 500 USDC, you receive nothing").
- Approval warnings: flag unlimited token allowances, NFT "set approval for all" requests, Permit signatures and EIP-7702 delegations to unknown contracts. Most wallet drains come from signatures users did not understand, not from broken cryptography.
- Allowance management: a screen to review and revoke approvals.
- Phishing and address-poisoning defenses: domain blocklists, warnings on first-time recipients, and showing full addresses rather than truncated ones that lookalikes exploit.
- Secure key storage: device secure enclaves or keystores on mobile, encrypted storage in extensions, and no keys in logs or analytics.
- Independent audits of smart-account contracts and key-management code before launch.
Custodial or non-custodial
If your company can move user funds unilaterally, you are running a custodial service, which can trigger licensing, such as crypto-asset service provider authorization under the EU's MiCA or money-transmission rules in US states. Non-custodial wallets avoid much of that but put recovery on the user, which is why smart-account recovery and MPC designs exist. Decide this early, because it shapes the architecture and the legal work.
Build process and cost drivers
- Pick the account model and supported chains. Each extra chain family (EVM, Solana, Bitcoin) adds signing, fee and indexing work.
- Design the key lifecycle: creation, backup, recovery, device change, and compromise response.
- Build the signing core and dApp connectivity, then simulation and warnings.
- Integrate infrastructure: RPC, indexers for balances and history, bundlers and paymasters for smart accounts, price feeds.
- Audit and run a bug bounty before broad release.
As a reasoned estimate, an EVM-only mobile wallet with smart accounts, simulation and dApp connectivity is commonly two to four engineers for four to six months before audit. Ongoing costs include RPC and indexing, sponsored gas, and support for users who lose access. A wallet built for a single dApp with an embedded SDK is far smaller; for DeFi-specific features like swaps and staking inside the wallet, see the DeFi wallet guide.
Frequently asked questions
What is the difference between a Web3 wallet and a crypto wallet?
The terms overlap. "Web3 wallet" usually stresses dApp connectivity and signing for smart contracts, while "crypto wallet" can mean any tool for storing and sending coins, including simple Bitcoin wallets.
Are seed phrases going away?
Not entirely, but they are no longer the only option. Passkeys, MPC and smart-account recovery let many users start without one, and EIP-7702 lets existing accounts gain smart features.
Can a wallet pay gas on behalf of users?
Yes. With ERC-4337 paymasters or relayers, the app sponsors fees. You need abuse limits, because free transactions attract bots.
Do I need an audit for a wallet?
Yes for any smart-account contracts and strongly advisable for key-management and signing code. Wallet bugs typically mean irreversible loss of user funds.