What is a native wallet in a browser?

A wallet built into the browser itself rather than installed as an extension. The user never installs it, never manages it from an extensions page, and does not leave the browser to use it.

Why build MetaMask natively instead of shipping the extension?

When the wallet is central to the product. A native integration gives one coherent experience, no install step, and an update path you control through your own browser releases. An extension is faster and cheaper, and is usually the better choice when the wallet is one feature among many.

What was the hardest part of the Omni MetaMask integration?

Making two wallet systems coexist. MetaMask has its own internal architecture and Brave already has its own wallet layer, so the integration had to work with both at once without user-facing conflicts. It took months of careful, methodical engineering.

Is a native wallet more secure than a wallet extension?

Not automatically. A native integration changes where the code lives and who owns the update path, but security still depends on how it is built, reviewed and maintained. Any product that handles funds should plan for security review as part of the work.

How long does it take to build a custom browser with a native wallet?

The Omni browser, which combined a full rebrand, a native VPN, a standalone new tab page, a native MetaMask integration and enterprise policy management, ran for close to a year. A narrower scope takes less time, but a native wallet is always a significant engineering effort.

Can a custom browser built on Brave hide its Brave origins?

Yes. The Omni browser replaced every visible Brave element with Omni's brand, including logos, interface chrome, settings and about screens, and ships with no Brave references in the product.

What does a custom browser fork need after launch?

Ongoing upstream maintenance. A fork has to be rebased onto new Chromium releases and kept patched for security, and Chromium now ships a new stable milestone every two weeks, so a plan for tracking upstream is part of the cost of owning a browser.

Does Entalogics build custom browsers with built-in crypto features?

Yes. Entalogics built the Omni browser on Brave's open-source core with a native VPN, a crypto wallet layer and MetaMask integrated as a native browser feature, and offers Chromium browser development and ongoing upstream maintenance.

Native MetaMask in a Custom Browser: What Omni Taught Us

Short answer: a native wallet is worth building when the wallet is the product, not an add-on. Integrated at the browser level, it gives you one coherent experience, with no install step, no separate update path and no extension store to depend on. The cost is real engineering: you have to make the wallet coexist with everything the browser already ships. We did this for Omni, a custom browser built on Brave's open-source core, where MetaMask is a native feature alongside Brave's own wallet layer. It took months of careful work.

What does "native" actually mean for a wallet?

A wallet extension is a separate piece of software that the user installs into a browser. A native wallet is part of the browser. The user never installs it, never sees an extensions page for it, and does not leave the browser to use it.

For Omni, the requirement was a single product: a browser with a built-in VPN and crypto wallet, accessible with no extensions required, and no visible trace of its Brave origins. MetaMask had to feel like part of that product, so we integrated it at the browser level instead of shipping it as an optional add-on.

Why not just ship the extension?

For many products, an extension is the right answer, and we say so in our post on when an extension beats a rebuild. It is faster, cheaper and easier to maintain. The question is whether it fits your product. These are the trade-offs.

	Wallet as an extension	Wallet as a native feature
Install step	The user installs it	None, it ships with the browser
First-run experience	Depends on the user finding and setting it up	Part of onboarding you control
Update path	Extension store or the extension's own updates	Part of your browser release process
Look and feel	Extension UI inside someone else's chrome	One design system across the product
Engineering effort	Low	High, and ongoing
Fit	Wallet is one feature among many	Wallet is central to the product

Layered diagram of where a native wallet sits inside a custom browser: the wallet lives in the browser layer next to the built-in wallet, VPN and policy management, so it has to coexist with the existing wallet layer on every release

What made the Omni integration hard?

Two things had to coexist. MetaMask has its own internal architecture. Brave already has its own wallet layer. Integrating MetaMask natively meant working with both at once and making them live side by side without conflicts the user could see.

That is the real difficulty, and it is not glamorous. Nothing about it is a single clever trick. It is months of methodical engineering to keep two wallet systems from stepping on each other while the product still feels like one thing. The goal was a single cohesive experience across browsing and crypto workflows.

Is a native wallet more secure than an extension?

Not automatically, and we would not claim it. Security depends on how the integration is built, how it is reviewed and how it is maintained. A native integration changes where the code lives and who owns the update path. It does not remove the need for careful review. If you are building something that handles funds, plan for security review as part of the work, not as an afterthought.

What else did the Omni browser need around the wallet?

The wallet was one part of a larger product. The same build included a full rebrand with no Brave references in the shipped product, a native VPN with connect and disconnect in the browser UI, and a standalone new tab page that Omni's team can update without a full browser release. It also had inherited and tuned privacy and tracker blocking, plus centralized policy and device management for enterprise deployment.

The new tab page is a good example of the same theme. Brave's new tab page is tightly coupled to internal browser APIs and the build system, so making it independently updatable meant rearchitecting how the browser shell talks to it. Native features are rarely a skin. They are changes to how the browser is put together.

What does the user actually notice?

Mostly, they notice nothing, and that is the point. There is no "install the wallet" step, no extension icon to find, and no moment where the product changes look and behavior. Crypto workflows and ordinary browsing sit in the same window, under one brand. When a native feature is done well, it feels like the browser always did this.

That invisibility is also why it is expensive. The user never sees the months spent making two wallet systems coexist, and no one gets credit for conflicts that never happened.

Ship faster with senior engineers

Direct collaboration, AI-augmented delivery, and no agency markup.

Get in touch

What does maintaining a native wallet look like?

Shipping is the first half. A native integration also has to survive three kinds of change:

Upstream browser changes. The browser base keeps moving, and every wallet-related patch has to survive each rebase.
Wallet changes. If the wallet's own architecture changes, your integration points can break, so you need a way to notice before users do.
Interaction with other features. A VPN, privacy controls, a custom new tab page and a wallet all touch the browser shell. A change to one can affect another.

The practical answer is a regression suite around the wallet flows, run on every candidate build, plus a documented owner for each integration point. It is the same discipline as any long-lived fork.

How do you decide between native, extension, or both?

Some products ship both: a native experience for the default path and the extension for users who already have one. The right answer depends on how central the wallet is and how much engineering you can sustain.

If the wallet is one feature among many, ship the extension and move on.

If the wallet is central but you need to ship fast, start with an extension, then go native once the product has proven demand.

If the wallet is the product and you are committed to owning a browser, go native from the start and budget for it.

When should you build the wallet natively?

Build it natively when these are true:

The wallet is the product. Users come for the crypto workflow, not for a general browser.
You need one coherent experience. Onboarding, design and updates all need to be yours.
You have the engineering budget for a fork. Omni's build ran close to a year, and a fork has to be maintained against every upstream Chromium release. See what a faster Chromium cadence means for forks.

Stay with an extension when the wallet is one feature among many, when you need to ship in weeks, or when you do not want to own a browser.

What should you ask before committing?

Who owns updates for the wallet, and how fast can you ship a security fix?

What happens when the wallet vendor changes its architecture?

Which existing wallet or privacy layers in your browser base will it have to coexist with?

Do you have a plan for tracking upstream Chromium releases for as long as the product lives?

If you are weighing a custom browser with built-in crypto features, see the Omni case study, our Chromium browser development service, or hire Chromium browser developers.