MetaMask alternatives such as Rabby, Rainbow and Phantom are the wallets a new browser wallet competes against. Some of them also publish code that a team may legally reuse. This guide compares those wallets, then explains how a MetaMask-like extension works: its parts, the standards dApps call, key storage, signing safety, build steps and cost.
MetaMask alternatives compared
A team that plans its own wallet usually studies the existing extensions first. The license of each one decides whether the team can fork its code, and the chains it supports decide which users it can serve.
| Wallet | Source code license | Chains | Notes for a builder |
|---|---|---|---|
| MetaMask | ConsenSys license, free only for non-commercial use | EVM networks, Solana and Bitcoin | A fork with more than 10,000 monthly active users needs a commercial agreement |
| Rabby | MIT, with the Rabby name and logo reserved | EVM networks | Simulates each transaction and shows balance changes before signing |
| Rainbow (extension) | GPL-3.0 | Ethereum and EVM layer 2 networks | A fork must publish its own source code under GPL-3.0 |
| Frame | GPL-3.0 | EVM networks | A desktop app that connects to the browser, with little repository activity since March 2025 |
| Phantom | Closed source | Solana, Ethereum, Bitcoin and some EVM networks | Cannot be forked |
| Base app (formerly Coinbase Wallet) | Closed wallet app; the developer SDK is MIT | Base, Ethereum and other EVM networks | Coinbase renamed the wallet in July 2025 |
The licenses come from each project's GitHub repository. MetaMask added native Solana accounts in May 2025 and later added Bitcoin, so a new wallet that supports only EVM networks covers less ground than MetaMask does.
Can you fork MetaMask as a MetaMask clone?
MetaMask's extension code is public on GitHub, but it is not open source in the usual sense. The MetaMask license allows non-commercial use only, which it defines as personal hobby or research use, use by charities, schools or public bodies, or a product with no more than 10,000 monthly active users. Any fork must also credit ConsenSys and carry the same restrictions. MetaMask is a registered trademark, so a MetaMask clone needs its own name and logo.
A team that wants a permissive base can start from Rabby's MIT code, but it must remove the Rabby brand. A GPL-3.0 base such as Rainbow requires the team to publish its changes. Many teams build their own wallet on standard libraries for key derivation, RPC calls and EIP-712 encoding instead.
How an extension wallet is built
Chrome and other Chromium browsers accept only Manifest V3 extensions, because Google has removed Manifest V2 from the Chrome Web Store. Firefox also supports Manifest V3, with some differences. A Manifest V3 wallet has four parts:
- Background service worker. It holds the wallet controller: accounts, network settings, the queue of pending approvals and the RPC client. The browser can suspend a service worker at any time, so the controller saves its state and restores it on wake.
- Content script. It runs next to each web page in a separate JavaScript context, which the browser calls an isolated world, and passes messages between the page and the background worker.
- In-page provider. The wallet injects a script into the page's own context that exposes the provider object that dApps call.
- Popup and full-screen screens. They handle onboarding, approvals, account management and settings.
The wallet must validate every message that passes between the page, the content script and the background worker. Any website can send a request, and a malicious site can send a crafted one.
The standards dApps expect
| Standard or method | What it does |
|---|---|
| EIP-1193 | Defines the provider interface: a request() method and events such as accountsChanged and chainChanged |
| EIP-6963 | Lets each installed wallet announce itself to the dApp, which then shows a list of wallets for the user to pick from |
eth_requestAccounts | Asks the user to connect; the user picks the accounts the site may see |
eth_sendTransaction | Builds a transaction, shows it for review, signs it and broadcasts it |
personal_sign, eth_signTypedData_v4 | Signs plain messages and EIP-712 typed data, used for Sign-In with Ethereum, off-chain orders and token permits |
wallet_addEthereumChain, wallet_switchEthereumChain | Lets a dApp ask the wallet to add or switch a network (EIP-3085 and EIP-3326) |
wallet_watchAsset | Suggests a token for the user's token list |
EIP-5792 (wallet_sendCalls, wallet_getCapabilities) | Sends a batch of calls in one request and reports which features the wallet supports |
The full specifications are on the Ethereum EIPs site. EIP-5792 has reached Final status, so its methods will not change. EIP-7702 went live with Ethereum's Pectra upgrade in May 2025 and lets an ordinary account run code from a smart contract, so one signature can send several calls and another party can pay the gas.
Key storage: the vault
A MetaMask-like wallet generates a BIP-39 recovery phrase and derives accounts along the standard Ethereum derivation path, the BIP-44 rule that turns one phrase into many addresses. The wallet stores the phrase and keys in an encrypted vault in extension storage, where a slow key-derivation function turns the user's password into the vault key. The decrypted keys stay in memory only while the wallet is unlocked, and an auto-lock timer clears them.
Hardware wallet support for Ledger, Trezor and similar devices keeps keys off the computer, and teams often add it early for users with large balances.
Common vault mistakes:
- weak settings for the key-derivation function
- logs that contain keys, phrases or passwords
- a decrypted recovery phrase kept in long-lived state
- a recovery phrase screen that screen-capture malware can read
Making signing safe
Most wallet losses happen when users approve a malicious request, not when the cryptography fails. Current MetaMask alternatives compete on these protections:
- Transaction simulation. The wallet shows the token balance changes before the user signs.
- Decoded approvals. The wallet warns about unlimited token allowances and about
setApprovalForAll, a call that lets another address move every NFT the user holds in a collection. - Readable EIP-712 signatures. A signed permit or marketplace order can move assets without a separate transaction, so the wallet shows the amount, the token and the receiver of each permit or order in plain words.
- Phishing and address checks. The wallet checks lists of known bad domains, flags look-alike addresses and marks a first interaction with a contract.
- EIP-7702 delegation checks. A malicious delegation request can hand control of an account to an attacker's contract, so the wallet shows the target contract and blocks unknown ones by default.
- Per-site permissions. Users can see which sites are connected and revoke each one.
Build steps
- Choose to fork or build. Read the license of any wallet you plan to fork, using the table above, or build on maintained libraries for keys, RPC and EIP-712 encoding to avoid most license limits.
- Build the controller and the vault. Test key derivation and encryption against published test vectors.
- Build the provider and the RPC methods. Test the wallet against popular dApps and against the EIP-6963 discovery flow.
- Add simulation and decoding. Teams usually call a simulation API, though some run their own node, copy the current chain state and test each transaction on that copy.
- Secure the release pipeline. Use signed builds, reproducible packaging and a second reviewer for each store submission, because attackers have stolen funds through compromised wallet extension updates.
- Order an external security review before the first store release, then open a bug bounty.
Cost and timeline
This estimate is a reasoned guess, not a quote. It covers an EVM-only extension with several accounts, custom networks, token and NFT display, hardware wallet support and transaction simulation, which needs the following team for about four to seven months:
- two or three front-end and extension engineers
- one backend engineer for indexing and simulation services
- one designer
- one QA engineer
A companion mobile app that connects to dApps through WalletConnect is a separate project, and the WalletConnect developer kits now come from Reown, the company formerly called WalletConnect Inc. Each non-EVM chain, such as Solana or Bitcoin, adds its own key types, transaction formats and RPC work.
The crypto wallet development guide compares custody models, and the DeFi wallet guide covers wallets for active DeFi users. The Web3 wallet development guide covers mobile-first dApp wallets, and the blockchain wallet development page covers wallet projects across chains.
Frequently asked questions
What are the main MetaMask alternatives?
Rabby, Rainbow, Frame, Phantom and the Base app (formerly Coinbase Wallet) are common browser wallet choices. Rabby, Rainbow and Frame publish their source code, but Phantom and the Base app do not.
Can I fork MetaMask and rebrand it?
Only within the MetaMask license, which allows non-commercial use, including products with no more than 10,000 monthly active users. Larger commercial use needs an agreement with ConsenSys, and the MetaMask name and fox logo cannot be reused.
Do I need Manifest V3?
Yes, for Chrome and other Chromium browsers, because Google has removed Manifest V2 extensions from the Chrome Web Store. Firefox supports Manifest V3 with some differences.
How do several wallets work in one browser?
EIP-6963 lets each wallet announce itself with a name, an identifier and an icon, so the dApp can show a chooser instead of using whichever wallet wrote window.ethereum last.
Should an extension wallet support smart accounts?
Smart accounts are accounts controlled by contract code. Supporting them is now expected, because dApps call EIP-5792 batch methods, and EIP-7702 lets ordinary accounts delegate to contract code. A wallet that supports EIP-5792 and EIP-7702 must also check every EIP-7702 delegation request, because a malicious one can give an attacker control of the account.