.png)
"Privacy is not a crime, and compliance with laws and regulations doesn’t have to conflict with it. Cryptography allows us to have compliance while still maintaining users’ privacy. The game’s not zero-sum." --Michael Lewellen, Head of Solutions Engineering at Turnkey
Browser extension wallets like MetaMask have a privacy problem.
Recent research from KU Leuven tested 85 popular browser extension wallets and found that many leak enough information to track users’ onchain activity, link separate accounts, and build detailed profiles of their transactions.
Published in a paper called The Masks We (Think We) Wear, the research examined wallets representing 35.16 million Chrome Web Store users and identified five distinct privacy threats.
These threats are not hacks or exploits. They are design problems. Browser wallets expose this information because of how they interact with websites, applications, and external infrastructure.
Embedded wallets do not face the same design constraints by default, allowing them to offer stronger privacy for both institutions and individuals. As Vitalik Buterin wrote in April 2025, “Privacy is an important guarantor of decentralization: whoever has the information has the power.”
Turnkey’s non-custodial embedded wallet infrastructure helps preserve that decentralization at the signing layer. Combined with Turnkey’s integrations and partner ecosystem, it can help protect transaction privacy from wallet creation through finality.
This article explains the design differences between browser wallets and embedded wallets, why those differences matter for privacy, and how Turnkey supports the networks, integrations, and applications building more private and verifiable onchain experiences.
The five privacy threats from browser extension wallets
The five threats the paper reveals center around a core design issue. A browser extension wallet injects a shared provider object into nearly every page you visit. That object announces itself, remembers which sites it is connected to, and answers requests, including from inside frames loaded by other sites.
The injection causes five significant threats which include:
1. Address linkability
To show your balances, a wallet constantly queries outside servers, and those requests carry your addresses. When a wallet bundles two of your addresses into one request, or fires requests within milliseconds of each other, the server learns they belong to the same person. Seventeen of the wallets exposed links like this, covering a large share of the installs studied.
2. Fingerprinting
Each extension announces itself to any page that loads, so a script can read the exact set of wallets you carry, even if you never connect and even if you block cookies.
3. Broken logout
Disconnecting a wallet often does not revoke access. Of 30 popular Web3 apps tested, only 11 sent a real revoke command when a user disconnected. Even when the command was sent, 22 of the 36 wallets kept exposing the address afterward, and that access survived clearing cookies and restarting the browser.
4. Cross-site tracking
Because a wallet can be detected across different websites, the same user can be observed and tracked across multiple apps.
5. Cross-frame deanonymization
A wallet may answer an address request from inside an invisible frame on an unrelated site. This creates a path for connecting a pseudonymous wallet address to a user’s real identity.
The scale is not small. Thirty-six of the 85 wallets announce themselves, and those wallets account for about 82% of the installs studied.
After researchers had brought their findings to the wallet providers’ attention, Coinbase Wallet and Coin98 had fixed the most far-reaching issue, and Hana Wallet did so later. But several of the largest wallets declined to treat it as a defect at all.
One called it a known duplicate with no plans to stop injecting its provider, another concluded that the vulnerability does not exist, and others marked it informational, low risk, or out of scope.
If the leak is a property of the architecture rather than a flaw in the code, then patching individual wallets will not solve it. You must address the faulty architecture. The question then becomes whether a different architecture avoids the surface entirely.
Embedded wallets: Ways they protect against these threats
An embedded wallet is built directly into an application rather than installed as an extension. It injects nothing into third-party pages.
There is no provider announcing itself on arbitrary websites, so there is no installed-wallet fingerprint to read.
Any wallet that displays a balance must send an address to blockchain infrastructure. Embedded wallets do not eliminate this. The difference is control: developers choose how addresses are queried, while Turnkey returns signed transactions to the application for broadcast without sending a user’s other addresses to an external server.
What about connecting to external dApps?
A fair question is what happens when an embedded wallet does need to interact with an outside site. With embedded wallets, it does so through an explicit, scoped connection, not the ambient injection the study describes.
With Turnkey's Wagmi and EIP-1193 integration, a dApp requests accounts through the standard provider interface, the user approves in an app-controlled prompt, and Turnkey signs inside the enclave and returns the result. Nothing announces itself to sites the user never connected to, and nothing sits in arbitrary pages or their frames waiting to answer.
The tradeoff is narrow. A dApp the user deliberately connects to does learn the wallet address they connect with to operate, but that is consented disclosure to a chosen counterparty, not the non-consensual fingerprinting and cross-site leakage the study measures.
The benefit holds precisely because the wallet is not injecting a shared provider into every page.
"We should be absolutely protecting the ability for people to build protocols that are non-custodial.” --Michael Lewellen, Head of Solutions Engineering at Turnkey
Privacy is more than not being tracked
Everything above is about metadata privacy: not being fingerprinted, linked, or deanonymized through the wallet's behavior in the browser. But there is a second layer. Onchain confidentiality is about what the ledger itself reveals: balances, amounts, and counterparties.
Public blockchains may appear anonymous, but most are only pseudonymous. Wallet addresses do not show a person’s name, yet transaction patterns and other data can still be used to connect multiple wallets and identify the people or organizations behind them. Removing browser-level tracking does not solve this because the information is visible on the ledger itself.
Both layers follow the same privacy principle: reveal only what is necessary. Embedded wallets can reduce what is exposed through the browser and wallet infrastructure, while onchain confidentiality protects what transactions reveal on the public ledger.
Turnkey x privacy infrastructure
Turnkey provides the secure wallet infrastructure that privacy-focused networks and applications can build on. Private keys, authentication, policy enforcement, and signing are handled inside a trusted execution environment, helping teams maintain non-custodial control over transactions.
The network or protocol provides the privacy features themselves, such as hiding transaction details or limiting what each participant can see. Turnkey provides the secure key management and signing layer that makes those transactions possible.
Turnkey currently supports several privacy-focused networks, including:
Canton Network
Canton provides configurable, need-to-know privacy for regulated financial applications. Turnkey allows teams to manage private keys and sign Canton transactions through a single API using non-custodial, TEE-backed wallets.
Midnight
Through its partnership with the Midnight Foundation, Turnkey brings API-first key management and developer SDKs to Midnight’s privacy network. Midnight uses selective disclosure, allowing applications to reveal only the information a specific party is authorized to see.
Across both networks, the model is consistent: the network provides transaction confidentiality, while Turnkey provides the secure, non-custodial key management, policy, and signing infrastructure underneath it.
Beyond dedicated integrations, Turnkey is curve-agnostic, so it can secure key material for many other chains at the curve level, including privacy chains like Monero, whose keys use the Ed25519 curve Turnkey supports.
.png)
Turnkey: Embedded wallets as the foundation for onchain privacy
Privacy onchain is a stack, and the wallet sits at its foundation. Browser extension wallets can expose signals across sites, making it easier to track users, connect accounts, and build a broader picture of their onchain activity.
Embedded wallets reduce that exposure by removing the shared extension layer injected into every site. From there, privacy networks and compliance systems can control what transaction data is revealed and to whom.
Turnkey provides the secure, verifiable, non-custodial wallet infrastructure underneath that stack. Wallets, keys, policies, and signing remain protected at the infrastructure layer, giving applications a stronger foundation for preserving privacy from wallet creation through transaction finality.
The principle is consistent at every layer: verify what is allowed without exposing more than necessary.
Related articles
Why OpenUSD could become a new standard in stablecoin money movement
What is OpenUSD, and what does it mean for stablecoin growth? Learn why it matters and how to secure stablecoin transactions.
How does embedded wallet authentication work? Self-custody without seed phrases.
Embedded wallet authentication explained and what teams need to understand before designing their login flows.
