crypto wallet

Project Roadmap
+ Branding Guide 2026

A step-by-step plan for white-labelling MetaMask: copying its code and rebranding it as a client's own crypto wallet, with their name, logo, colours and blockchain, published on the Chrome Web Store. About 12 weeks, versus many months building a wallet from scratch.

Why not code your own?

  • Proven security: key storage, encryption and transaction signing have been hardened over years of real-world use by millions. Getting that right from scratch is where home-built wallets fail.
  • Works with every dApp: it already speaks the standard Ethereum wallet protocols, so Uniswap, NFT marketplaces and the client's own platform just connect.
  • Months faster, far cheaper: you're rebranding and configuring, not building and auditing a wallet from zero.
  • Keeps improving: you can pull in MetaMask's security fixes and updates instead of maintaining everything alone.

The trade-off: you work within MetaMask's licence and replace its backend services (both covered below).

Updated October 2026 for MetaMask's current licensing (ConsenSys licence, not MIT) and the latest build steps, checked against the MetaMask repo's main branch. Timings are estimates.

Delivery roadmap

Click any item to expand for explanation. MetaMask → rebrand → ship.

Head to github.com/MetaMask/metamask-extension and fork it into your own GitHub account.

Licence check first: MetaMask is not MIT licensed (it changed in 2020). The current ConsenSys licence only permits derivative use within its defined "Non-Commercial Use", which expressly includes resulting programs with no more than 10,000 monthly active users, subject to its notice and other conditions, and as ConsenSys reasonably determines. Anything outside those terms needs permission from ConsenSys (the LICENSE currently gives communications@metamask.io). Read the current LICENSE in the repo and get legal advice before building a commercial fork.

Clone it locally, then: run nvm use (it needs the Node version in .nvmrc, currently Node 24), corepack enable (the project uses Yarn 4, managed per project), copy .metamaskrc.dist to .metamaskrc and add your own INFURA_PROJECT_ID (required). Then yarn install && yarn start spins up a development build you can load as an unpacked extension in Chrome via chrome://extensions → Load unpacked.

Verify you can: create a wallet, send a transaction on testnet, and connect to a dApp like Uniswap. If all three work, your baseline is solid.

Tip: MetaMask supports GitHub Codespaces, so you can have a dev environment running in under 5 minutes without any local setup. Handy for a quick client demo, but there's a free monthly quota and the default Infura key on a fork is heavily rate-limited, so add your own key.

This is the most visible phase. Start with a global search for "MetaMask" across the codebase to find every brand mention:

# Find all files with MetaMask references
grep -r "MetaMask" --include="*.json" --include="*.ts" --include="*.tsx" -l

Key files to change:

  • app/_locales/en/messages.json — most user-facing text (plus the other language folders)
  • app/images/ — replace all logo/fox PNG and SVG assets
  • ui/css/utilities/ — colour and font overrides (the colours themselves come from the @metamask/design-tokens package)
  • app/manifest/v3/_base.json — extension manifest: name and description come from appName / appDescription in messages.json, but it also has hard-coded branding ("default_title": "MetaMask", "author": "https://metamask.io") and the icon files

The fox mascot is a separate npm package (@metamask/logo) that renders a 3D WebGL animated fox. Run yarn remove @metamask/logo then replace the fox component in each file with a plain <img> pointing to the client's logo SVG.

This is where you tailor the wallet to the client's specific blockchain setup. Most clients will be on Ethereum mainnet, a Layer 2 (Polygon, Base, Arbitrum), or occasionally a custom chain.

What to configure:

  • Default network — set their chain as the default so users don't need to switch manually
  • Custom RPC endpoint — use the client's own Infura project ID in .metamaskrc, or point the default network at their own RPC provider. RPC is only one dependency: see "MetaMask backend services" in the checklist for the rest.
  • Pre-loaded tokens — add the client's token contract address so it shows in the wallet automatically
  • dApp allowlist — optionally restrict which dApps the wallet can connect to
Tip: If the client is on a custom EVM chain, get their chain ID, RPC URL, block explorer URL, and native currency symbol before starting this phase. You can't configure what you don't have.

This is the phase where the wallet becomes genuinely theirs rather than just a reskin. Common client requests:

  • Custom onboarding flow — branded welcome screens explaining their specific product
  • Restricted feature set — hide swap, bridge, or buy features if the client doesn't want them
  • Deep link to their dApp — a prominent button connecting directly to their platform
  • In-wallet support — help button pointing to their own support docs or chat widget
  • Custom transaction labels — "Pay [ClientName]" instead of generic "Send ETH"
Scope creep warning: This phase is where projects balloon. Agree a fixed feature list with the client in writing before you start. Every "small" addition costs time.

Before anything goes near mainnet, test everything on a public testnet. For Ethereum use Sepolia, for Polygon use Amoy (Mumbai was shut down in 2024). Get free test ETH from a faucet.

Test checklist:

  • Create new wallet — seed phrase generation and backup flow
  • Import existing wallet — via seed phrase and private key
  • Send and receive ETH/tokens
  • Connect to a dApp (use Uniswap on testnet)
  • Sign a transaction and reject a transaction
  • Lock and unlock the wallet
  • Switch networks manually
  • Install on a fresh Chrome profile (no prior MetaMask installed)
  • Test a production-like build with LavaMoat on (yarn build:test). yarn start runs without LavaMoat, MetaMask's supply-chain security sandbox, so a dev build passing is not enough
Tip: Test the install on a machine that has never had MetaMask installed. Conflicts with the original MetaMask extension are a real issue if a user has both installed.

Build the production package with yarn dist, which creates the production build and the zip you upload to the Chrome Web Store.

What Google requires for a wallet extension:

  • Privacy policy URL — mandatory, must explain key storage, data collection
  • Store listing copy — name, short description (132 chars), full description
  • Screenshots — at least 1, ideally 3–5 at 1280×800 or 640×400
  • Promo tile — 440×280px store banner image
  • Developer account — a one-time registration fee (US$5 at the time of writing; check the current amount)
Submit as soon as the release candidate is ready: functionally complete and security-tested, not half-built. Google expects working, tested extensions with accurate listings, and may ask you to justify permissions. Review times vary; for a crypto wallet, plan for several weeks as a contingency (a planning estimate, not a Google figure).

Once Google approves, the extension goes live on the Chrome Web Store. Users can install it directly or you can distribute the install link to the client's user base.

Handover deliverables to prepare for the client:

  • Full source code repo access (private GitHub repo)
  • Build and deployment instructions
  • Chrome Web Store developer account credentials (or transfer ownership)
  • Documentation for updating the extension post-launch
  • Infura/Alchemy account credentials for their RPC endpoint
Ongoing revenue idea: Offer a monthly retainer for updates, Chrome policy compliance, and security patches. MetaMask updates frequently — staying in sync with upstream security fixes has real value.
Critical path: Get the release candidate functionally complete and security-tested by Phase 6, then submit straight away. Store review for a wallet can take weeks (plan for it; Google doesn't publish a figure), and being code-complete but stuck in review is a frustrating way to miss a client deadline.

Branding checklist

Visual assets

Provide icons at 16, 32, 48 and 128px (Chrome recommends at least 16, 48 and 128; 128px is what the Web Store shows). Export them from the client's logo as PNG with transparency. MetaMask's manifest also declares 19, 38, 64 and 512px versions in images/, so replace every size it lists, not just four.
The main logo appears in the popup header, onboarding screens, and loading states. Drop SVG and PNG versions into app/images/ replacing the MetaMask logo files. Keep the same filenames where possible to avoid hunting down every import reference.
The splash screen is the first thing new users see. MetaMask shows the animated fox here. Remove the @metamask/logo WebGL component entirely and replace with a clean branded screen — the client's logo centred on a branded background colour. Simple is better here.
For the Chrome Web Store you need: screenshots at 1280×800px (minimum 1, ideally 3–5 showing key screens), and a promotional tile at 440×280px. Take real screenshots of your finished extension — don't mock them up, Google can tell.

Colour and typography

MetaMask's colours come from its design-token packages (@metamask/design-tokens and a Tailwind preset), loaded at the end of ui/css/index.scss. Because they load last, overrides placed earlier (for example in utilities/colors.scss) get overwritten. The safer approach: add your own brand file imported after the design-tokens line in ui/css/index.scss, override the token variables there for both light and dark themes, then check every screen visually. Verify against the checked-out code, as the theming setup changes between releases. Don't edit packages in node_modules.
MetaMask now uses its own brand typefaces, MM Sans and MM Poly, plus Inter. The MM fonts are MetaMask's brand, so replace them. They're loaded in ui/css/utilities/fonts.scss with the files in the fonts folder. Swap in the client's brand font or a free one like DM Sans. Inter is a free open-source font and can stay.
The fox is a 3D WebGL animation from the @metamask/logo npm package. It appears on the splash screen, onboarding, and some loading states. Remove the package with Yarn, then search for every import of it and replace with a static logo image. Also delete all fox PNG/SVG files from app/images/.
# Remove the package
yarn remove @metamask/logo
# Find all usages
grep -r "metamask/logo" --include="*.js" --include="*.ts" -l

Text and strings

The manifest at app/manifest/v3/_base.json takes its name and description from __MSG_appName__ / __MSG_appDescription__, i.e. appName and appDescription in app/_locales/en/messages.json (and each language file you keep). It also hard-codes "default_title": "MetaMask" (the toolbar tooltip) and "author": "https://metamask.io": change both. The version comes from package.json; reset it for the client's first release.
Most user-facing text lives in app/_locales/en/messages.json: thousands of strings (about 3,900 on main in October 2026), with many mentioning MetaMask. Find-and-replace "MetaMask" → client name, then read the onboarding and error strings for anything still MetaMask-specific. But this file is not the whole rebrand: the manifest, images, hard-coded URLs and other language folders all need doing too.
Searching for "metamask.io" finds support links, but a commercial fork needs a full inventory of MetaMask-specific hosts: support and help URLs, API endpoints, deep links, feature flags, authentication, analytics, Snaps infrastructure, security services and CDNs. Start with builds.yml and .metamaskrc.dist (dozens of MetaMask URLs), then search the code. Replace each with the client's own, or disable the feature.

Config and API keys

The build needs an Infura key: set INFURA_PROJECT_ID in your .metamaskrc file (copied from .metamaskrc.dist). Use the client's own Infura account so RPC calls are on their bill and under their control. A fork using the default key is heavily rate-limited. Alchemy or another RPC provider can be set as the network endpoint instead.
MetaMask uses Sentry for error tracking and Segment for analytics. The keys come from build settings (builds.yml and .metamaskrc, e.g. SEGMENT_WRITE_KEY) rather than being hard-coded. Either point them at the client's own accounts or turn them off for a leaner, more private wallet, which is easier and what most clients prefer.
"Buy crypto" now runs through MetaMask's own on-ramp service (METAMASK_RAMP_API_CONTENT_BASE_URL in builds.yml points at MetaMask's servers), not swappable partner keys. A white-label fork has to audit this and either remove the Buy feature or replace it. Our recommendation is to integrate a provider directly (Transak, MoonPay, Ramp and others have partner programmes), but that's a design choice, not something the MetaMask code sets up for you.
This is bigger than it looks. Besides token prices, token lists, accounts, swaps and bridging (the *.api.cx.metamask.io URLs in .metamaskrc.dist), builds.yml wires in authentication, storage, notifications, security alerts, signature insights, compliance checks, CDNs and deep-link infrastructure. A commercial fork shouldn't depend on services MetaMask can rate-limit or switch off. Inventory every service the client's feature set touches, then disable it, replace it, or cover it in an agreement with ConsenSys. Do this in week one: it decides how big Phase 4 really is.

Legal and compliance

Google will not approve a crypto wallet extension without a privacy policy URL. It must cover: what data is collected, how private keys are stored (locally, never transmitted), whether analytics are used, and contact information. Host it on a simple web page. If the client doesn't have one, drafting it is a billable extra.
MetaMask shows a ToS acceptance screen during onboarding. Point it at the client's own terms covering: that the wallet is non-custodial (users control their keys), that lost seed phrases cannot be recovered, and limitation of liability. Being non-custodial does not automatically remove regulatory obligations (see "Regulation"). A crypto-specialist solicitor is worth the cost for a commercial product.
Since 2020 the MetaMask extension has been under a ConsenSys licence, not MIT. It only permits use within its defined "Non-Commercial Use", which expressly includes resulting programs with no more than 10,000 monthly active users (as ConsenSys reasonably determines), and requires prominent notice that the software is MetaMask's and ConsenSys's copyright. Uses outside those terms need permission from ConsenSys; the current LICENSE gives communications@metamask.io as the contact. Terms can change, so read the current LICENSE in the repo and get legal advice before committing to a commercial fork.

Security and release

A wallet holds people's money, so "works on Sepolia" is not enough. Before release: an independent security review or audit; dependency and supply-chain review (and keep LavaMoat policies working); secrets and API keys kept out of the shipped code; seed phrase and private-key storage checked; Content Security Policy and extension permissions kept to the minimum; phishing, signing and transaction-safety warnings tested; a reviewed, reproducible production build; a way for people to report vulnerabilities plus an incident plan; and a process to pull in MetaMask's upstream security fixes quickly.
The Chrome Web Store requires the minimum permissions needed, accurate Privacy Practices answers in the dashboard, secure handling of user data, and prominent disclosure and consent where personal or sensitive data is involved. Financial, payment and authentication data count as sensitive. Collected data must be necessary for the extension's single, disclosed purpose. Turning off analytics you don't need makes all of this simpler.
Whether the wallet triggers financial-services or crypto regulation depends on what the client actually offers (swaps, bridges, buying and selling crypto, token sales) and where their users are. "Non-custodial" does not automatically mean "unregulated". Get jurisdiction-specific legal advice before launch, and scope features with that in mind.
Build time: about 12 weeks (estimate) Biggest time sinks: MetaMask backend services, licensing and security review