A MetaMask-style wallet is a browser extension that keeps encrypted keys, injects an Ethereum provider into web pages, and asks the user to approve every connection, transaction and signature. Building one means getting four things right: extension architecture, the provider standards dApps expect, local key security and transaction review that people can actually understand.
Architecture of an extension wallet
Modern Chrome-family extensions use Manifest V3, which shapes the design:
- Background service worker. Holds the wallet controller: account state, network configuration, pending approval queue and the RPC client. Service workers can be suspended by the browser, so state must be persisted and restored rather than kept only in memory.
- Content script. Runs in each page's isolated world and relays messages between the page and the background.
- In-page provider. A script injected into the page's own context that exposes the provider object dApps call.
- Popup and full-screen UI. Onboarding, approvals, account management, and settings.
Messages between page, content script and background must be validated strictly. The page is untrusted; any request it sends could come from a malicious site.
The standards dApps expect
| Standard / method | Purpose |
|---|---|
| EIP-1193 | The provider interface: a request() method plus events such as accountsChanged and chainChanged |
| EIP-6963 | Multi-wallet discovery, so several installed wallets can announce themselves instead of fighting over window.ethereum |
eth_requestAccounts | Connection request; the user picks which accounts to expose to the site |
eth_sendTransaction | Build, review, sign and broadcast a transaction |
personal_sign, eth_signTypedData_v4 | Message and EIP-712 typed-data signatures, used for logins (Sign-In with Ethereum) and off-chain orders and permits |
wallet_addEthereumChain, wallet_switchEthereumChain | Network management requests from dApps (EIP-3085 and EIP-3326) |
wallet_watchAsset | Suggest adding a token to the user's list |
The full specifications live on the Ethereum EIPs site. Newer capabilities such as batched calls (EIP-5792) and EIP-7702 account delegation, introduced with Ethereum's Pectra upgrade, are increasingly expected by dApps.
Key storage: the vault
MetaMask-style wallets generate a BIP-39 mnemonic, derive accounts along the standard Ethereum path, and store everything in an encrypted vault in extension storage. The vault key comes from the user's password through a slow key-derivation function, and the decrypted keys should exist in memory only while unlocked, with an auto-lock timer. Hardware wallet support (Ledger, Trezor and others) keeps keys off the computer entirely and is worth building early for high-value users.
Common mistakes: weak KDF settings, logging sensitive data, keeping the decrypted seed in long-lived state, and showing the seed phrase in a way that screen-capture malware can read.
Making signing safe
Most wallet-related losses come from users approving something malicious, not from cryptography failing. A competitive wallet now needs:
- Transaction simulation that shows token balance changes before signing.
- Decoded approvals with warnings for unlimited allowances and
setApprovalForAllon NFT collections. - Readable EIP-712 signatures, especially permits and marketplace orders that can transfer assets without a transaction.
- Phishing and address checks: known-bad domain lists, look-alike address warnings, first-interaction notices.
- Per-site permissions that users can review and revoke.
Build process
- Decide fork or build. MetaMask's extension source is public but released under its own license with restrictions on commercial use; read it before forking. Other wallets are under more permissive licenses. Building on well-maintained libraries (for keys, RPC and EIP-712 encoding) is a middle path.
- Implement the controller and vault, with test vectors for derivation and encryption.
- Implement the provider and RPC methods and test against popular dApps and the EIP-6963 discovery flow.
- Add simulation and decoding, usually via a simulation API or your own forked-node service.
- Harden the release pipeline: signed builds, reproducible packaging, two-person review for store submissions. Compromised extension updates have been used to steal funds in the past.
- External security review before publishing to browser stores, then a bug bounty.
Cost and timeline
A reasoned estimate: an EVM-only extension with multiple accounts, custom networks, token and NFT display, hardware wallet support and transaction simulation needs about two or three front-end and extension engineers, one backend engineer for indexing and simulation services, a designer and QA for roughly four to seven months. A companion mobile app with WalletConnect adds a separate project. Non-EVM chains add substantial work per chain.
For the broader choice between custody models, see the cryptocurrency wallet development guide; for wallets aimed at DeFi power users, the DeFi wallet guide; and for mobile-first dApp wallets, the Web3 wallet development guide.
Frequently asked questions
Can I fork MetaMask and rebrand it?
Check the current license in its repository first. It has restricted commercial use, and the brand is trademarked. Forking also means tracking a fast-moving codebase and its security fixes.
Do I need Manifest V3?
Yes, for Chrome and other Chromium browsers; Manifest V2 extensions have been phased out. Firefox supports Manifest V3 with some differences.
How do multiple wallets coexist in one browser?
Through EIP-6963. Each wallet announces itself with an identifier and icon, and dApps show a chooser instead of relying on whichever wallet wrote window.ethereum last.
Should an extension wallet support smart accounts?
Increasingly, yes. EIP-7702 lets ordinary accounts delegate to contract code for batching and sponsored gas, but the wallet must guard carefully against malicious delegation requests.