Time Tells All: Deanonymization of Blockchain RPC Users with Zero Transaction Fee (Extended Version)

TL;DR

This paper introduces a novel, zero-cost deanonymization attack on blockchain RPC users that links IP addresses to blockchain pseudonyms by exploiting temporal correlations in network traffic and transaction data.

Contribution

It presents a new attack method that does not require transaction fees or active network eavesdropping, and validates its effectiveness through large-scale measurements and real-world experiments.

Findings

Achieves over 95% success rate in deanonymization

Effective across multiple blockchain networks including Ethereum, Bitcoin, and Solana

Relies on temporal correlation between network traffic and blockchain transactions

Abstract

Remote Procedure Call (RPC) services have become a primary gateway for users to access public blockchains. While they offer significant convenience, RPC services also introduce critical privacy challenges that remain insufficiently examined. Existing deanonymization attacks either do not apply to blockchain RPC users or incur costs like transaction fees assuming an active network eavesdropper. In this paper, we propose a novel deanonymization attack that can link an IP address of a RPC user to this user's blockchain pseudonym. Our analysis reveals a temporal correlation between the timestamps of transaction confirmations recorded on the public ledger and those of TCP packets sent by the victim when querying transaction status. We assume a strong passive adversary with access to network infrastructure, capable of monitoring traffic at network border routers or Internet exchange points. By monitoring network traffic and analyzing public ledgers, the attacker can link the IP address of the TCP packet to the pseudonym of the transaction initiator by exploiting the temporal correlation. This deanonymization attack incurs zero transaction fee. We mathematically model and analyze the attack method, perform large-scale measurements of blockchain ledgers, and conduct real-world attacks to validate the attack. Our attack achieves a high success rate of over 95% against normal RPC users on various blockchain networks, including Ethereum, Bitcoin and Solana.

Tables

Table 1. Table 1. Blockchain-based cryptocurrency wallets

Wallet	Year	Country	Users	Block- chain	Multi- Curr.	Standard RPC Prot.	Open Source	Sup. Testnet
MetaMask	2016	USA	30 M+	ETH	$\times$	$✓$	$✓$	$✓$
Enkrypt	2015	USA	3 M+		$✓$	$✓$	$✓$	$✓$
Taho	2021	USA	70 K+		$✓$	$✓$	$✓$	$✓$
[2pt/2pt] Electrum	2011	Germany	1 M+	BTC	$\times$	$✓$	$✓$	$✓$
Green	2016	Canada	100 K+		$\times$	$✓$	$✓$	$✓$
Sparrow	2020	South Africa	N/A		$\times$	$✓$	$✓$	$✓$
[2pt/2pt] Phantom	2020	USA	3 M+	SOL	$\times$	$✓$	$\times$	$✓$
Solflare	2020	USA	2 M+		$\times$	$✓$	$\times$	$✓$
Torus	2019	Singapore	1 M+		$✓$	$✓$	$✓$	$✓$

Table 2. Table 2. TCP packet sizes considering practical API usage in wallets. ( MetaMask relies on the RPC service Infura and adopts HTTP/2. Electrum relies on service Blockstream and adopts Websocket. The details on Solana are presented in Appendix A

Block- chain	Num. of APIs	Target RPC API	Wallet	TCP Segment Size		Overlapped APIs in Theory	TCP Segment Size
				Request	Response		Request	Response
Ethereum	44	eth_getTransaction Receipt	MetaMask	193-194	$\ge$1061	eth_getBlockByHash	192-193	$\ge$1437
[2pt/2pt]						eth_getTransactionByBlockHash	Without Overlap	Without Overlap
						eth_getTransactionByHash
						eth_getUncleByBlockHashAndIndex
[2pt/2pt]						eth_getProof, eth_createAccessList, eth_feeHistory, eth_getFilterLogs, eth_getLogs	Unused	Unused
Bitcoin	29	blockchain.transaction .get_merkle	Electrum	172-182	$\ge$167	blockchain.scripthash.get_history	170-174	$\ge$148
						blockchain.scripthash.listunspent	170-174	$\ge$59
[2pt/2pt]						blockchain.transaction.get	w/o overlap	w/o overlap
[2pt/2pt]						blockchain.scripthash.get_mempool	Unused	Unused

Table 3. Table 3. Numerical success rate across blockchains

Blockchain	Number of Attack Rounds	Testnet		Mainnet
[2pt/2pt]		$\alpha$ = 0.99	$\alpha$ = 1.00	$\alpha$ = 0.99	$\alpha$ = 1.00
Ethereum	m=3	96.97%	99.94%	95.61%	98.53%
Bitcoin	m=4	93.88%	97.73%	95.98%	99.92%
Solana	m=4	95.32%	99.23%	90.16%	93.86%

Table 4. Table 4. Proportion of target transactions included in k k blocks

Blockchain	Wallet	Periodic Q.	Sub. Notif.	k=1	k=2	k=3
Ethereum	MetaMask	20s	$\times$	63.30%	99.48%	99.69%
	Enkrypt	10s	$\times$	98.98%	100%	100%
	Taho	2s	$\times$	99.49%	99.49%	100%
[3pt/3pt] Bitcoin	Electrum	$\times$	$✓$	99.85%	100%	100%
	Green	$\times$	$✓$	100%	100%	100%
	Sparrow	$\times$	$✓$	99.59%	100%	100%
Blockchain	Wallet	Periodic Q.	Sub. Notif.	k=40	k=50	k=60
Solana	Torus	10s	$\times$	76.13%	93.62%	99.78%
	Phantom	0.5s	$\times$	97.72%	97.72%	98.48%
	Solflare	1s	$\times$	97.91%	97.91%	98.95%

Table 5. Table 5. Success rate of TRAP attack across different wallets

Ethereum			Bitcoin			Solana
[2pt/2pt] MetaMask	Enkrypt	Taho	Electrum	Green	Sparrow	Torus	Phantom	Solflare
96.80%	95.83%	94.40%	97.70%	96.85%	97.95%	96.58%	96.42%	95.62%

Table 6. Table 6. TCP segment size ranges considering practical API usage in the Solana wallet named Torus . The RPC service is QuickNode , the protocol is HTTP/2, and the target API is getSignatureStatuses .

Target TCP Size		Overlapped APIs in Theory	Noise TCP Size
Request	Response		Request	Response
262	266-269

Equations

$$⟨$$

$$d_{2r+2},t_{2r+2})⟩$$

$$\text{vskip}-2.84526ptk=\lceil \frac{y+RTT}{z}\rceil ,$$

$$\text{vskip}-2.84526ptk=\lceil \frac{2RTT}{z}\rceil ,$$

$${\mathcal{S}}_i={\mathcal{S}}_i\cap {\mathcal{S}}_{i-1},$$

$$P=P_t\cdot P_{t^{\prime }},$$

$$P_t={\alpha }^m.$$

$$f_i=1-{\prod }_{j=2}^m(1-(1-p_i{)}^{x_j}),$$

$$\text{vskip}-2.84526pt{P}_{t^{\prime }}={\prod }_{i=1,i\ne t}^n{f}_i,$$

$$\text{vskip}-2.84526ptP={\alpha }^m{\prod }_{i=1,i\ne t}^n\left(1-{\prod }_{j=2}^m(1-(1-p_i{)}^{x_j})\right).$$

$$P(X_i\ge 1)=1-e^{-{\lambda }_{i}kT},$$

$$y_j=1-(1-p_i{)}^{x_j}.$$

$$f_i$$

$$F(f_i=\widetilde{f_i},m=\tilde{m})=\sum _{⟨\tilde{p},\tilde{x}⟩\in \mathcal{D}}F(\tilde{p})F(\tilde{x}),$$

$$\mathbb{E}[f_i]=\sum _{f_i\in \mathcal{M}}{f}_i\cdot F(f_i).$$

$$F(P=\tilde{P},\alpha =\tilde{\alpha },m=\tilde{m})=\sum _{⟨\tilde{p},\tilde{x},\tilde{n}⟩\in \mathcal{C}}F(\tilde{p})F(\tilde{x})F(\tilde{n}),$$

$$\mathbb{E}[P]=\sum _{P\in \mathcal{N}}P\cdot F(P),$$

Full text

Blockchain; RPC service; Wallet; Deanonymization attack

1. Introduction

Remote Procedure Call (RPC) protocols and services have become a primary gateway for users to access blockchain networks. Wallet applications such as browser plug-ins rely on RPC services for easy development and seamless interaction with blockchains. This allows a blockchain user to transact effortlessly through lightweight wallets on their personal devices with no need of running a full blockchain node. Ethereum pioneered the use of blockchain RPC services, with Bitcoin and newer blockchains such as Solana following suit. For instance, the most popular Ethereum wallet MetaMask relies exclusively on the RPC service, Infura, for blockchain access (Infura, 2022).

Despite various deanonymization attacks against blockchains, anonymity of blockchain RPC users remains insufficiently examined. (i) Some works aim to cluster blockchain addresses belonging to the same user (Zhao and Guan, 2015; Zheng et al., 2020; Remy et al., 2018; Meiklejohn et al., 2013), which cannot reveal users’ real-world identities. (ii) Existing deanonymization methods typically link a transaction, along with its initiator’s pseudonym, to the IP address of a blockchain node that firstly broadcasts the transaction to the network (Biryukov and Tikhomirov, 2019a, b; Gao et al., 2021; Koshy et al., 2014; Shen et al., 2020; Zheng et al., 2023). This type of attack typically requires the attacker to establish a super node that connects to almost all blockchain nodes. However, RPC users’ personal devices operate off-chain, with RPC service nodes acting as intermediaries that broadcast transactions and synchronize the ledger on their behalf. As a result, this type of work cannot reveal the IP address of RPC users’ personal devices. (iii) Most existing attacks exploiting blockchain RPC services do not focus on compromising user anonymity (Li et al., 2021a, b; Hara et al., 2020; Kim and Hwang, 2023). The only prior study on deanonymization of Ethereum RPC users assumes an active network adversary capable of both persistently eavesdropping on and injecting RPC traffic via routers (Wang et al., 2024). The injected traffic is used to send transactions through the same router as the victim, enabling estimation of the victim’s transaction propagation timing. However, this active attack incurs transaction fees as well as makes it more likely to be detected. Moreover, this work (Wang et al., 2024) falls short of exposing widespread flaws in user anonymity across various blockchains and wallets.

We assume a passive adversary with access to network infrastructure, capable of monitoring traffic at network border routers or Internet exchange points. This threat model is stronger than those typically used in prior blockchain research. For example, front-running attacks (Eskandari et al., 2019), DoS attacks (Li et al., 2021a), Eclipse attacks (Heilman et al., 2015), flash loan attacks (Gan et al., 2022), and deanonymization via super nodes (Biryukov and Tikhomirov, 2019a, b; Gao et al., 2021; Koshy et al., 2014; Shen et al., 2020; Zheng et al., 2023) generally assume malicious behavior from ordinary nodes or users. In contrast, the adversary in our model possesses capabilities far beyond those of typical blockchain participants. That said, this paper addresses a less studied problem, with only one prior work (Wang et al., 2024) directly targeting it. Our threat model is justified by its established use in anonymity research and real-world examples, such as certain countries blocking Tor at border routers (Lopes et al., 2024).

This paper fills the gap: deanonymizing RPC users across various blockchains without incurring any transaction fee, under a passive network eavesdropping model. We identify a temporal correlation vulnerability in the widely deployed ”wallet—RPC service—blockchain network” interaction paradigm. While processing a transaction, the RPC service responds to the transaction status query by a wallet shortly after the transaction is confirmed by the ledger. We call the timestamp of such a RPC response as transaction query timestamp $\mathcal{T}_{q}$ and denote the transaction confirmation timestamp as $\mathcal{T}_{c}$. An attacker may infer $\mathcal{T}_{q}$ through monitoring and analyzing encrypted the network traffic between a wallet at a monitored IP address and its associated RPC service. Therefore, the attacker can estimate $\mathcal{T}_{c}=\mathcal{T}_{q}-I_{c,q}$, where $I_{c,q}$ is the interval between these two timestamps and can be derived via analyzing wallet codes or network traffic. By searching the ledger for transactions confirmed around the estimated timestamp $\mathcal{T}_{c}$, the attacker obtains the pseudonyms in the transactions and can then link the monitored IP address to those pseudonyms. Such a passive way of deanonymization does not incur any transaction fee.

Although the RPC-based communication paradigm exposes temporal correlation vulnerability and opens a new attack surface, linking a RPC user’s IP address to a unique pseudonym for deanonymization presents grave challenges. First, encrypted TCP packets in RPC protocol complicate the identification of a specific transacting behavior such as status query and its timestamp $\mathcal{T}_{q}$. Second, design diversities across different blockchains, RPC protocols, and wallets pose significant challenges to estimate a reliable $I_{c,q}$. Finally, the derived transaction confirmation timestamp $\mathcal{T}_{c}=\mathcal{T}_{q}-I_{c,q}$ is a rough estimation, and may correspond to quite many transactions and pseudonyms, thereby concealing the target. The attacker can link the monitored IP of a wallet user to a set of pseudonyms, but may be unable to uniquely identify the target.

To solve these challenges, we propose a novel deanonymization attack method named Timestamp Reveals Associated Pseudonym (TRAP), which aims to uniquely link an IP address of a RPC user to its pseudonym. (i) By carefully analyzing RPC API calls along with the sizes and sequences of TCP packets generated by these calls in wallets, we design a machine learning model that leverages TCP packet size and sequence features to accurately detect $\mathcal{T}_{q}$. (ii) Thanks to wallet design philosophy for good user experience, a wallet typically queries transaction status automatically and promptly without user intervention to provide timely feedback to users. This allows the attacker to estimate an upper bound of the interval $I_{c,q}$ (which is short and spans only a few blocks) and derive the range of transaction confirmation timestamp $\mathcal{T}_{c}$. (iii) By searching ledgers based on the estimated $\mathcal{T}_{c}$, the attacker can obtain a set of candidate pseudonyms. To uniquely identify the target, the attacker conducts multiple rounds of traffic and ledger analysis against the same IP address and each round generates a candidate set. Intersecting these sets may reveal the target.

We mathematically model the attack, conduct large-scale measurements on blockchain ledgers and perform real-world attacks to analyze and validate the TRAP attack across various blockchains including Ethereum, Bitcoin and Solana. We classify users who transact infrequently based on a threshold as normal users, who represent the overwhelming majority of all users (e.g., 99.97% in Ethereum). We find if a normal RPC user performs $3$ or $4$ transactions with their wallet at a monitored IP address, the success rate of uniquely identifying the user’s pseudonym can reach up to $96.80\%$ in Ethereum testnet, $95.33\%$ in Ethereum mainnet, $97.70\%$ in Bitcoin testnet and $96.58\%$ in Solana testnet. Furthermore, our results demonstrate that TRAP is universally effective across diverse open-source or closed-source wallets. The success rate remains consistently high for attackers located in different cities or countries, regardless of their geographic distance from the victim.

Attack impact. Our findings demonstrate that, an abusive entity—such as a big brother—can deanonymize public blockchain users simply by monitoring network traffic, without any cooperation from blockchains, wallets, or RPC services, with zero transaction fee and in a stealthy manner. TRAP potentially exposes cryptocurrency users to unexpected censorship. Moreover, tens of millions of users use RPC services to send trillions of transactions (Infura, 2022). Targeting RPC users has a widespread impact.

Responsible disclosure. We have reported our findings in this paper to 12 affected vendors, including 3 blockchains and their 9 wallets. 10 of them have acknowledged the vulnerability, including 7 who have confirmed the attack and 3 who are investigating the issue. 2 vendors have not yet responded. Notably, the Bitcoin RPC protocol designer Electrum (also a wallet vendor) assigned CVE-2025-43968 to this issue, and awarded us a bug bounty of $5,000. The Ethereum Foundation awarded us an academic grant on the attack and protocol-level countermeasures (No. FY25-2131). Moreover, 3 vendors are collaborating with us on the countermeasures, and/or driving changes at other relevant vendors to address the issues more broadly. More details can be found in Appendix G.

Ethical considerations. Our research adheres to the principles outlined in the Menlo Report (Bailey et al., 2012). We only consider a passive attacker who monitors network packets from a victim user. The attacker will not interfere with normal operations of blockchain networks. Our statistics are calculated based on public ledgers. In our evaluation experiments, we strictly log only the network traffic associated with our own devices/IPs with informed consent, ensuring that no data is collected from unaware users/IPs. Additionally, the transactions generated during our experiments are designed to emulate the transacting patterns and rates observed in public blockchain ledgers. This approach ensures that our experiments do not place any noticeable load on the RPC services or blockchain networks under study.

2. Background

2.1. Blockchain Ledgers and Wallet Applications

Public blockchain ledgers. Public blockchain ledgers record transactions in a sequence of append-only blocks. Once a transaction is packaged into a block and confirmed by the blockchain network, it is permanently stored in the ledger, accessible to all at any time. Different blockchains usually adopt unique consensus protocols, leading to distinct block time (the period of generating and confirming a new block). Although each public blockchain features distinct attributes, blocks in their ledgers exhibit some common fields, such as a collection of transactions and a timestamp marking the confirmation time of these transactions. Each transaction includes a blockchain address of its initiator user, which is derived from the user’s public key and acts as a pseudonym, enhancing user anonymity.

Wallet applications. Public blockchain ledgers serve as a foundational decentralization technology for various applications, particularly supporting the development and operation of cryptocurrency wallets. These wallets leverage the blockchain to perform critical functions such as validating and recording transactions and tracking balances. Currently, a wallet typically relies on blockchain RPC services to enable easy development without deploying a blockchain full node. This has prompted the emergence of multiple types of wallet applications. They can be browser plug-ins like MetaMask, which provides access to Ethereum; desktop applications such as Electrum, which is used for Bitcoin transactions; or websites like Torus, which facilitates interactions with Solana. Table 1 provides a short review of various blockchain-based wallets. It is evident that these wallets enjoy significant popularity.

2.2. Blockchain RPC Protocol

RPC-based blockchain communication paradigm. The RPC protocols and services have reshaped the communication paradigm in the blockchain ecosystem, as they provide a lightweight way for users to access blockchain networks. As shown in Figure 1, users manage their cryptocurrencies using wallets on their personal devices. These wallets depend on RPC services to seamlessly access blockchain networks. A RPC service provider operates multiple full nodes for ledger synchronization and exposes standardized RPC APIs that enable clients to submit transactions and retrieve ledger data. Wallets interact with these APIs by sending RPC requests and receiving corresponding responses. Communication between wallets and RPC services follows the JSON-RPC protocol over TLS, ensuring data integrity and confidentiality. Additionally, wallets may interact with their own servers for routine maintenance such as updates, using TLS-secured communications.

RPC protocol specification. A blockchain RPC service typically employs the JSON-RPC protocol to facilitate the communication between a client and a RPC server. The client sends a RPC request to call a specific RPC API associated with a function on a remote RPC server, and the server responds with the results of the function execution. Each pair of request and response is meticulously structured in JSON, detailing the remote functions, their parameters, and the function execution results. Specifically, the request JSON object includes four key-value pairs, such as ”jsonrpc” indicating the protocol version, ”method ” indicating the function to be called, ”params” containing parameters and ”id ” uniquely identifying this request. The response JSON object includes ”jsonrpc”, ”id ”, and ”result” detailing the execution outcomes.

Format and layout of RPC network packets. JSON-RPC protocol (or Blockchain RPC Protocol) runs atop a set of low-level network protocols, as shown in Figure 2. It employs the standard TCP/IP protocol, where each connection between a client and a server is uniquely identified by a quadruple of $\langle$source IP, source port, destination IP, destination port$\rangle$. To safeguard the data transmission, the TLS protocol is adopted to encrypt the TCP data. At the application layer, HTTP protocol or Websocket protocol is employed, with a Header and a Body that encapsulates the actual application content. Central to the HTTP/Websocket body is the RPC JSON object, which holds the actual RPC request or response details.

3. TRAP Attack Overview

This section covers the motivation (§3.1), threat model (§3.2), the basic idea (§3.3), challenges and methodology of the attack (§3.4).

3.1. Motivation

Existing work largely overlooks the critical risks to user anonymity arising from the new communication paradigm reshaped by RPC protocols and services. Existing deanonymization methods typically rely on a super node to link a transaction, along with its initiator’s pseudonym, to the IP address of a blockchain node that firstly broadcasts the transaction to the network (Biryukov and Tikhomirov, 2019a, b; Gao et al., 2021; Koshy et al., 2014; Shen et al., 2020; Zheng et al., 2023).

However, in the context of blockchain RPC services as illustrated in Figure 1, users’ personal devices operate off-chain and behind the RPC service. It is the RPC service nodes, rather than the users’ personal devices, that first broadcast users’ transactions and thus are the targets of these attacks. Consequently, such approaches cannot uncover the real-world identities of RPC users. Most existing attacks exploiting blockchain RPC services do not focus on compromising user anonymity (Li et al., 2021a, b; Hara et al., 2020; Kim and Hwang, 2023). The only prior study on deanonymization of Ethereum RPC users relies on an active network attacker capable of eavesdropping on and injecting traffic via network devices to observe the RPC users’ IPs and link them to pseudonyms. However, it incurs the cost of transaction fees and falls short of exposing widespread flaws in user anonymity across diverse blockchain networks (Wang et al., 2024).

Our work fills the gap: deanonymizing RPC users across various blockchains without incurring any transaction fees under a passive network eavesdropping model, thereby highlighting the severe and widespread risks to blockchain privacy concerning RPC protocols and services. Specifically, we propose the TRAP attack which aims to link a RPC user’s pseudonym, i.e., its blockchain address, to the IP address of the user’s personal device (which may reveal the victim user’s real-world identity), across mainstream blockchains including Ethereum, Bitcoin and Solana, in a passive way and without transaction fees. This kind of passive and zero-cost attack represents an advanced threat model, as the attacker can compromise blockchain users stealthily and without encountering economic constraints.

3.2. Threat Model

In our threat model, illustrated in Figure 3, the attacker passively observes network traffic between the victim users’ devices and RPC services, via a network device such as a router along the traffic routing path across cities and countries. An attacker may locate in different region from victims and RPC services. The attacker collects only the metadata of TCP packets such as the quadruple of $\langle$source IP, source port, destination IP, destination port$\rangle$, timestamps and sizes, which are always unencrypted. The actual packet contents are encrypted by TLS and remain inaccessible to the attacker. The attacker can monitor multiple users simultaneously, as the quadruple can uniquely identify a network connection between a wallet application and a RPC service, allowing for the categorization of packets associated with different wallet users and their RPC services. Potential actors in this scenario include network router owners, internet service providers (ISPs), or regulatory government bodies (big brothers), with network monitoring capabilities via port mirroring or optical splitters (Esmail and Fathallah, 2012). This is a common threat model in network attacks (Ling et al., 2019; Shen et al., 2023; Tran et al., 2020; Lopes et al., 2024). Furthermore, the attacker can access public ledger data from blockchain networks, a capability available to anyone.

In our context, the adversary does not need to identify or control the full routing path between users and RPC services. If the adversary (e.g., an ISP) has access to the network topology and infrastructure, it can monitor traffic at key chokepoints such as border routers or exchange points, where traffic enters or exits the network of interest. An enterprise can monitor its users via internal switches or border routers. Governments can surveil citizens by monitoring national border routers. The computational cost of monitoring traffic at a router depends on inspection depth and traffic volume. In our case, the adversary only needs to capture traffic for specific IPs without deep inspection, enabling low-cost collection with offline analysis.

Our attack is effective against both open-source and closed-source wallets, as the attacker infers wallet behaviors from network traffic. To rigorously examine wallet behaviors and identify root causes, this paper will concentrate on analysis of open-source wallets for establishing a theoretical foundation.

3.3. Basic Idea

In the ”wallet—RPC service—blockchain network” interaction paradigm, processing a single transaction involves coordinated actions and multiple rounds of interactions among these three entities. As illustrated in Figure 4, when a user issues a transaction (TX) through their wallet, the wallet first sends it to the RPC service, which then broadcasts the transaction to the blockchain network. Later, at time $\mathcal{T}_{c}$ (called transaction confirmation timestamp), the transaction is confirmed by the ledger and replicated across blockchain nodes including those of the RPC service, following a consensus protocol. Subsequently, the wallet interacts with the RPC service to query the transaction status and receives the response at time $\mathcal{T}_{q}$ (called transaction query timestamp), allowing it to verify the transaction’s validity and provide feedback to the user. The interval $I_{c,q}=\mathcal{T}_{q}-\mathcal{T}_{c}$.

If an attacker can monitor encrypted network traffic between a wallet at a monitored IP address and its RPC service, and is able to infer the fact of transacting and derive $\mathcal{T}_{q}$, the anonymity of the wallet user will be in grave danger. A transaction in public ledgers reveals its confirmation timestamp and its initiator’s pseudonym (denoted as $s_{t}$). When the attacker obtains $\mathcal{T}_{q}$ through traffic analysis, they may derive the transaction confirmation timestamp $\mathcal{T}_{c}=\mathcal{T}_{q}-I_{c,q}$ by estimating $I_{c,q}$. It then searches the ledger for transactions confirmed around $\mathcal{T}_{c}$ and obtains the pseudonyms in the transactions. Therefore, the attacker can link the monitored IP address with those pseudonyms. Such a passive way of deanonymization does not incur any transaction fee.

3.4. Challenges and Methodology

The basic idea of deanonymization above faces grand challenges.

(C-I) Traffic analysis for the fact of transacting and $\mathcal{T}_{q}$. The TCP traffic between the wallet and the RPC service is encrypted using TLS, preventing the attacker from inferring what is going on between them. Only metadata, such as IP addresses, packet sizes, and timestamps, is observable. Furthermore, a blockchain RPC protocol typically offers tens of APIs of a wide range of functionalities, which facilitate diverse interactions between a wallet and its RPC service, highly concealing the RPC response packet for a transaction status query by the wallet.

(S-I) Identifying $\mathcal{T}_{q}$ via TCP packet size and sequence (§4). Through systematic analysis of the RPC protocols and wallet business logic, we find that the TCP packet size and sequence features can effectively facilitate the identification of a specific TCP packet that carries $\mathcal{T}_{q}$ of the target RPC response. First, each RPC API has unique parameters and return values, producing RPC-JSON objects of distinct sizes that cause variations in TCP packet sizes. Second, wallets often use a limited set of APIs, narrowing down the candidates. Third, the fixed wallet business logic results in relatively consistent and distinct packet sequences surrounding the target. Together, these features enable accurate detection of the RPC response of interest, which is generated by the transaction status query API call, along with its timestamp.

(C-II) Estimating $I_{c,q}$ to derive $\mathcal{T}_{c}$. As shown in Figure 4, during the interval $I_{c,q}$, significant activities occur among the wallet, RPC service and blockchain system, which may affect $I_{c,q}$. Each blockchain employs its own consensus protocol, which dictates the time required to confirm a transaction in a block. RPC protocols expose different sets of functionalities across blockchains. Wallets differ in how they manage transactions, such as querying for transaction status. These variations complicate the estimation of a reliable $I_{c,q}$ with a universal and effective approach.

(S-II) Exploiting wallet design to estimate $I_{c,q}$ (§5). To provide users with feedback on transaction status, a wallet must rely on RPC services to query this information as it does not synchronize the ledger like blockchain full nodes. For a good user experience, wallets perform these queries automatically and promptly, via either periodic queries or notification subscriptions. Such a wallet design philosophy of efficiency allows a reliable estimation of the upper bound of $I_{c,q}$, which spans only a few blocks (denoted as $k$ blocks). This indicates that the timestamp $\mathcal{T}_{c}$ precedes $\mathcal{T}_{q}$ by no more than $k$ consecutive blocks.

(C-III) Ledger analysis for the identification of the pseudonym making the observed transaction. $\mathcal{T}_{c}$ is a rough estimate, which is within $k$ consecutive blocks away from $\mathcal{T}_{q}$. Hundreds of thousands of users conduct millions of transactions daily, potentially appearing in the $k$ blocks alongside the target in a random way. By retrieving the ledger, the attacker can link the monitored IP address with a set of transactions and their pseudonyms, including the target one, within the $k$ blocks. However, uniquely and accurately pinpointing the target pseudonym responsible for the observed transaction remains challenging.

(S-III) Uniquely identify the target pseudonym via rounds of intersection (§6). We propose uniquely identifying the target pseudonym via multiple (denoted as $m$) rounds of traffic and ledger analysis. In each round of the attack, where a transaction is detected by the attacker, it obtains a candidate set $\mathcal{S}_{i}$ which includes pseudonyms of all transactions within the selected $k$ blocks. The target (called $s_{t}$) is always in $\mathcal{S}_{i}$. The attacker then performs the intersection of the $m$ candidate sets: $\mathcal{S}_{m}=\bigcap_{i=1}^{m}\mathcal{S}_{i}$. The target user will be in the intersection $\mathcal{S}_{m}$. We find most blockchain users, referred to as normal users, transact very infrequently. After a few attack rounds (such as $m=3$), the chance that their pseudonyms show up in $\mathcal{S}_{m}$ along with the target $s_{t}$ is extremely small. Active users do exist and show up with $s_{t}$. We design an efficient filtering strategy to reduce active users’ influence so as to uniquely identify the target normal user. If the target is an active user, the cardinality $|\mathcal{S}_{m}|$ of the intersection is not 1, and the target cannot be uniquely identified while we find $|\mathcal{S}_{m}|$ is small in this case.

4. Deriving Transaction Query Timestamp $\mathcal{T}_{q}$

This section presents the detailed solution (S-I), the traffic analysis method for deriving the transaction query timestamp $\mathcal{T}_{q}$ and linking $\mathcal{T}_{q}$ to the IP address of a wallet user.

4.1. Identify RPC Related TCP Packets

An attacker may observe multiple traffic flows simultaneously but can identify RPC packets by inspecting IPs and domain names associated with RPC services. A Blockchain RPC protocol relies on TCP/IP and TLS for secure network transport. Each TCP connection is uniquely identified by a quadruple $\langle$source IP, source port, destination IP, destination port$\rangle$, indicating who is communicating with whom. While different applications on the same device share the same source IP, they build distinct network connections with different service servers at different destination IPs. The RPC service’s IP maps to its domain name, which is either well known or can be extracted from TLS packets. A TLS handshake occurs each time a wallet establishes a TCP connection with a RPC server. During the TLS handshake, the client’s ”Client Hello” message includes the domain name in plaintext, such as ”sepolia.infura.io”, which corresponds to the destination IP. Wallets may also connect to their own servers for routine maintenance, and the attacker can similarly obtain the wallet server’s domain names and IPs. Therefore, by analyzing the IPs and domain names in network packets, a network eavesdropper can identify RPC packets and infer which wallet is interacting with which RPC service and blockchain.

4.2. Identify Packet Candidates via Packet Size

We first analyze and extract size features of TCP packets to identify packet candidates potentially generated by RPC API calls for querying transaction status. A RPC protocol provides tens of APIs supporting diverse functions such as sending transactions, querying ledgers, mining and block validation. The RPC protocols of Ethereum, Bitcoin and Solana define 44 APIs, 29 APIs and 54 APIs, respectively. Among these RPC APIs, one is often used by a client (such as a wallet) to check whether the initiated transaction has been confirmed by the ledger, enabling timely verification of transaction validity and balance updates. For example in Ethereum, the API eth_ getTransactionReceipt is used with a transaction hash as the parameter to query for its status, and the response provides a receipt containing block information that includes this transaction, gas usage, and so on. Nil will be returned for an unconfirmed transaction. The Bitcoin RPC API blockchain.transaction.get_ merkle and Solana RPC API getSignatureStatuses are used by wallets for similar functions.

Each RPC API has distinct semantics, unique parameters, and specific return values. By analyzing the sizes of TCP packets generated by different API calls, we could identify the packet of interest.

(Step-I) Estimating packet size ranges via maximum and minimum sizes of message fields. When a wallet calls a RPC API, the required parameters are organized in a request RPC-JSON object and the corresponding return values are in a response RPC-JSON object. These JSON objects contain fixed fields and predictable values according to the API semantics and RPC protocol format in §2.2. For example, a transaction status query API typically takes a transaction hash as input and returns an object containing status details. Conversely, a transaction sending API accepts a raw transaction as input and returns a transaction hash. Therefore, the size range of a JSON-RPC object can be estimated based on the theoretical minimum and maximum sizes of each field’s value. Figure 5 summarizes the analysis results in Bitcoin. The results for Ethereum and Solana can be found in Figure 20 and Figure 21 in the Appendix. It can be observed that the size ranges of request/response JSON objects generated by an API for transaction status query only overlap with those of a few other APIs. For example, Table 2 shows that the JSON sizes of Bitcoin RPC API blockchain.transaction.get_ merkle overlap with those of only $4$ other APIs.

According to the RPC packet format in Figure 2, the TCP segment contains a TLS header, a HTTP/Websocket header and a HTTP/Websocket body which only carries a RPC JSON object. The size of a TLS header and a HTTP/Websocket header are relatively fixed according to the protocol standards. Consequently, the TCP segment size is mainly decided by the size of RPC JSON object. Therefore, distinguishability in RPC JSON size ranges will lead to distinguishability in the corresponding TCP packets’ sizes.

(Step-II) Narrowing size ranges via heuristics derived from wallet implementation. Several heuristics based on API usage in wallets can further narrow down the candidates of packets carrying the transaction status query result. First, wallets typically do not invoke RPC APIs related to mining or block validation. For example, Ethereum RPC API eth_ getTransactionReceipt theoretically overlaps in size with $9$ APIs, but $5$ out of these $9$ APIs are not used by its wallet MetaMask as shown in Table 2 and will not introduce noise to the identification. Second, the RPC JSON objects generated by a wallet usually occupy a limited subset of their theoretical size ranges, resulting in fewer overlaps. For example, when we calculate the theoretical size ranges, we assume the value of id field is an integer ranging from $1$ byte to $20$ bytes. However, MetaMask only uses a 15-byte or 16-byte random number as the value of the id  field in JSON. Considering the practice, packets generated by the RPC API eth_ getTransactionReceipt potentially overlap in size with those of only one API, for MetaMask. Note: When a wallet calls an API for transaction status, nil will be returned if the transaction has not been confirmed. Our size-based detection result can exclude packets with nil, since their size is small.

With the size-based strategies above, the identified packet candidates may still include noise, leading to false positives.

4.3. Identify Target Packet via Packet Sequence

We find that features in the TCP packet sequence can be leveraged to eliminate false positives. Blockchain wallets typically follow standardized business logic, leading to predictable and relatively consistent sequences of RPC API calls and corresponding TCP packets. For example, before querying a transaction’s status, a wallet usually first calls an API to send the transaction, followed by additional ledger queries to retrieve the latest information. Figure 6 shows the business logic of the Ethereum wallet MetaMask. It first initiates a transaction by calling API eth_ sendRawTransaction. Simultaneously in an asynchronous task, it cyclically calls API eth_ blockNumber to query the latest block number every $20$ seconds. If the block number increases, it queries for the transaction status by calling our target API eth_ getTransactionReceipt, followed by calling eth_ getBlockByHash for verifying the transaction validity. At the same time, it also calls APIs to retrieve the latest block details and the current account balance. Bitcoin and Solana wallets have similar features according to Figure 22 and Figure 23 in the Appendix.

The target API and the noise APIs (those that could have size overlaps with the target) have different contexts in the API call sequence, as they have different functionalities. As shown in Figure 6, the surrounding APIs, invoked before and after, differ for the target and noises. This distinction results in unique TCP packet sequences around the target packet. Consequently, the sequence features can enhance detection accuracy.

Given the asynchronous nature of periodic and other RPC calls, manually defining rules to identify the target packet across multiple patterns would be cumbersome and less effective. Rule-based methods typically struggle with determining an appropriate packet sequence length, weighting features, and handling all possible sequences. Therefore, we adopt a basic ML model to automatically and efficiently learn the data features and rules for performing the identification task better, as discussed and validated in Appendix H. A feature vector as defined in Equation (1) is constructed to represent a sequence of TCP packets, for training a ML model for detection. Specifically, each RPC request is paired with a RPC response, meaning that each API call generates two TCP packets. Assume the middle two TCP packets correspond to the target API. Together with $r$ packets preceding them and $r$ packets following them, these $2r+2$ packets form a complete sequence. Each packet is described by three properties including its packet size $l$, its direction $d$ (request or response) and the inter-arrival time interval $t$ to the former. The feature vector is shown as follows.

[TABLE]

Based on this feature vector, training a basic machine learning model, such as decision tree, support vector machine (SVM), and Random Forest, for binary classification would be sufficient to achieve high detection accuracy.

The attacker uses the trained ML model to classify a sequence of $2r+2$ packets in the form of the feature vector. If the feature vector is classified as a positive instance, the timestamp of the response TCP packet in the middle is the desired transaction query timestamp $\mathcal{T}_{q}$.

5. Estimation of Interval $I_{c,q}$ to Derive $\mathcal{T}_{c}$

This section presents the detailed solution (S-II), a universally effective approach to derive the interval $I_{c,q}$, measured in $k$ blocks, so as to further derive the transaction confirmation timestamp $\mathcal{T}_{c}$.

5.1. Transaction Status Query Methods

The detailed interaction pattern among a wallet, a RPC service and a blockchain network for processing a single transaction is illustrated in Figure 7. The interaction is triggered by a user manually sending a transaction through their wallet. All subsequent actions introduced below are then automatically performed by the wallet, RPC service and blockchain network. First, the wallet sends a RPC request containing the raw transaction to the RPC service at the time $\mathcal{T}_{s}$ in Step
[2 ]1. The RPC service checks and broadcasts the received transaction to the blockchain network in Step
[2 ]2. It also returns a transaction hash to the wallet as the acknowledgment of the receival of the transaction in Step
[2 ]3. To monitor the transaction status, a wallet has two options as follows.

Periodic query. As shown in Figure 7(a), a common way is to send a periodical query to the RPC service with the transaction hash in Step
[2 ]4. The RPC service then retrieves the ledger in Step
[2 ]5 and returns a nil if the transaction has not yet been confirmed in Step
[2 ]6. Once the transaction is confirmed and included in a new block (Step
[2 ]7), all blockchain nodes including the nodes operated by the RPC service synchronize the latest ledger in accordance with a consensus protocol in Step
[2 ]8. In the consensus protocol, the combined duration of Step
[2 ]7 and Step
[2 ]8 constitutes the block time. The transaction confirmation time is denoted as $\mathcal{T}_{c}$. The RPC service then responds to the wallet’s query with a transaction receipt in Steps
[2 ]9 and
[2 ]10, and the periodic query then stops. The time of the response at Step
[2 ]10 is $\mathcal{T}_{q}$. Ethereum wallets and Solana wallets typically adopt this method to check the transaction status, as their RPC protocols lack a notification mechanism.

Notification subscription. Alternatively, as illustrated in Figure 7(b), if the RPC service supports the notification subscription, it can notify the wallet once the transaction is confirmed (Step
[2 ]6). The wallet will then immediately initiate a query in Step
[2 ]7 and receive a response at the time $\mathcal{T}_{q}$ in Step
[2 ]9. Bitcoin wallets usually adopt this method, as the Bitcoin RPC protocol defines the notification function.

According to Figures 7(a) and 7(b), the transaction confirmation delay—the period between $\mathcal{T}_{s}$ and $\mathcal{T}_{c}$—occurs prior to the transaction confirmation and does not affect the temporal correlation between $\mathcal{T}_{c}$ and $\mathcal{T}_{q}$.

5.2. Estimation of the Interval to Derive $\mathcal{T}_{c}$

We measure the upper bound of the interval between $\mathcal{T}_{c}$ and $\mathcal{T}_{q}$, denoted as $I_{c,q}^{max}$, in units of blocks (specifically, $k$ blocks). The value of the parameter $k$ is primarily determined by the query method adopted by a wallet and the block time $z$, i.e., the time required to create a new block and add it to the ledger in a blockchain.

In the case of periodic query, the interval $I_{c,q}$ is between Steps
[2 ]7 and
[2 ]10 as depicted in Figure 7(a). Assume the periodic query cycle is $y$ seconds. The worst case is that a query cycle just ends right before the transaction is confirmed and the ledger is synchronized. Then the wallet needs to wait for $y$ seconds to initiate the next query. Considering the network RTT (Round-Trip Time), we estimate $k$ as follows,

[TABLE]

where RTT is incurred in Step
[2 ]10 and typically within $0.4$ seconds (AWS, 2025). The value of the periodic query cycle $y$ is typically hardcoded, and can be obtained by inspecting the open-sourced wallets. For closed-source wallets, $y$ can be derived through examining their network traffic. The block time $z$ is well-known for each blockchain. Take the Ethereum wallet MetaMask as an example, where $z=12$ and $y=20$, thus $k=2$ in theory. In the case of the Solana wallet Torus, where $z=0.4$ and $y=20$, we have $k=51$ in theory. Considering the practical fluctuations in the consensus process, setting $k=3$ in Ethereum and $k=60$ in Solana is robust enough.

In the case of notification subscription, we estimate $k$ as follows,

[TABLE]

where RTT is incurred in Steps
[2 ]6,
[2 ]7 and
[2 ]9. For example, for Bitcoin wallets such as Electrum, $z=120$, thus $k=1$. Setting $k=2$ is reliable enough to the practical fluctuations in blockchain networks.

As shown in Equations (2) and (3), the RTT has minimal impact on the selection of $k$, as it is typically negligible compared to the block time. This observation is further supported by our experiments on realistic blockchain networks in §8.2 and Table 4, which also include results for other wallets. Consequently, an attacker can aprioristically derive an upper bound on the interval, i.e., $I_{c,q}^{max}=k~~blocks$. Combining with the identified timestamp $\mathcal{T}_{q}$ from traffic, the attacker can obtain a transaction confirmation timestamp within the range of $\mathcal{T}_{q}-I_{c,q}^{max}\leq\mathcal{T}_{c}\leq\mathcal{T}_{q}$. Compared to the vast ledger, a small value of $k$ significantly reduces the pool of candidates.

6. Identification of Target Pseudonym

This section details the solution (S-III) to uniquely identify the target pseudonym from the ledger, presents the mathematical models underlying the method, and proposes an optimized method.

6.1. Identify Target Pseudonym via Intersection

Identifying the target pseudonym involves multiple rounds of network traffic and ledger analysis and final deanonymization.

Step-I: Traffic and ledger analysis rounds. In each round, e.g., the $i^{th}$ round, the attacker monitors network packets from the IP address of interest. They identify packets related to transaction queries and obtain the query response timestamp $\mathcal{T}_{q}$, as in §4.

The attacker then estimates the transaction confirmation timestamp $\mathcal{T}_{c}$, which is within a range: $\mathcal{T}_{q}-I_{c,q}^{max}\leq\mathcal{T}_{c}\leq\mathcal{T}_{q}$ and $I_{c,q}^{max}=k~~blocks$. The attacker can now link the monitored IP with the $k$ consecutive blocks timestamped before $\mathcal{T}_{q}$, retrieve the pseudonyms of all transaction initiators in the $k$ blocks, and form a candidate set, $\mathcal{S}_{i}=\{s_{i,1},s_{i,2},...,s_{i,n}\}$. The target $s_{t}\in\mathcal{S}_{i}$.

The attacker then performs the set intersection as follows,

[TABLE]

where $\mathcal{S}_{i}$ is the set of potential target pseudonyms at the $i^{th}$ round. $\mathcal{S}_{0}=\mathbb{U}$, where $\mathbb{U}$ is the universal set including all blockchain users. Note: $\mathcal{S}_{1}\cap\mathcal{S}_{0}=\mathcal{S}_{1}\cap\mathbb{U}=\mathcal{S}_{1}$.

Step-II: Deanonymization. The attacker performs multiple rounds (e.g., $m$) of Step-I until the cardinality of the potential target pseudonym set $\left|\mathcal{S}_{m}\right|=1$ or no longer changes. The pseudonyms in $\mathcal{S}_{m}$ link corresponding users to the IP address being monitored. If $\left|\mathcal{S}_{m}\right|=1$, a unique user is associated with the IP address. It is important to emphasize that our attack goal is ambitious, as it aims to uniquely link a single IP address to one pseudonym, rather than to a set of pseudonyms. We consider the attack successful only when $\left|\mathcal{S}_{m}\right|=1$ and the single pseudonym in $\mathcal{S}_{m}$ is the target.

6.2. Modeling the Attack

Based on the attack steps, we can derive the probability $P$ (the success rate) that the target user is uniquely identified from $m$ rounds of traffic and ledger analysis as follows,

[TABLE]

where $P_{t}$ is the probability that the target pseudonym appears in all the $m$ candidate sets, and $P_{t^{\prime}}$ is the probability that non-target pseudonyms are excluded from the candidates.

(Phase-I) Modeling the target inclusion probability $P_{t}$. If the ML-based timestamp detection method in §4 correctly identifies the packet of interest and the timestamp $\mathcal{T}_{q}$, the target user’s pseudonym $s_{t}$ will appear in the chosen $k$ blocks. Denote the probability of detecting $\mathcal{T}_{q}$ as $\alpha$,

[TABLE]

(Phase-II) Modeling the non-target exclusion probability $P_{t^{\prime}}$. We model users making transaction as a multinomial process. Assume there are $N$ users with pseudonyms in the blockchain system, i.e., $\mathbb{U}=\{s_{i}|1\leq i\leq N\}$. This multinomial process is a sequence of independent transactions where a transaction may be made by any of the $N$ users/pseudonyms. The probability of $s_{i}$ making the transaction is $p_{i}$. We model an individual user $s_{i}$ making transactions as a Poisson process with rate $\lambda_{i}$. Therefore, the number of transactions initiated by $N$ users follows the Poisson distribution with a rate of $\lambda=\sum_{i=1}^{N}\lambda_{i}$.

Denote $f_{i}$ as the probability that a non-target pseudonym $s_{i}$, where $i\neq t$, is excluded after $m$ rounds of intersection. Since $s_{i}$ can be excluded once it fails to appear in any of the sets during the intersection process (Refer to Appendix B for more details in the Appendix), $f_{i}$ can be derived in Equation (7).

[TABLE]

where $x_{j}$ is the number of transactions in the $k$ consecutive blocks in the $j^{th}$ round of the attack.

Assume $s_{t}$ is the target user in $\mathcal{S}_{1}$ and $\left|\mathcal{S}_{1}\right|=n$. The probability that the $n-1$ non-target users in set $\mathcal{S}_{1}$ are excluded after $m$ rounds of intersection is derived as follows,

[TABLE]

where $n$ is the number of pseudonyms in $\mathcal{S}_{1}$, which is collected from $k$ consecutive blocks.

(Phase-III) Modeling the success rate: Based on the above equations, we can derive $P$ in Equation (9). The parameters $x_{j}$, $n$ and $p_{i}$ are decided by the blockchain user activity intensity in the ledger. Parameters $\alpha$ and $m$ are determined by the attack strategy.

[TABLE]

6.3. Analysis and Optimization

According to Equation (9), $P$ decreases as $p_{i}$ increases, where $p_{i}$ quantifies a user’s transaction-sending intensity. Therefore, if non-target users transact infrequently, there is a better chance to uniquely identify the target user $s_{t}$. However, we observe highly active users in real-world ledgers. Such users may often appear alongside with the target in candidate sets in each round of the attack, causing false positives. To address this issue, we categorize users as normal users and active users and propose an optimized identification method based on a transacting rate threshold.

Classifying users based on a transacting rate threshold. An attacker can utilize transacting rate, i.e., the rate $\lambda_{i}$ in the Poisson distribution model of each user, as a metric to classify users. Note that, the Poisson distribution is typically used to model the number of events in a fixed interval of time. The probability of user $s_{i}$ sending one or more transactions within the period of $k$ blocks can be derived in Equation (10).

[TABLE]

where $X_{i}$ denotes the number of transactions from $s_{i}$, and $T$ is the block time. The attacker can distinguish active users and normal users (inactive users) via a threshold $\theta_{\lambda}$ of transacting rate. We define $\theta_{\lambda}$ by setting $P(X_{i}\geq 1)=1\%$, as $1\%$ is generally considered small in probability theory. Our experiment results are consistent with this threshold setting.

Optimized identification method. As outlined in Algorithm 1, after obtaining the intersection set $\mathcal{S}_{m}$ via $m$ attack rounds, the attacker calculates the transacting rate for each user in $\mathcal{S}_{m}$. Users with $\lambda_{i}$ exceeding the threshold $\theta_{\lambda}$ are active users and excluded from $\mathcal{S}_{m}$. There are three cases per the size of the final set, denoted as $\mathcal{S}_{t}$, without active users. (Case I): When $\left|\mathcal{S}_{t}\right|=1$, the only one pseudonym in $\mathcal{S}_{t}$ is output as the target. (Case II): If $\left|\mathcal{S}_{t}\right|=0$, implying that the target is an active user, the initial $\mathcal{S}_{m}$ is output and gives a set of pseudonym candidates. (Case III): If $\left|\mathcal{S}_{t}\right|>1$, indicating false positives introduced by normal users, the final $\mathcal{S}_{t}$ gives a set of pseudonym candidates. Our attack goal is ambitious; therefore, we consider the last two cases, where the result is a candidate set rather than a unique target, as failures. Fortunately, according to our measurements in §7, the occurrence probability of the Case III is only $1.47\%$ when $m=3$ in Ethereum. Moreover, only a small portion of users are active based on the transacting rate threshold (e.g., only around $0.03\%$ in Ethereum), indicating that our attack method can uniquely identify overwhelming majority of users.

7. Measurements-Based Numerical Evaluation

In this section, we conduct large-scale measurements of public ledgers from real-world blockchains, including Ethereum, Bitcoin and Solana, so as to derive numerical results of the attack based on mathematical models in §6.2, since the user activity intensity in ledgers may impact the attack results as indicated by Equation (9). These numerical results validate the intersection-based attack method, demonstrating the root cause of TRAP lies in the inherent characteristics of blockchain users and ledgers. The numerical evaluation answers the following two questions.

• •

Q1: What is the false positive rate before and after adopting the optimized identification method in Algorithm 1 (§7.2)?

• •

Q2: What is the success rate according to the statistics of public ledgers (§7.3)?

We assume the victim user is a normal user, who transacts infrequently. If the victim user is an active user, the attacker cannot uniquely identify the active user. The latter case is evaluated in §8.2 .

7.1. Datasets

We collected the public around $30.61$ GB of ledger data from August 1st to August 31st, 2024 in Ethereum mainnet. The dataset contains 221,842 blocks and 33,964,686 transactions. These transactions are initiated by 6,769,835 users. Please note that, this section primarily presents the measurements from the Ethereum mainnet as a representative example to demonstrate our models and findings. The datasets and measurements from other $5$ blockchain networks, including the Ethereum testnet, Bitcoin mainnet and testnet, Solana mainnet and testnet, exhibit similar patterns, which are presented in Appendix E and Figures 26-55 in the Appendix. In total, we processed about 3.10 TB of ledger data.

7.2. False Positive Rate

We derive the false positive rate, denoted as $R$ where $R=1-P_{t^{\prime}}$, based on large-scale measurements. According to Equations (7) and (8), and the estimation method in Appendix C, we empirically measure the probability density functions (PDFs) of the three key parameters, the number of transactions in $k$ consecutive block—$x$, the number of pseudonyms in $k$ consecutive blocks—$n$, and the probability of a user making a transaction—$p_{i}$. The measurement results and analysis are presented in Figure 11 and Figure 11, and Appendix D, through which we make Finding I.

Finding I.* Only $0.03\%$ of Ethereum users are marked as active users based on the threshold of transacting rate. Filtering out the $0.03\%$ of users who are active can significantly reduce the range of values for $p_{i}$. *

False positive rate without optimization: We first check the distribution of $f_{i}$, and then derive the mathematical expectation of the false positive rate $R$. The calculation methods based on the measured PDFs of $x$, $n$ and $p_{i}$ are presented in Appendix C. Recall $f_{i}$ is the probability that a non-target user is excluded after the intersection as discussed in §6.2. When $f_{i}$ approaches [math], the user $s_{i}$ most likely introduces the false positive. When $f_{i}$ approaches 1, the opposite holds true. The distribution $F(f_{i})$ is shown in Figure 11 when $m=3$. It can be observed that some values of $f_{i}$ approach [math]. Based on $F(f_{i})$, we further derive the expectation of false positive rate $R$. We have $\mathbb{E}[R]=97.66\%$, indicating the false positive rate is very high without optimization.

False positive rate of optimized method: Figure 11 shows the distribution $F(f_{i})$ when the attacker employs the optimized identification method described in Algorithm 1, which excludes active users (only $0.03\%$ of all users) from the intersection result. The optimized method significantly alters the distribution $F(f_{i})$, shifting from Figure 11 to Figure 11, where nearly all values of $\boldsymbol{f_{i}}$ exceed $99.99\%$. Accordingly, the expectation of false positive rate is changed to $\mathbb{E}[R]=1.47\%$. Based on this, we make Finding II.

Finding II.* The optimized identification method, which excludes only a small portion of users who are active, significantly reduces the false positive rate, from $97.66\%$ to only $1.47\%$ in a $3$-round intersection attack, highly optimizing the attack result.*

7.3. Success Rate Based on Measurements

Based on the measured probability density functions of $x$, $n$ and $p_{i}$, along with the calculation methods in Appendix C, we derive the expected value of $P$, i.e., $\mathbb{E}[P]$, which gives the success rate versus the timestamp detection probability ($\alpha$) and the number of attack rounds ($m$). Figure 13 shows the distribution of success rate $P$ using the optimized identification method. When $m=3$ and $\alpha=100\%$, $\mathbb{E}[P]=98.53\%$, indicating that variations in blockchain user activity cause minimal interference. When $m=3$ and $\alpha=0.99$, almost all values of $P$ exceed $94\%$ and $\mathbb{E}[P]=95.61\%$, suggesting a consistent and high success rate. The heatmap in Figure 13 shows the expectations of $P$ versus varying $\alpha$ and $m$. These two parameters are decided by the attacker’s capability and strategy. This enables us to assess the risks to user anonymity without launching real-world attacks on blockchain networks. The expectations of $P$ in other blockchains can be derived similarly, which are summarized in Table 3. These results demonstrate that the attacker can achieve a high success rate across blockchains, with a small $m$ and a large $\alpha$. We then make Finding III.

Finding III.* Although the number of transactions and the number of pseudonyms in $k$ consecutive blocks and the user transacting rates are random, they rarely interfere with the final attack result in our optimized identification method. The attacker can achieve high deanonymization success rates across various blockchains with only a limited number of attack rounds.*

8. Evaluation of Real-World Attacks

This section presents the results of real-world attacks on realistic blockchain networks. These results align with the numerical results in §7, validating the correctness of the mathematical models.

8.1. Experiment Setup

Platforms and tools. We use browser-based MetaMask v12.6.0 for Ethereum, Windows application Electrum v4.5.5 for Bitcoin, and web-based Torus for Solana as representatives to demonstrate the attack effectiveness across different blockchains. The generality of the attacks against other wallets is discussed in §8.3. For each wallet, we develop an automation tool built atop Selenium or pywinauto to emulate manual click operations on wallets such as sending transactions. These tools generate transactions based on timings, intervals and frequency observed in realistic ledgers. By design, each wallet keeps periodical query for network-adjusted gas price from its own server or from the RPC service, which estimates the gas price according to the network conditions in real time. When a user sends a transaction, the wallet will automatically provide the latest queried gas price as the default. In our experiments, the transactions use the wallets’ default and network-adjusted gas price, which typically ensures timely confirmation.

Victim user settings. As illustrated in Figure 14, 90 victim users are located in three regions, including Sydney, Zurich and Nanjing respectively, with 30 users in each region. To simulate realistic transaction behaviors, we randomly select the $90$ normal users (inactive users) from the ledger, and the 90 victim users replicate their transaction patterns, including transaction timings, intervals and frequency as recorded in the ledger. During a two-week attack period, these $90$ victims sent $1099$ transactions in total.

Attacker settings. For Ethereum and its wallet MetaMask, the RPC service Infura is hosted in Virginia, USA. The routing paths from victims in different regions to Infura vary widely, spanning the globe. To emulate this scenario, we artificially deploy software routers on cloud servers at various geographic locations along real-world routes identified using traceroute-like tools (e.g., NextTrace), as illustrated in Figure 14. We further employ the Point-to-Point Tunneling Protocol (PPTP) to ensure RPC traffic passes through our routers without modifying TCP packet characteristics. Each router runs Ubuntu 24.04 with 1 vCPU and 2GB of memory. Captured traffic is analyzed offline using a machine with a 12th Gen Intel Core i5-12500H (3.10GHz) and 32GB of RAM. This setup aims to demonstrate that network delay has minimal impact on deanonymization accuracy, regardless of victim or malicious router location. It is not intended to show how an adversary identifies or controls routing paths. Note that, we also set up attackers at the victims’ locations.

Network data collection and processing. The attackers employ the Linux packet analyzer tool tcpdump to capture network traffic going through the controlled relays. A Python library, mitmproxy, operating in the transparent mode, is used to execute a man-in-the-middle attack, enabling us to log TLS keys for decrypting TCP packets and label them with their corresponding RPC APIs, which serve as ground truth. Note: actual attacks work on encrypted traffic. During a two-week period of attacks against the 1099 transactions from the 90 victims, we collected in total of 26.70 GB of network traffic related to RPC services.

Generalization to real world Attack. Although our experiments are not conducted through real-world ISPs due to ethical and legal constraints, the primary impact of this limitation is restricted to missed transaction observations (see §9 for details). Nonetheless, our results based on real traffic and transaction data can be generalized to reflect real-world attack effectiveness, given sufficient transaction observations per target IP.

8.2. Real-World Attack Results

Detection accuracy of transaction query timestamp: The attacker trains the machine learning (ML) model to identify the TCP packet of interest and obtain the timestamp $\mathcal{T}_{q}$. The feature vector in Equation (1) is derived from a sequence of TCP packets of length $2r+2$. If the middle two packets in the sequence are generated by the RPC API for transaction status query, this sequence is labeled as positive; otherwise, it is labeled as negative. In Ethereum, the training dataset contains $2000$ positive instances related to target API eth_getTransactionReceipt, $2000$ negative instances related to the noise APIs, and another $2000$ randomly selected negative instances that are not generated by noise APIs but share similar packet sizes. Figure 17 shows the training results. When $r=0$, the accuracy is low, indicating that high accuracy cannot be achieved without incorporating features in packet sequences. Using the random forest model with $r=4$, the attacker can achieve a high detection accuracy of $99.74\%$, i.e., high $\alpha$ in Equation (6). Moreover, we define rule-based identification method (in Appendix H) and compare its effectiveness with ML models. As shown in Figure 17, the ML model is better.

Analysis of feature importance. Moreover, we utilize Shapley value to evaluate the contribution of each feature to the ML model’s prediction. When $r=4$, the feature vector contains $30$ features in total, with each packet profiled by three features. Figure 18 shows the feature importance of each feature. It can be observed that, the packet size of the middle packet contributes the most, and the features of its surrounding packets also contribute more. This aligns with our analysis in §4.2 and §4.3.

Effectiveness of the $k$-block interval: Upon detecting a transaction query timestamp $\mathcal{T}_{q}$ from network traffic, the attacker retrieves $k$ consecutive blocks preceding $\mathcal{T}_{q}$ to capture the target transaction. Table 4 presents the proportion of target transactions successfully captured by the $k$ blocks, based on 1000 instances per wallet. These results validate our estimation of $k$ in §5.2, and confirm that a small $k$ is effective. For example, $99.69\%$ of target transactions are included in the selected $3$ blocks for Ethereum wallet MetaMask. Accordingly, we set $k=3$ for Ethereum wallets, $k=2$ for Bitcoin wallets, and $k=60$ for Solana wallets.

Success rate in real-world attacks: Using the trained ML model and the selected parameter $k$, the attacker launches attacks against Ethereum RPC users from the MetaMask wallet. These attacks target $1099$ transactions initiated by the $90$ victim users across three regions, from March 23, 2025 to April 05, 2025, on Ethereum testnet. Additionally, the attacker performs attacks against $100$ transactions on Ethereum mainnet. Please note that, attack results on other blockchains and wallets are presented in §8.3. Figure 17 and Figure 17 show the results on Ethereum mainnet and testnet with varying $m$ and transacting rate threshold $\theta_{\lambda}$ (determined by setting $P(X_{i}\geq 1)$ to different values to exclude active users). We also compare the real-world results with the numerical results in §7.3 when $\theta_{\lambda}$ is derived by $P(X_{i}\geq 1)=1\%$. We make the following observations. (i) Our attacks achieve a high success rate. With $m=3$ and $P(X_{i}\geq 1)=1\%$, the success rate reaches up to $95.33\%$ on Ethereum mainnet and $96.80\%$ on Ethereum testnet. (ii) The real-world attack results closely align with their mathematical expectations in both trends and values, validating the correctness of our mathematical models of the attack. We observe deviations between the real-world and numerical results when $m=2$. This is reasonable, as active users are identified over a relatively long period (e.g., one month) in our method, while some normal users may exhibit high transaction intensity within a shorter time frame such as during the attack period. This issue can be easily mitigated by performing one more attack, increasing $m$ from 2 to 3. (iii) A small $m$ can yield a high success rate. This demonstrates that observing a limited number of transactions already allows the attacker to accurately link a user’s IP address to its pseudonym.

Attack results against active users: We also carry out attacks against active users by configuring the victims to send $1000$ transactions at a rate exceeding the defined threshold. In this case, the attacker links an IP address to a small set of pseudonyms, rather than a single one. On average, this set contains around $17$ pseudonyms, with a probability $99.60\%$ of including the target, when $m=3$.

8.3. Attack Generality

Attack generality across different blockchains: The attack results in Bitcoin and Solana are shown in Figure 58 and Figure 59 in Appendix, exhibiting high success rate and alignment with numerical results. When $m=4$ and $\theta_{\lambda}$ is defined by $P(X_{i}\geq 1)=1\%$, the success rate can reach up to $97.70\%$ in Bitcoin testnet. When $m=4$ and $\theta_{\lambda}$ is defined by $P(X_{i}\geq 1)=5\%$, the success rate can reach up to $96.58\%$ in Solana testnet. Although we do not evaluate real-world attacks in Bitcoin mainnet and Solana mainnet, the numerical results in Table 3 can suggest that a high success rate can be achieved in these two mainnets.

Attack generality across different wallets: Table 5 shows that our deanonymization attack consistently achieves high success rates across different wallets. This is reasonable as our attack exploits universal vulnerabilities across applications and platforms that follow similar RPC-based communication paradigm. Notably, the attack is effective against both open-source and closed-source wallets (e.g., Solflare and Phantom), as the attacker can infer wallet behaviors via network monitoring, regardless of code transparency.

Attack generality across different attacker locations: Our experiments cover multiple scenarios in terms of locations of the attacker and victim: in the same city; in different cities but within the same country; in different countries. As presented in Figure 19, against Ethereum testnet, the effectiveness of the selected $k=3$ blocks that capture the target transaction, the timestamp detection accuracy $\alpha$ and the deanonymization success rate $P$ remain consistently high at different attack locations, whether across cities or countries along the routing paths. This is reasonable because network packets exchanged between victim users and the RPC service typically preserve consistent sizes and sequences along the routing path at the TCP layer.

9. Limitations in the Experimental Evaluation

Our experiments use artificially positioned users and emulated software routers deployed at various locations to collect data. However, real-world network conditions may differ significantly from our experimental setup, potentially resulting in insufficient transaction observations (i.e., a small $m$), or failed deanonymization attempt, as discussed below:

Network jitters and packet loss. Our attack method is robust to normal network jitters, as discussed in §10. However, if the network jitter is extremely high, deanonymization may fail due to inaccurate estimation of the transaction confirmation timestamp based on the query response timestamp.

Dynamic IPs. The IP of a wallet user may change over time, particularly for mobile users, and an attacker may not observe enough (fewer than 3 or 4) transactions from a specific IP. As a result, the success rate will decrease. If an attacker observes only 1 transaction, they can only link the IP to a set of pseudonyms within the selected $k$ blocks, rather than a single pseudonym.

Geographic routing diversity. Geographic routing diversity can introduce variations in network jitters. It may also lead to partial traffic visibility. For instance, traffic from a particular IP address may not consistently traverse a malicious router or ISP, causing the attacker to miss some transaction observations. If the attacker fails to capture a sufficient number of transactions, the effectiveness of the attack may degrade significantly.

NAT. Users behind NAT have distinct private IP addresses but may share the same public IP. If the NAT router is the adversary, our attack remains effective. We now consider scenarios where the adversary operates on the Internet, external to the NAT. In this case, especially in the enterprise environments, different users may share a single public IP while using different pseudonyms. If the observed transactions originate from multiple users behind the same NAT, the intersection step in our attack yields an empty set, causing the deanonymization attempt to fail.

Feasibility of persistent network visibility. The hierarchical architecture of the global Internet ensures that attackers located at certain positions, such as a border router or an exchange point, could persistently observe sufficient traffic to deanonymize blockchain RPC users. A border router of a local/regional ISP or an enterprise network that connects the wallet users to the Internet can persistently monitor their traffic and track user IPs. A border router of a local/regional ISP that serves the RPC server can monitor RPC traffic from users at scale, although dynamic IPs and NAT may reduce the attack effectiveness. For a national/global ISP or a government interested in surveilling its citizens, they can monitor border routers that connect the national network to the global Internet. Those border routers typically have stable visibility into traffic of users within their service scope.

10. Discussion

Countermeasures. Defeating the TRAP attack proposed in this paper by enhancing RPC services and wallets is challenging, as it requires protocol-level adjustments and coordinated actions between RPC services and wallets. While potential mitigation like packet padding and random delays could help, they face significant challenges considering long-term security, practical integration, and user experience. First, although padding can obscure the size features, attackers may exploit the packet frequency to infer sensitive transaction behaviors. Second, the varying sizes of current RPC data make standardizing their size difficult, as it may disrupt the established data flow and introduce compatibility issues. Third, although introducing delays can obscure the temporal features, there is a tradeoff between delays and user experience. We leave the details of countermeasures as our future work.

IP-masking tools for defense. Using IP-masking tools like Tor/VPN can enhance wallet user anonymity and may defeat our attack. In Tor, wallet traffic passes through an entry node, a middle relay, and an exit node before reaching the RPC service. At the exit, Tor encryption is removed while RPC’s TLS encryption remains, allowing adversaries to observe traffic similar to what we study. However, grand challenges remain: (i) exit nodes change over time and vary by location, (ii) multiple users may share the same exit, and (iii) advanced attacks like confirmation attacks (Lopes et al., 2024; Ling et al., 2019) are needed to reveal the user’s true IP even if the exit IP is linked to a pseudonym using our method. Monitoring traffic at the entry node is also limited by Tor’s layered encryption and fixed-size cells, though traffic analysis/fingerprinting techniques (Mitseva and Panchenko, 2024; Li et al., 2022; Oh et al., 2023) may offer insights. VPNs can be analyzed similarly. How to deanonymize blockchain RPC users protected by Tor/VPN remains an open problem.

Impact of transaction confirmation delays. Transaction confirmation delays have no impact on the effectiveness of the attack. This is because the estimate of the transaction confirmation timestamp relies on the status query/response traffic generated after this transaction has been confirmed on-chain, regardless of how long the confirmation takes. For unconfirmed transactions or failed transactions, the ML model will classify the corresponding status query/response packets as negative instances, as the responses contain nil with a small size, preventing false positives.

Robustness to network latency. Our method is robust to network latency in the blockchain P2P network and in the interactions between wallets and RPC services. These network delays are typically within hundreds of milliseconds (AWS, 2025) and has been accounted for by the parameter block time $z$ and the $RTT$ in Equations (2) and (3), which are used to theoretically estimate the interval $I_{c,q}$ measured in $k$ blocks. To account for potential real-world fluctuations, we use a slightly larger $k$ than the theoretical estimate in the attack. The search window spans $k$ blocks (e.g., around $36$ seconds in Ethereum), far exceeding the typical network latency in practice. Moreover, our dataset is collected from geographically distributed routers and consists of thousands of transactions, covering typical network jitters. Figure 19 demonstrates that the network latency has little impact on our attack.

11. Related Work

In this section, we introduce the related work on deanonymization attacks against blockchains.

Clustering Blockchain Addresses: Many existing attacks focus on clustering blockchain addresses that belong to the same user or exhibit similar behaviors, by analyzing extensive ledger data such as topological information from transaction flow graphs (Zhao and Guan, 2015; Zheng et al., 2020; Remy et al., 2018; Meiklejohn et al., 2013; Béres et al., 2021; Linoy et al., 2019; Chen et al., 2020; DuPont and Squicciarini, 2015; Mastan and Paul, 2018). However, this type of attack cannot reveal the real-world identity of blockchain users.

Identifying Transaction Source Node: These attacks typically leverage the features of transaction propagation order and timing to define heuristic rules or train a machine learning model to identify the source node (Biryukov and Tikhomirov, 2019a, b; Gao et al., 2021; Koshy et al., 2014; Shen et al., 2020; Zheng et al., 2023). To gather sufficient propagation data and features, they often rely on a super node that maintains thousands of connections to nearly all nodes in the target blockchain, which may not be practical. Some work is only effective in particular scenarios (Koshy et al., 2014; Biryukov and Tikhomirov, 2019a; Wallace and Scott-Hayward, 2020), such as targeting malformed transactions. These methods may link a blockchain address to the IP address of a node belonging to a RPC provider, not the user. In contrast, our method is general against blockchain RPC users and does not need a super node, offering a practical solution.

Deanonymizing Lightweight Clients: A few deanonymization attacks aim to reveal the real-world identity of a blockchain lightweight client via correlating its IP address with a transaction and the initiator’s pseudonym. Biryukov et al. exploit the address advertisement mechanism and transaction propagation timing from entry nodes to deanonymize Bitcoin lightweight clients (Biryukov et al., 2014) or users accessing Bitcoin via Tor (Biryukov and Pustogarov, 2015). However, these vulnerabilities have been addressed (Fanti and Viswanath, 2017; Bitcoin, 2015). Furthermore, a research has shown that these attack methods in Bitcoin do not apply to Ethereum (Klusman and Dijkhuizen, 2018).

Attack Surfaces Introduced by Blockchain RPC Services: Only a few studies focus on security issues related to blockchain RPC services, such as DoS attacks (Li et al., 2021a, b), cryptocurrency stealing (Cheng et al., 2019), passphrase extraction attacks (Wang et al., 2018), behavior analysis of malicious users (Hara et al., 2020), and handling non-deterministic events and invalid arguments (Kim and Hwang, 2023). We highlight the risks of using public RPC services on user anonymity under passive network attacks that incur zero transaction fee.

Deanonymizing Blockchain RPC Users: There is only one study dedicated to deanonymizing Ethereum RPC users (Wang et al., 2024). It is an active attack that injects transactions into the Ethereum network via the same router as the victim. It incurs transaction fees and falls short of exposing widespread flaws in user anonymity across other blockchain networks. In contrast, our methods incur zero transaction fees under passive network attacks without traffic injection, and are applicable to various mainstream blockchains. In addition, as Solana is relatively new blockchain (Yakovenko, 2018; Pierro and Tonelli, 2022), only a few work discusses its security problems such as detecting its smart contract vulnerabilities (Cui et al., 2022; Smolka et al., 2023). We are pioneering the investigation of risks to Solana’s user anonymity.

Comparison with Web2 IP deanonymization. Both our attack and Web2 IP deanonymization involve deanonymization techniques, but their goals and techniques differ. In conventional Web2 IP deanonymization, a malicious website observes a user’s IP address and seeks to identify the user identity and their physical location (Dan et al., 2021). For clarity, we define extended Web2 IP deanonymization as the process of correlating multiple online accounts to the same user, often through shared IPs and behavioral patterns, for purposes such as targeted advertising (Wu et al., 2021). In contrast, the adversary in our attack observes a blockchain pseudonym in the public ledger and seeks to identify the IP address responsible for the corresponding transactions. If physical location information is needed, established conventional Web2 IP deanonymization techniques can then be applied to the recovered IP. Due to different application contexts and objectives, the employed attack methods vary.

12. Conclusion

In this paper, we propose a novel deanonymization attack named TRAP against blockchain RPC users across various blockchain networks. TRAP can accurately link a RPC user’s IP address with their blockchain pseudonym, by exploiting the temporal correlation vulnerability in the interactions among wallets, RPC services, and blockchain networks, which collaboratively process a transaction. TRAP only requires a passive network attacker who can monitor network traffic from the victim user and retrieve public ledgers, without incurring transaction fees. We systematically analyze and explain why our methods are universally applicable across different blockchains and wallets. Our numerical results and real-world attack results align well, and both consistently demonstrate high deanonymization success rates against normal users. All results across Ethereum, Bitcoin and Solana can achieve a success rate of over $95\%$. Although the attacker is assumed to possess network eavesdropping capabilities over encrypted traffic, the high success rate and zero attack cost (i.e., transaction fee) significantly highlight the risks to blockchain user anonymity posed by blockchain RPC protocols and services.

Acknowledgment

This research was supported in part by National Key R&D Program of China (No. 2023YFC3605800), National Natural Science Foundation of China (Nos. 62072103, 62232004, 92467205), HK RGC Theme-Based Research Scheme (No. T43-513/23-N), HK RGC General Research Fund (No. PolyU15220922), Jiangsu Provincial Key Laboratory of Network and Information Security, and Research Institute for Artificial Intelligence of Things, The Hong Kong Polytechnic University. Any opinions, findings, conclusions, and recommendations in this paper are those of the authors and do not necessarily reflect the views of the funding agencies.

Appendix

In the main text above, we primarily present analysis, figures and data related to Ethereum. In this Appendix section, we present those in other blockchains, and other details ignored by the main text.

Appendix A TCP Packet Size and Sequence Features across Blockchains and Wallets

Figure 20 shows the size range of request and response JSON objects in Ethereum RPC protocol. There are 44 RPC APIs in total. 9 out of these 44 APIs have size overlaps with our target API eth_ getTransactionReceipt.

Figure 21 shows the size range of request and response JSON objects in Solana RPC protocol. There are 54 RPC APIs in total. 13 out of these 54 APIs have size overlaps with our target API getSignatureStatuses. Appendix A shows the results considering the practical API usage in the wallet.

Figure 22 shows the API call sequence in Bitcoin wallet Electrum. It first sends out a transaction by calling API blockchain.transaction.broadcast. Then it queries the confirmed and unconfirmed transactions by API blockchain.scripthash.get_ history. When its initiated transaction is confirmed, the wallet queries its status by API blockchain.transaction.get_ merkle for checking its validity. Electrum also periodically calls APIs for estimating transaction fees every minute.