The Masks We (Think We) Wear: Privacy Threats of Browser-Extension Wallets in the Web3 Ecosystem

Source: arXiv:2607.06141 · Published 2026-07-07 · By Weihong Wang, Yana Dimova, Victor Vansteenkiste, Tom Van Goethem, Tom Van Cutsem

TL;DR

This paper investigates significant privacy vulnerabilities inherent to browser-extension cryptocurrency wallets within the Web3 ecosystem. Users generally expect their multiple blockchain addresses to remain unlinkable unless explicitly disclosed. However, this study uncovers that the routine operations and architectural designs of wallets systematically leak information that enables adversaries to link different user addresses, track users across sessions and sites, and correlate on-chain assets with web browsing behavior. The authors identify and formalize five classes of privacy threats arising from both network-level and web-exposed wallet interactions. Using a large-scale empirical study covering 85 popular Chrome browser-extension wallets with a combined user base of over 35 million, they demonstrate that data leakage through RPC requests, inconsistent permission revocation, and unsafe provider interface injections into cross-origin iframes create exploitable signals for user deanonymization. The paper further explores practical mitigations to reduce these risks and advocates for standardized, privacy-preserving wallet architecture designs.

Key findings

• 17 out of 57 fully functional wallets leak structural linkability signals between multiple addresses via RPC requests, affecting approximately 22.1 million users (62.9% of the user base).
• 36 wallets (covering 82% of users) are detectable through a new wallet fingerprinting technique based on provider interface exposure.
• 22 of these 36 wallets fail to fully revoke permissions after user disconnect, continuing to expose previously authorized addresses across sessions.
• 23 wallets inject their provider interfaces into cross-origin iframes, enabling passive, cross-site wallet address tracking without user interaction.
• Nearly 90% of address-bearing requests go to wallet-specific backend domains rather than widely shared RPC providers, concentrating user data visibility at wallet vendors.
• Background extension contexts (e.g., service workers) generate substantial address-leaking network traffic missed by prior measurement frameworks.
• Many wallets embed third-party analytics or telemetry scripts, but direct address leakage to these is comparatively rare.
• Permission revocation mechanisms are inconsistent across wallets due to lack of standardized protocols, leading to persistent address exposure despite user attempts to disconnect.

Threat model

The adversary is either a network-level passive observer with access to decrypted HTTPS requests made by the wallet to backend endpoints (including wallet vendors, node providers, analytics services), or a web-based code injection adversary operating as a third-party script embedded on websites including dApps and unrelated sites. The adversary cannot break cryptography, interfere with private keys, or compromise the wallet extension but analyzes metadata, RPC request contents, permission states, and provider interface exposure to infer address linkage, cross-site tracking, and user deanonymization.

Methodology — deep read

The study focuses on two adversary models: (1) network-side adversaries capable of observing decrypted wallet network requests at backend endpoints, and (2) web-based adversaries embedded as third-party scripts that can observe provider API exposure in the browser. The authors collect 85 Chrome Web Store wallet extensions with >10k users as of November 2025 (CWS-10K/85 dataset), supplemented by legacy Torres et al. datasets for temporal comparison, and 30 popular Ethereum dApps from DappRadar to simulate real-world wallet interactions.

For network analysis, they enhance the Puppeteer-based request interceptor framework used by Torres et al. by adding support for extension background contexts (service workers and background pages), addressing prior blind spots in measuring wallet traffic originating outside webpages. The wallets are set up with 3 test accounts funded with minimal ETH to verify balance queries and multiple addresses. They classify wallets as broken, partially functional, or fully functional based on initialization and RPC traffic.

They run scripted sessions involving random UI interactions to elicit typical address queries and record all outbound HTTP and WebSocket traffic, capturing full request payloads, timing, and destination domains. They analyze occurrence of multiple addresses batched in single requests (co-occurrence) and correlated timing of separate requests containing different addresses within a 10ms window.

For web-side measurement, they build a Playwright-based framework that drives wallet-dApp interaction cycles in a controlled environment using a minimal test dApp and the 30 real-world dApps. Each test involves discovering wallets via modern EIP-6963 events, connecting (eth_requestAccounts), disconnecting (via wallet_revokePermissions if supported), and then querying eth_accounts post-revocation. They instrument the webpage to record accessible address data and wallet API calls at each stage, including localStorage and cookie changes. Due to variance in wallet UI and flow complexity, setup involves a mix of automated and manual steps, ensuring clean fresh profiles per test. Ethical considerations exclude any real user data, relying solely on test accounts in isolated profiles.

Results are reported across the datasets comparing legacy and modern wallets and detail prevalence of address leakage, third-party endpoints contacted, permission revocation failures, provider injections into iframes, and wallet fingerprintability. The authors carefully distinguish vendor-operated backend domains from other third-party trackers and discuss the implications of fragmented RPC providers on data aggregation. The comprehensive methodology combines fine-grained network traffic interception with in-browser interaction testing to reveal privacy risks at multiple layers.

Technical innovations

• Extending Puppeteer-based request interception to capture network traffic from wallet background contexts, revealing previously unobserved address leak channels.
• Identification and formalization of five distinct wallet privacy threat classes combining network-level and web-exposed attack surfaces.
• A new detection technique for wallet fingerprinting based on provider interface exposure events compliant with EIP-6963.
• Demonstration that many wallets inject provider APIs into cross-origin iframes, enabling off-dApp cross-site tracking and deanonymization.
• Systematic empirical quantification of widespread permission revocation inconsistencies across a large, user-popular wallet ecosystem.

Datasets

• Torres-2023/100 — 100 wallet extensions — legacy dataset from Torres et al. 2023
• Torres-2025/100 — 100 wallet extensions — updated versions as of November 2025
• CWS-10K/85 — 85 wallet extensions with >10k users each — fresh crawl from Chrome Web Store November 2025
• DappRadar-30 — 30 popular Ethereum dApps — public dApp platforms as of November 2025
• Analytics domains list — 21 well-known third-party tracking domains — compilation from public sources

Baselines vs proposed

• Torres-2023/100 baseline: 7 wallets leaking addresses (page context only) vs enhanced: 42 wallets with additional extension background context leaks observed
• Torres-2025/100 baseline: 18 wallets leaking addresses (page context) vs enhanced: 40+ wallets including background leaks
• CWS-10K/85: 57 wallets leak addresses to third-party endpoints vs prior datasets largely undercounted these leaks
• Wallets with correct permission revocation: 14 of 36 detectable wallets (38.9%) vs 22 wallets (61.1%) exposing revoked addresses
• Wallets injecting provider interface into cross-origin iframes: 23 out of 85 (27%) enabling cross-site tracking
• Timing correlation of multiple addresses within 10ms window: observed in 11 wallets in CWS-10K/85
• Address co-occurrence in single RPC request: observed in 13 wallets in CWS-10K/85

Figures from the paper

Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2607.06141.

Fig 1: A wallet’s two roles: financial interfaces (showing

Fig 2: Single-site cross-session re-identification and ad-

Fig 3: Cross-site cross-session tracking and wallet-address

Fig 4: A shared third-party tracker on websiteA.com em-

Fig 5: Outcome tree showing which wallets (referenced in

Limitations

• The study focuses on Chrome browser-extension wallets; other platforms or wallet types (mobile, desktop) are not evaluated.
• Automation of wallet setup is partial; some manual interaction is needed due to heterogeneous onboarding UX, potentially limiting scale.
• No active adversarial attacks or mitigation robustness testing was performed; analysis is observational and passive.
• Only Ethereum-compatible wallets and dApps are studied; findings may not generalize to non-Ethereum chains.
• Some wallet network traffic may be obfuscated or encrypted at application layer, limiting visibility to all data flows.
• The permission revocation study relies on behavior of selected dApps that trigger revocation, which may not reflect all real-world usage patterns.

Open questions / follow-ons

• How can wallet permission revocation standardization be implemented ecosystem-wide to prevent persistent address exposure?
• What cryptographic or protocol-level privacy enhancements could better isolate wallet address queries from backend providers?
• Can new browser security policies or extension architectures prevent provider interface injection into cross-origin iframes?
• How do user behavior patterns around granting and revoking dApp permissions affect real-world exposure durations and risks?

Why it matters for bot defense

Bot-defense and CAPTCHA practitioners should be aware that browser-extension wallets for Web3 introduce complex privacy leak vectors through both network traffic and scripting interfaces exposed to webpages. From a bot/human classification perspective, the distinctive patterns of multiple address queries, provider injection footprints, and persistent permission states can serve as strong signals of wallet presence and user identity linkage. These signals might be exploited to track or fingerprint users across sessions and sites, complicating standard anti-abuse models relying on IP plus cookie-based isolation. Defenses in Web3-enabled sites must consider this layered privacy leakage and carefully manage wallet permissions and API exposure to avoid unintended deanonymization. Additionally, CAPTCHAs integrating with Web3 wallets should enforce strict permission isolation and revocation control, and avoid trusting wallet states without validation. The paper’s findings underscore an urgent need for privacy-aware wallet design to prevent large-scale cross-site user tracking that could undermine anti-bot systems relying on persistent anonymity.

Cite

@article{arxiv2607_06141,
  title={ The Masks We (Think We) Wear: Privacy Threats of Browser-Extension Wallets in the Web3 Ecosystem },
  author={ Weihong Wang and Yana Dimova and Victor Vansteenkiste and Tom Van Goethem and Tom Van Cutsem },
  journal={arXiv preprint arXiv:2607.06141},
  year={ 2026 },
  url={https://arxiv.org/abs/2607.06141}
}

Read the full paper

• arXiv:2607.06141 (abstract)
• arXiv:2607.06141 (PDF)