Pith. sign in

REVIEW 3 major objections 7 minor 44 references

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

T0 review · 3 major / 7 minor · reviewed 2026-07-08 · glm-5.2

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Crypto Wallets Leak User Addresses to Any Website

desk verdict Five wallet-privacy threats measured at scale; headline user-impact figures overcount but the threats are real read the letter →

arxiv 2607.06141 v1 pith:3RMS5TKA submitted 2026-07-07 cs.CR

Weihong Wang , Yana Dimova , Victor Vansteenkiste , Tom Van Goethem , Tom Van Cutsem This is my paper · ORCID
classification cs.CR
keywords browser-extensionwalletsprivacyaddresslinkabilityEIP-6963permissionrevocationcross-originiframefingerprintingWeb3
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper identifies five classes of privacy threats in browser-extension cryptocurrency wallets, showing that routine wallet behavior—background network requests, inconsistent permission revocation, and provider injection into cross-origin iframes—systematically leaks user addresses and enables cross-session, cross-site tracking. The authors tested 85 of the most popular Chrome Web Store wallet extensions (representing 35.16 million users) and found that 65.4% of users are affected by network-side address linkability, 82% are detectable through a new EIP-6963-based fingerprinting vector, and 78.95% are vulnerable to iframe-based address leakage on arbitrary websites. The core mechanism is a mismatch between what wallets promise (independent pseudonymous addresses) and what they actually expose: wallets batch multiple addresses into single RPC requests visible to external endpoints, fail to revoke stale permissions after a dApp requests disconnection, and inject their provider objects into cross-origin iframes where any embedded tracker script can read previously authorized addresses without user interaction. The paper traces these failures to two structural gaps: the absence of a standardized permission revocation mechanism in the EIP-2255 specification, and unrestricted provider injection into cross-origin contexts.

What carries the argument

The five privacy threats arise from two structural gaps in the Web3 wallet ecosystem: (1) EIP-2255 defines how permissions are granted but specifies no revocation mechanism, leaving wallets to implement disconnection inconsistently; (2) wallets inject their provider objects into cross-origin iframes without restricting access to top-level browsing contexts, allowing tracker scripts embedded in invisible iframes to call eth_accounts and read addresses. The EIP-6963 discovery protocol, designed to solve multi-wallet conflicts, additionally exposes installed wallet combinations as a fingerprinting signal on any website.

What would settle it

Demonstrate that real-world wallet usage produces substantially different RPC request patterns (no address batching, no timing correlation) than the automated measurement procedure, which would invalidate the network-side threat prevalence rates.

Watch

Extended reading notes

Core claim

The central discovery is that browser-extension crypto wallets passively disclose user addresses and address relationships through two distinct channels that users cannot control. On the network side, wallets issue background RPC requests that either batch multiple addresses together or send them in rapid succession, allowing any endpoint receiving these requests to definitively link addresses to the same wallet instance. On the web side, the EIP-6963 wallet discovery protocol creates a new fingerprinting vector (revealing which wallets are installed), while the lack of a standardized revocation mechanism means 22 of 36 EVM-compatible wallets continue returning previously authorizedaddresses

Load-bearing premise

The measurement framework's automated interaction procedure—randomly clicking up to ten UI elements or running for sixty seconds—may not capture the same RPC call patterns that a real user would generate during normal dApp usage, which means the network-side address linkability rates could be higher or lower than measured.

Editorial extensions

If this is right

  • Any third-party tracker script on any website—not just dApps—can detect which crypto wallets a user has installed via EIP-6963 events, creating a Web3-specific fingerprinting vector that works even when cookies are blocked or browser storage is cleared.
  • Stale wallet permissions function as unforgeable, user-clearable-resistant tracking identifiers: because addresses are stored in extension-controlled storage rather than browser cookies or localStorage, clearing browser data does not remove them, making them more durable than traditional web tracking identifiers.
  • A single revocation-unsafe wallet installed by a user enables ecosystem-wide address clustering: any shared tracker across multiple dApps can merge address sets from different sites into a unified profile of the user's Web3 holdings.
  • Wallet vendors and RPC endpoint operators can observe which addresses belong to the same user through request batching and timing patterns, potentially enabling targeted attacks against high-value users.
  • The iframe-based attack vector means that linking a user's real-world identity (e.g., email, name from a Web2 site) to their on-chain wealth requires only one previously granted dApp permission and one shared tracker between that dApp and the identity-revealing site.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's measurement framework captures wallet behavior through automated interaction (random UI clicks for up to 60 seconds), which may not fully replicate real user dApp usage patterns. If real users trigger different RPC call patterns during actual dApp interactions, the network-side linkability rates could differ from those reported.
  • The finding that most wallet vendors classified the iframe exposure issue as 'informational' or 'out of scope' suggests that market incentives alone may not drive adoption of the proposed mitigations, and regulatory or standards-body intervention may be necessary for ecosystem-wide change.
  • The shift toward wallet-specific backend domains (87.6% of address-receiving domains contacted by only one wallet) implies that address visibility is becoming more centralized within individual wallet vendors, creating concentrated data honeypots that could be attractive targets for compromise.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 7 minor

Summary. This paper identifies and measures five privacy threats in browser-extension cryptocurrency wallets: (1) network-side address linkability via batched/timed RPC requests, (2) wallet fingerprinting via EIP-6963 discovery events, (3) cross-session tracking via stale permission state, (4) cross-dApp tracking via shared trackers and stale permissions, and (5) cross-site tracking and deanonymization via provider injection into cross-origin iframes. The authors build two measurement frameworks (an improved network request interceptor extending Torres et al., and a web exposure framework using Playwright), apply them to 85 popular Chrome Web Store wallets (35.16M users) and 30 dApps, and report prevalence figures for each threat. The paper also proposes mitigations and documents responsible disclosure.

Significance. The paper makes a solid empirical contribution to Web3 privacy. The iframe-based cross-site tracking vector (Threat #4) is novel and well-motivated: the attack chain connecting wallet provider exposure in cross-origin iframes to real-world deanonymization is clearly articulated and supported by measurements across both wallets and dApps. The improved network interceptor that captures service worker / background page traffic is a useful methodological extension over Torres et al. The reproducibility commitment (open-source frameworks, public demo) and responsible disclosure process are commendable. The systematic measurement of permission revocation behavior across 36 EVM-compatible wallets and 30 dApps fills a genuine gap in the literature.

major comments (3)
  1. §4.3.3 and Table 6: The headline user-impact figure for Threat #1 (65.4%, 23.0M users) is computed by summing CWS user counts for all 17 wallets exhibiting co-occurrence or timing correlation signals, divided by the total user base. However, this threat only applies to users who maintain multiple addresses in the same wallet. The paper tests with 3 accounts per wallet but does not measure or estimate what fraction of real users actually use multiple addresses. Single-address users of these 17 wallets are included in the 23.0M figure despite having no addresses to link. The paper should either (a) explicitly caveat this figure as an upper bound conditional on multi-address usage, or (b) provide an estimate of multi-address user prevalence. As stated, the figure overstates the population at risk.
  2. §5.6.5 and Table 6: The 78.95% figure for Threat #4 represents the fraction of users whose wallets expose provider interfaces in cross-origin iframes (23/36 wallets). However, the full attack chain (§5.5) requires three additional preconditions: (i) the user previously connected to an iframe-embeddable dApp, (ii) that dApp includes the same tracker as the attacking site, and (iii) the wallet has not revoked the permission. The paper measures iframe embeddability of dApps (18/30) and wallet iframe exposure (23/36) but does not measure the joint probability of these conditions. Table 6 presents 78.95% as the 'ecosystem impact' for Threat #4, which conflates a necessary condition with the full attack feasibility. The paper should distinguish between 'wallets vulnerable to this vector' and 'users realistically exploitable' more clearly in the summary table.
  3. §3.3.4: The automated interaction procedure (randomly clicking up to 10 UI elements or running for 60 seconds) is the basis for all network-side measurements. The paper does not validate that this procedure triggers representative RPC traffic. For Threat #1, the timing correlation signal depends on the wallet issuing multi-address RPC requests within the test window; if the random-clicking routine does not trigger balance refresh or similar operations, the measured linkability rates could be artificially low (or high, if the routine triggers unusual batched queries). The paper should discuss this limitation and, ideally, provide a sensitivity analysis or comparison with a scripted dApp-interaction scenario.
minor comments (7)
  1. Table 2: The legend explains • and ◦ symbols, but the 'Analytics embedded' column for MetaMask shows ◦ while the 'Addr. to Analytics' column shows •, which is confusing since metamask.io is listed as a recipient. Clarify whether metamask.io is classified as an analytics domain or a vendor backend.
  2. §5.6.2: The text states '22 (61.1%) did not correctly implement permission revocation' and then 'The remaining 14 wallets successfully removed the permission entry.' 22 + 14 = 36, which is consistent, but the sentence structure implies 14 is a subset of the 22. Reword for clarity.
  3. Table 3 caption: 'Revocation unsafe' is defined in the footnote, but 'Error returned?' column uses '–' and 'Not supported' without fully explaining the distinction. Some wallets marked 'Not supported' are also marked revocation-unsafe (•), while others with '–' are also marked •. Clarify the relationship between returning an error and being revocation-unsafe.
  4. §5.5, Figure 4: The figure caption says 'tracker T on websiteA.com embeds an invisible iframe of dappX.com.' It would help to explicitly state in the figure or caption that the tracker inside the iframe runs with dappX.com's origin, as this is the key insight enabling the attack.
  5. §6, Web-Threats #2–#3: The proposed 'script-level access-controlled localStorage' mitigation is interesting but described only at a high level. A brief note on how the JavaScript stack inspection would handle indirect calls (e.g., via eval or dynamic imports) would strengthen the discussion.
  6. References [7] and [8] are cited to support the claim that many crypto users manage multiple wallets. These are industry reports with 'Version: 24.39.1' noted, which is unusual. Verify these are stable, citable sources or replace with peer-reviewed alternatives.
  7. §4.3.3: The 10ms timing correlation window is used as a threshold but its choice is not justified. A brief rationale or sensitivity note would help.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the thorough and constructive review. The referee raises three major comments, all of which are valid and actionable. We agree with all three and will revise the manuscript accordingly. Below we address each point in turn.

read point-by-point responses

  1. Referee: §4.3.3 and Table 6: The headline user-impact figure for Threat #1 (65.4%, 23.0M users) is computed by summing CWS user counts for all 17 wallets exhibiting co-occurrence or timing correlation signals, divided by the total user base. However, this threat only applies to users who maintain multiple addresses in the same wallet. The paper tests with 3 accounts per wallet but does not measure or estimate what fraction of real users actually use multiple addresses. Single-address users of these 17 wallets are included in the 23.0M figure despite having no addresses to link. The paper should either (a) explicitly caveat this figure as an upper bound conditional on multi-address usage, or (b) provide an estimate of multi-address user prevalence.

    Authors: The referee is correct. The 65.4% figure represents the fraction of users whose wallets exhibit the linkability signal, not the fraction of users who are definitively exploitable, since the attack requires the user to maintain multiple addresses within the same wallet. We do not currently have an empirical estimate of multi-address user prevalence, and we agree that presenting 23.0M as the population at risk without this caveat overstates the impact. In the revision, we will explicitly label this figure as an upper bound in Table 6, in §4.3.3, and in the abstract. We will add a clarifying sentence stating that the figure represents the maximum potential exposure—i.e., the fraction of users whose wallets produce linkability signals, conditional on the user maintaining multiple addresses—and note that the actual exploitable population depends on multi-address adoption rates, which we do not measure. We will also discuss this as a limitation in the methodology section. revision: yes

  2. Referee: §5.6.5 and Table 6: The 78.95% figure for Threat #4 represents the fraction of users whose wallets expose provider interfaces in cross-origin iframes (23/36 wallets). However, the full attack chain (§5.5) requires three additional preconditions: (i) the user previously connected to an iframe-embeddable dApp, (ii) that dApp includes the same tracker as the attacking site, and (iii) the wallet has not revoked the permission. The paper measures iframe embeddability of dApps (18/30) and wallet iframe exposure (23/36) but does not measure the joint probability of these conditions. Table 6 presents 78.95% as the 'ecosystem impact' for Threat #4, which conflates a necessary condition with the full attack feasibility. The paper should distinguish between 'wallets vulnerable to this vector' and 'users realistically exploitable' more clearly in the summary table.

    Authors: We agree. The 78.95% figure captures the fraction of users whose wallets expose the provider in cross-origin iframes—a necessary precondition for the attack—but not the joint probability of all preconditions being met. We will revise Table 6 to distinguish between 'wallets vulnerable to this vector' (23/36, 78.95%) and a more nuanced 'realistic exploitability' assessment. Specifically, we will add a note to Table 6 clarifying that the 78.95% figure represents the population vulnerable to the iframe exposure precondition, and that full exploitation additionally requires (i) prior connection to an iframe-embeddable dApp (18/30 in our sample), (ii) a shared tracker between the attacking site and the embedded dApp, and (iii) unrevoked permissions. We will also add a sentence in §5.6.5 explicitly stating that we measure each precondition independently but not their joint probability, and that the 78.95% figure should be interpreted as an upper bound on the population vulnerable to this vector rather than a precise estimate of the exploited population. revision: yes

  3. Referee: §3.3.4: The automated interaction procedure (randomly clicking up to 10 UI elements or running for 60 seconds) is the basis for all network-side measurements. The paper does not validate that this procedure triggers representative RPC traffic. For Threat #1, the timing correlation signal depends on the wallet issuing multi-address RPC requests within the test window; if the random-clicking routine does not trigger balance refresh or similar operations, the measured linkability rates could be artificially low (or high, if the routine triggers unusual batched queries). The paper should discuss this limitation and, ideally, provide a sensitivity analysis or comparison with a scripted dApp-interaction scenario.

    Authors: The referee raises a valid concern about the ecological validity of the automated interaction procedure. We acknowledge that the random-clicking routine may not trigger the exact same RPC traffic patterns that a real user would generate, and that this could bias the measured linkability rates in either direction. In the revision, we will add a dedicated paragraph in §3.3.4 discussing this limitation explicitly, noting that (i) the procedure may not trigger all balance-refresh or multi-address query patterns, potentially underestimating linkability, and (ii) conversely, the routine could trigger unusual batched queries that overestimate it. We will also note that we verified each wallet displayed correct balances for the funded test accounts (§3.3.3), which confirms that balance-fetching RPC traffic was triggered during the test window for all wallets included in the analysis. Unfortunately, we cannot provide a full sensitivity analysis with a scripted dApp-interaction scenario within the revision timeframe, as this would require designing wallet-specific interaction scripts for 55 multi-account wallets—a substantial engineering effort. We will state this as a limitation and suggest it as future work. revision: partial

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: empirical measurement study with externally defined threats and independently measured data

full rationale

This paper is an empirical measurement study, not a derivation. The five privacy threats are defined independently (Sections 4.2, 5.2–5.5) in terms of observable wallet behaviors (RPC co-occurrence, EIP-6963 discovery, revocation failure, iframe exposure). The measurements are then performed against external datasets: 85 Chrome Web Store wallets, 30 dApps from DappRadar, and a public analytics-domain list. No threat definition reduces to a fitted parameter, and no 'prediction' is equivalent to a fit. The framework builds on Torres et al. [29] (external authors, publicly available code), which the authors transparently reproduce and extend by adding service_worker/background_page interception. Self-citation is minimal: the paper cites prior work by Torres et al. and Winter et al. (both external), and the authors' own prior work is not invoked as a load-bearing premise. The user-impact figures (e.g., 65.4%, 78.95%) are computed by summing Chrome Web Store user counts for wallets exhibiting each measured behavior, which is a straightforward aggregation of independently collected data, not a circular restatement of a definition. The skeptic's concern about unmeasured prerequisites (single-address users, prior dApp connections) is a correctness-risk issue about external validity of the headline numbers, not a circularity issue—no step in the paper's chain reduces to its own inputs by construction.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The paper is an empirical measurement study with no invented entities, new particles, or postulated objects. The free parameters are methodological choices (thresholds, account counts, click limits) rather than fitted constants. The axioms are mostly standard browser security properties and cryptographic assumptions, with one ad-hoc representativeness assumption.

free parameters (4)
  • Timing correlation window = 10ms
    §4.2 defines timing correlation as requests 'sent within a short time window' and §4.3.3 uses 10ms. This threshold is not justified by any analysis of typical RPC request spacing.
  • User count threshold for CWS-10K/85 dataset = 10000
    §3.2.2 states wallets were filtered to those with '>10K users'. This is a reasonable heuristic but excludes less popular wallets that may exhibit different behaviors.
  • Number of test accounts per wallet = 3
    §3.3.4 states 'Each wallet was initiated with three accounts'. The choice of three is not justified; linkability signals may differ with more accounts.
  • Maximum UI clicks during network measurement = 10
    §3.3.4 states the framework 'randomly clicked up to ten UI elements or stopped after sixty seconds'. This is inherited from Torres et al. but its representativeness is not validated.
assumptions (5)
  • domain assumption The adversary can observe plaintext request bodies at TLS termination points (RPC endpoints, wallet backends).
    §4.1 states 'Because these servers receive the decrypted HTTPS request, they have full visibility into the plaintext request body.' This is standard for HTTPS but is the foundation of the network-side threat model.
  • standard math Third-party tracker scripts execute with the same origin privileges as the embedding webpage.
    §5.1 states 'such scripts execute with the same origin privileges as the embedding webpage and can access wallet provider objects exposed to the webpage.' This is standard browser Same-Origin Policy behavior.
  • domain assumption EIP-6963 wallet discovery events are dispatched to all pages without origin restrictions.
    §5.2 assumes any website can dispatch eip6963:requestProvider and receive announcements. This is the current behavior of the standard as implemented.
  • domain assumption Wallet addresses are globally unique and cannot be spoofed without owning the private key.
    §5.3 states 'blockchain addresses are globally unique and cannot be produced in a wallet without owning the private key.' This is a fundamental property of public-key cryptography.
  • ad hoc to paper The 85 wallets in CWS-10K/85 are representative of the broader browser-extension wallet ecosystem.
    §3.2.2 selects wallets with >10K users from three keyword searches. The paper generalizes findings to 'the current Web3 ecosystem' (§4.4, §5.7) but does not validate that this sample is representative of all wallets or all users.

how reviews work

0 comments
Cite this review

Pith. "Pith review of The Masks We (Think We) Wear: Privacy Threats of Browser-Extension Wallets in the Web3 Ecosystem." pith.science (2026). https://pith.science/paper/3RMS5TKA

@misc{pith2026260706141,
  author       = {Pith},
  title        = {Pith review of: The Masks We (Think We) Wear: Privacy Threats of Browser-Extension Wallets in the Web3 Ecosystem},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3RMS5TKA}},
  note         = {Machine review of arXiv:2607.06141}
}
read the original abstract

Cryptocurrency wallets are the primary interface for managing pseudonymous blockchain addresses, viewing balances, and interacting with Web3 applications. Although users typically assume that their addresses remain independent of each other unless intentionally revealed, modern wallets routinely communicate with both blockchain infrastructure and decentralized applications (dApps), generating network-side and web-side signals that may undermine this assumption. In this paper, we identify and formalize five privacy threats that arise directly from wallets interacting with the network and the web browser. Using large-scale dynamic measurements of 85 of the most popular Chrome Web Store browser-extension wallets (representing 35.16 million users), we observe that routine remote procedure call (RPC) operations leak structural links between a user's addresses; that the majority of Ethereum wallets implement permission revocation inconsistently and continue to expose previously revoked addresses across sessions; and that many wallets inject their provider interfaces into cross-origin iframes, enabling passive cross-site tracking beyond dApps and potentially real-world identity deanonymization without user interaction. Taken together, our results show that these wallet behaviors leak sensitive information that can be used to link multiple addresses to the same user, track wallet users across sessions and sites, and connect their browsing activity to their on-chain wealth. We discuss practical mitigations and show that many of these threats can be substantially reduced through improved wallet implementation, stronger privacy considerations in ecosystem standards, and stricter controls over provider exposure. Our results highlight the need for standardized, privacy-preserving wallet architectures.

Figures

Figures reproduced from arXiv: 2607.06141 by the authors.

Figure 1
Figure 1. A wallet’s two roles: financial interfaces (showing [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 3
Figure 3. Cross-site cross-session tracking and wallet-address [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figure 4
Figure 4. A shared third-party tracker on websiteA.com em￾beds an invisible iframe of dappX.com. If the wallet exposes its provider to cross-origin iframes, the tracker inside the iframe can read the user’s previously authorized address and pass it back to the tracker on websiteA.com. The observed address can then be passed from the tracker 𝑇 inside the iframe to the tracker 𝑇 on websiteA.com, allowing it to identify the user… view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: Outcome tree showing which wallets (referenced in [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 44 canonical work pages

  1. [1]

    Shubham Agarwal, Aurore Fass, and Ben Stock. 2024. Peeking through the window: Fingerprinting Browser Extensions through Page-Visible Execution Traces and Interactions. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security(Salt Lake City, UT, USA)(CCS ’24). Association for Computing Machinery, New York, NY, USA, 2117–2...

    work page doi:10.1145/3658644.3670339 2024

  2. [2]

    Elli Androulaki, Ghassan Karame, Marc Roeschlin, Tobias Scherer, and Srdjan Capkun. 2012. Evaluating User Privacy in Bitcoin. Cryptology ePrint Archive, Paper 2012/596. https://eprint.iacr.org/2012/596

    work page 2012

  3. [3]

    Seres, Andras A

    Ferenc Beres, Istvan A. Seres, Andras A. Benczur, and Mikerah Quintyne-Collins

    work page

  4. [4]

    In2021 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS)

    Blockchain is Watching You: Profiling and Deanonymizing Ethereum Users . In2021 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS). IEEE Computer Society, Los Alamitos, CA, USA, 69–78. https://doi.org/10.1109/DAPPS52256.2021.00013

    work page doi:10.1109/dapps52256.2021.00013 2021

  5. [5]

    Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. 2014. Deanonymisa- tion of Clients in Bitcoin P2P Network. InProceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security(Scottsdale, Arizona, USA) (CCS ’14). Association for Computing Machinery, New York, NY, USA, 15–29. https://doi.org/10.1145/2660267.2660379

    work page doi:10.1145/2660267.2660379 2014

  6. [6]

    Alex Biryukov and Sergei Tikhomirov. 2019. Deanonymization and linkability of cryptocurrency transactions based on network analysis. In2019 IEEE European symposium on security and privacy (EuroS&P). IEEE, 172–184

    work page 2019

  7. [7]

    Ting Chen, Yuxiao Zhu, Zihao Li, Jiachi Chen, Xiaoqi Li, Xiapu Luo, Xiaodong Lin, and Xiaosong Zhange. 2018. Understanding Ethereum via Graph Analysis. InIEEE INFOCOM 2018 - IEEE Conference on Computer Communications. IEEE, ., 1484–1492. https://doi.org/10.1109/INFOCOM.2018.8486401

    work page doi:10.1109/infocom.2018.8486401 2018

  8. [8]

    Version: 24.39.1

    CoinLaw. Version: 24.39.1. Web3 Wallet User Growth Statistics 2026: Global Surge Explained. https://coinlaw.io/web3-wallet-user-growth-statistics/. Accessed: 2026-03-13

    work page 2026

Show all 44 references
  1. [9]

    Version: 24.39.1

    Study created by Reown with support and insights from Nansen. Version: 24.39.1. The State of Onchain UX. https://reown.com/onchainux-report

  2. [10]

    DappRadar. 2025. Top Ethereum Dapps – Rankings by Protocol. https://dappradar. com/rankings/protocol/ethereum. Accessed: 2025-11-24

    2025

  3. [11]

    Yimika Erinle, Yathin Kethepalli, Yebo Feng, and Jiahua Xu. 2025. SoK: Design, vulnerabilities, and security measures of cryptocurrency wallets.Computer Networks273 (2025), 111691. https://doi.org/10.1016/j.comnet.2025.111691

    2025 doi

  4. [12]

    Extropy. 2025. The Human Weakness in a Decentralised World: Phishing Attacks and Social Engineering in Web3. https://extropy-io.medium.com/the-human- weakness-in-a-decentralised-world-phishing-attacks-and-social-engineering- in-web3-cf76ab19ffdf. Accessed: 2025-02-10

    2025

  5. [13]

    Dan Finlay, Erik Marks, and Gavin John. 2019. EIP-2255: Wallet Permissions System. Ethereum Improvement Proposals (EIPs) no. 2255. https://eips.ethereum. org/EIPS/eip-2255

    2019

  6. [14]

    Chrome for Developers. 2023. Migrate to a service worker. https://developer. chrome.com/docs/extensions/develop/migrate/to-service-workers. Accessed: 2026-03-13

    2023

  7. [15]

    Pedro Gomes, Kosala Hemachandra, Richard Moore, Gregory Markou, Kyle Den Hartog, Glitch, Jake Moxey, Pierre Bertet, Darryl Yeo, and Yaroslav Sergievsky

  8. [16]

    Ethereum Improvement Proposals (EIPs) no

    EIP-6963: Multi Injected Provider Discovery. Ethereum Improvement Proposals (EIPs) no. 6963. https://eips.ethereum.org/EIPS/eip-6963

  9. [17]

    Alejandro Gómez-Boix, Pierre Laperdrix, and Benoit Baudry. 2018. Hiding in the crowd: an analysis of the effectiveness of browser fingerprinting at large scale. InProceedings of the 2018 world wide web conference. 309–318

    2018

  10. [18]

    Shixuan Guan and Kai Li. 2024. Characterizing Ethereum address poisoning attack. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 986–1000

    2024

  11. [19]

    Lioba Heimbach, Yann Vonlanthen, Juan Villacis, Lucianna Kiffer, and Roger Wattenhofer. 2025. Deanonymizing Ethereum Validators: The {P2P} Network Has a Privacy Issue. In34th USENIX Security Symposium (USENIX Security 25). 1319–1338

    2025

  12. [20]

    Sabine Houy, Philipp Schmid, and Alexandre Bartel. 2023. Security Aspects of Cryptocurrency Wallets—A Systematic Literature Review.ACM Comput. Surv. 56, 1, Article 4 (Aug. 2023), 31 pages. https://doi.org/10.1145/3596906

    2023 doi

  13. [21]

    George Kappos, Haaroon Yousaf, Mary Maller, and Sarah Meiklejohn. 2018. An empirical analysis of anonymity in Zcash. InProceedings of the 27th USENIX Conference on Security Symposium(Baltimore, MD, USA)(SEC’18). USENIX Asso- ciation, USA, 463–477

    2018

  14. [22]

    Soroush Karami, Panagiotis Ilia, Konstantinos Solomos, and Jason Polakis. 2020. Carnus: Exploring the Privacy Threats of Browser Extension Fingerprinting.. In In Proceedings of the 27th Network and Distributed System Security Symposium (NDSS)

    2020

  15. [23]

    Maso, Erik Trickel, Panagiotis Ilia, Yan Shoshitaishvili, Adam Doupé, and Jason Polakis

    Soroush Karami, Faezeh Kalantari, Mehrnoosh Zaeifi, Xavier J. Maso, Erik Trickel, Panagiotis Ilia, Yan Shoshitaishvili, Adam Doupé, and Jason Polakis

  16. [24]

    In31st USENIX Security Symposium (USENIX Secu- rity 22)

    Unleash the Simulacrum: Shifting Browser Realities for Robust Extension- Fingerprinting Prevention. In31st USENIX Security Symposium (USENIX Secu- rity 22). USENIX Association, Boston, MA, 735–752. https://www.usenix.org/ conference/usenixsecurity22/presentation/karami

  17. [25]

    Voelker, and Stefan Savage

    Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. 2016. A fistful of Bitcoins: characterizing payments among men with no names.Commun. ACM59, 4 (March 2016), 86–93. https://doi.org/10.1145/2896384

    2016 doi

  18. [26]

    MetaMask Team. 2023. MIP-2: Revoke Permissions. https://github.com/ MetaMask/metamask-improvement-proposals/blob/main/MIPs/mip-2.md. Ac- cessed: 2025-11-24

    2023

  19. [27]

    Nick Nikiforakis, Alexandros Kapravelos, Wouter Joosen, Christopher Kruegel, Frank Piessens, and Giovanni Vigna. 2013. Cookieless Monster: Exploring the Ecosystem of Web-Based Device Fingerprinting. In2013 IEEE Symposium on Security and Privacy. 541–555. https://doi.org/10.110...

    2013 doi

  20. [28]

    2025.𝐶𝑜𝑜𝑘𝑖𝑒𝐺𝑢𝑎𝑟𝑑 : Characterizing and Isolating the First-Party Cookie Jar

    Pouneh Nikkhah Bahrami, Aurore Fass, and Zubair Shafiq. 2025.𝐶𝑜𝑜𝑘𝑖𝑒𝐺𝑢𝑎𝑟𝑑 : Characterizing and Isolating the First-Party Cookie Jar. InProceedings of the 2025 ACM Internet Measurement Conference(USA)(IMC ’25). Association for Computing Machinery, New York, NY, USA, 645–661. htt...

    2025

  21. [29]

    Gaston Pugliese, Christian Riess, Freya Gassmann, and Zinaida Benenson. 2020. Long-term observation on browser fingerprinting: Users’ trackability and per- spective.Proceedings on Privacy Enhancing Technologies(2020)

    2020

  22. [30]

    Version: 24.39.1

    Puppeteer Docs. Version: 24.39.1. Chrome Extensions: Puppeteer can be used for testing Chrome Extensions. https://pptr.dev/guides/chrome-extensions. Ac- cessed: 2026-03-13

    2026

  23. [31]

    Dorit Ron and Adi Shamir. 2013. Quantitative Analysis of the Full Bitcoin Transaction Graph. InFinancial Cryptography and Data Security, Ahmad-Reza Sadeghi (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 6–24

    2013

  24. [32]

    Christof Ferreira Torres, Fiona Willi, and Shweta Shinde. 2023. Is your wallet snitching on you? an analysis on the privacy implications of web3. InProceedings of the 32nd USENIX Conference on Security Symposium(Anaheim, CA, USA)(SEC ’23). USENIX Association, USA, Article 44, 18 pages

    2023

  25. [33]

    Erik Trickel, Oleksii Starov, Alexandros Kapravelos, Nick Nikiforakis, and Adam Doupé. 2019. Everyone is Different: Client-side Diversification for Defending Against Extension Fingerprinting. In28th USENIX Security Symposium (USENIX Security 19). USENIX Association, Santa Clar...

    2019

  26. [34]

    Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, and Romain Rouvoy. 2018. Fp-stalker: Tracking browser fingerprint evolutions. In2018 IEEE Symposium on Security and Privacy (SP). IEEE, 728–741

    2018

  27. [35]

    Friedhelm Victor. 2020. Address Clustering Heuristics for Ethereum. InFinancial Cryptography and Data Security. Springer, Berlin, Heidelberg, 617–633. https: //api.semanticscholar.org/CorpusID:211141493

    2020

  28. [36]

    Fabian Vogelsteller, Ryan Ghods, Victor Maia, Marc Garreau, and Erik Marks

  29. [37]

    Ethereum Improvement Proposals (EIPs) no

    EIP-1193: Ethereum Provider JavaScript API. Ethereum Improvement Proposals (EIPs) no. 1193. https://eips.ethereum.org/EIPS/eip-1193

  30. [38]

    Shan Wang, Ming Yang, Wenxuan Dai, Yu Liu, Yue Zhang, and Xinwen Fu

  31. [39]

    https://api.semanticscholar.org/CorpusID:271868005

    Deanonymizing Ethereum Users behind Third-Party RPC Services.IEEE INFOCOM 2024 - IEEE Conference on Computer Communications(2024), 1701–1710. https://api.semanticscholar.org/CorpusID:271868005

    2024

  32. [40]

    Shan Wang, Ming Yang, Yu Liu, Yue Zhang, Shuaiqing Zhang, Zhen Ling, Jiannong Cao, and Xinwen Fu. 2025. Time Tells All: Deanonymization of Blockchain RPC Users with Zero Transaction Fee. InProceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security(Ta...

    2025 doi

  33. [41]

    Philipp Winter, Anna Harbluk Lorimer, Peter Snyder, and Benjamin Livshits

  34. [42]

    arXiv:2109.06836 [cs.CR] https://arxiv.org/abs/2109.06836

    Security, Privacy, and Decentralization in Web3. arXiv:2109.06836 [cs.CR] https://arxiv.org/abs/2109.06836

    arXiv

  35. [43]

    Pengcheng Xia, Yanhui Guo, Zhaowen Lin, Jun Wu, Pengbo Duan, Ningyu He, Kailong Wang, Tianming Liu, Yinliang Yue, Guoai Xu, and Haoyu Wang. 2024. WalletRadar: towards automating the detection of vulnerabilities in browser- based cryptocurrency wallets.Automated Software Engine...

    2024 doi

  36. [44]

    Kailun Yan, Jilian Zhang, Xiangyu Liu, Wenrui Diao, and Shanqing Guo. 2023. Bad Apples: Understanding the Centralized Security Risks in Decentralized Ecosys- tems. InProceedings of the ACM Web Conference 2023(Austin, TX, USA)(WWW ’23). Association for Computing Machinery, New ...

    2023 doi

Pith tools

Reviewed July 8, 2026 · model on record in the stance chip above.