A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum Kanan Huseynov # Department of Informatics, Eötvös Loránd University, Budapest, Hungary
Ali Shahzaib # Department of Informatics, Eötvös Loránd University, Budapest, Hungary
István András Seres # Department of Informatics, Eötvös Loránd University, Budapest, Hungary
János Tapolcai #
arXiv:2606.25926v1 [cs.CR] 24 Jun 2026
Dept. of Telecommunications and AI, Budapest University of Technology and Economics, Hungary
Abstract From a user’s perspective, perhaps the most significant difference between traditional banking services and widely used blockchain-based financial systems is that, in the latter, transactions and – either directly or indirectly – account balances and transaction histories are publicly observable. Therefore, a growing number of cryptographic solutions have been proposed to “add a privacy layer” to such systems. However, the privacy that users actually obtain does not depend solely on the security of the underlying cryptographic protocol: user behavior, transaction-amount patterns, and timing decisions can substantially reduce anonymity. In this work, we study behavioral leakage in cryptocurrency mixers, focusing on Railgun on Ethereum. We aim to heuristically estimate the probability that a given deposit and withdrawal transaction belong to the same user. We consider five sources of leakage: characteristic timing patterns, address reuse, proximity in the transaction graph induced by prior public transactions, amount fingerprints that preserve distinctive digit patterns across transaction values, and knapsacktype matches in which groups of transaction amounts add up in revealing ways. Our results show that even cryptographically strong privacy systems may suffer substantial anonymity loss due to user behavior and transaction patterns. Our five heuristics are able to uniquely link 17.65% of Railgun withdraw transactions to deposit transactions. We also applied a knapsack solver algorithm that was able to produce a 3.42 bit median anonymity loss for withdraw transactions. This work contributes to a better understanding of the practical privacy limits of mixers and anonymity pools, and points toward safer usage practices and design principles. 2012 ACM Subject Classification Security and privacy → Pseudonymity, anonymity and untraceability; Security and privacy → Privacy-preserving protocols; Security and privacy → Economics of security and privacy; Applied computing → Digital cash Keywords and phrases Ethereum, Blockchain, Anonymity, Privacy, Railgun Digital Object Identifier 10.4230/LIPIcs.CVIT.2016.23
1
Introduction
Cryptocurrencies have been remarkably successful as investment assets, yet have not fulfilled their original promise of becoming widely used money. This limitation is not merely technical. With the emergence of layer-2 systems, cryptocurrencies can in principle support low-cost, high-throughput, and even micropayment-scale transactions. A more fundamental barrier is related to privacy and user behavior. In traditional payments, the buyer and the merchant necessarily interact, and therefore they are not anonymous to each other. Precisely for this reason, it is essential that the payment process does not reveal the buyer’s account history or balance to the merchant, nor the merchant’s broader financial activity to the buyer. In contrast, widely used public blockchains expose transaction histories and, either © Copyright; licensed under Creative Commons License CC-BY 4.0 42nd Conference on Very Important Topics (CVIT 2016). Editors: John Q. Open and Joan R. Access; Article No. 23; pp. 23:1–23:28 Leibniz International Proceedings in Informatics Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany
23:2
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
directly or indirectly, account balances. As a result, a simple on-chain payment can reveal far more information than users would normally disclose in a traditional payment setting. For cryptocurrencies to serve as practical payment systems, they therefore need transaction mechanisms that preserve this basic form of financial privacy: neither party should learn the other party’s transaction history or balance, while the merchant should still receive cryptographic assurance that the correct payment has been made. At the same time, financial privacy creates an inherent regulatory tension. Privacypreserving payment systems can also make it harder to detect tax evasion, money laundering, sanctions evasion, and other illicit activity. Tornado Cash, a privacy-enhancing overlay on Ethereum, is a prominent example [20]. In August 2022, the U.S. Department of the Treasury sanctioned a set of Tornado Cash smart-contract addresses, effectively prohibiting U.S. persons from interacting with them. Usage dropped sharply after the sanctions, and parts of the Ethereum ecosystem began to censor or avoid Tornado-Cash-related transactions [36, 40]. The sanctions were later challenged in court, and in March 2025 the Treasury removed Tornado Cash from its sanctions list. Nevertheless, the episode illustrates the fragile position of privacy-enhancing infrastructure: it is simultaneously a tool for ordinary financial privacy and a source of serious compliance concerns. Despite this growing need for privacy-preserving payment mechanisms, financial privacy is not a first-class default property in any of the top 10 cryptocurrencies by market capitalization as of May 2026, according to CoinMarketCap. This has motivated a broad line of work aimed at adding a privacy layer to transparent blockchains, with stealth addresses, mixers and anonymity pools among the most prominent approaches [6, 16, 20, 25]. At a high level, Ethereum-based versions of these systems are implemented as smart contracts that maintain a private pool of funds. Users deposit assets into the contract, and subsequent operations are represented as cryptographically hidden state transitions. Using cryptographic techniques, often based on zero-knowledge proofs, the system can verify that a transaction is valid without revealing which users’ balances change, or by how much. The public blockchain observes that the pool state has been updated, but not the internal ownership changes that took place inside the pool. Eventually, users may withdraw funds from the private pool to a fresh public address. In a typical mixer, this means that a user first deposits funds into the pool and later withdraws them without publicly revealing which deposit funded the withdrawal. In principle, the identity of the withdrawer is hidden among all previous depositors, often referred as the corresponding anonymity set. However, this cryptographic guarantee captures only one aspect of privacy. It prevents an observer from directly verifying the deposit–withdrawal link from the protocol transcript, but it does not eliminate all side information available on a public blockchain. Users may interact with the system in ways that leave behavioral traces: they may withdraw shortly after depositing, reuse related addresses, transfer distinctive amounts, or split and recombine funds in recognizable patterns. Such traces can shrink the effective anonymity set well below the nominal set of all prior deposits. This distinction between nominal and effective anonymity is crucial in practice. A mixer may provide a large cryptographic anonymity set, yet only a much smaller subset of deposits may be plausible candidates for a given withdrawal once timing, transaction amounts, and prior on-chain relationships are taken into account. In other words, privacy loss may arise not from a failure of the cryptographic protocol itself, but from the interaction between the protocol and user behavior. In this work, we study this form of behavioral leakage in cryptocurrency mixers, focusing on Railgun on Ethereum as a case study. Railgun is particularly relevant because it extends the mixer model beyond simple fixed-denomination deposits/withdraws and supports more
Huseynov et al.
23:3
flexible private interactions inside the shielded pool. This flexibility is useful for users, but it also creates new opportunities for statistical and graph-based inference. Our goal is to estimate, using heuristic evidence, how likely a given deposit and withdrawal transaction belongs to the same user. As a solution to these privacy risks, various cryptographic solutions (cryptocurrency mixers and privacy pools) have been introduced,e.g., Tornado Cash (TC). However, these solutions only provide limited features. Some limitations of these solutions include the following. 1. Limited Currencies: Most mixers (most notably Tornado Cash) only support private transfer of native ETH and a handful of more ERC20 tokens. Railgun supports the deposit of every ERC20 tokens into the Railgun shielded pool. 2. Limited Functionalities: TC only allowed the deposits and withdraws of cryptoassets. On the other hand, Railgun aims to provide a much richer sets of functionalities such as internal shielded (thus, enabling private, confidential asset transfers), private decentralized finance applications (Uniswap, Compound, etc.). Thus, Railgun hopes to increase the anonymity sets and incentivize users to leave longer their funds in the shielded pool than as if there were no added financial functionalities.
1.1
Our contributions
In this work, we provide the following contributions. Behavioral leakage perspective. We study privacy in shielded-pool systems from a behavioral perspective. Rather than looking for cryptographic failures, we ask how much information remains available through public timing, amount, and transaction-graph patterns, and how this information can reduce the anonymity users obtain in practice. Heuristics for linking deposits and withdrawals. We introduce four families of heuristics for identifying plausible deposit–withdrawal links: address reuse, proximity in the public transaction graph, amount fingerprints, and knapsack-type amount matches. These heuristics are not intended to provide definitive deanonymization, but to estimate how much behavioral evidence points toward particular links. Measurement study of Railgun on Ethereum. We apply these heuristics to Railgun [5] on Ethereum and characterize the resulting anonymity loss. Our results show that even when cryptographic mechanisms hide direct links, observable user behavior can substantially narrow the set of plausible origins for withdrawals. Empirical usage statistics. We provide an empirical characterization of Railgun usage on Ethereum, including deposit and withdrawal behavior, timing patterns, transaction amounts, and the observable public-graph relationships around users entering and leaving the shielded pool. Open-source code and datasets. We release as an open-source repository the entire collected dataset, and the code we developed to analyze it. The repository is available at the following link: https://github.com/c0rt3x1337x/railgun_deanonymization.
1.2
Ethical considerations
We study behavioral leakage in a deployed, publicly accessible privacy system. All data used in our analysis was collected exclusively from the public Ethereum blockchain, which is permissionlessly readable by any party without authentication or special access. We did not interact with the Railgun protocol in any active capacity, did not attempt to inject transactions, and did not access any off-chain data sources such as IP addresses, user accounts,
CVIT 2016
23:4
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
or private communications. Our adversary model is therefore strictly passive and confined to publicly available information, consistent with the threat model described in Section 2.4. Our analysis operates at the level of Ethereum addresses, not individuals. We do not resolve pseudonymous addresses to real-world identities and do not publish any mapping between addresses and persons. The introduced heuristics produce probabilistic links between deposit and withdraw addresses; they do not identify the human beings who control those addresses. We deliberately refrain from publishing the list of flagged address pairs. The anonymity losses we document arise from user behavior, not from cryptographic vulnerabilities in Railgun’s zero-knowledge proof system. There is therefore no technical vulnerability to disclose in the traditional sense. Nevertheless, we shared a preliminary version of our findings with the Railgun development team prior to submission, in line with responsible disclosure practice for privacy measurement studies. The heuristics we describe are passive, observable by any blockchain analyst, and do not require any special tooling or insider access. Publishing them advances the public understanding of practical privacy limits and enables users to make more informed decisions. The rest of this paper is organized as follows. In Section 2, we describe the necessary background on shielded pools on Ethereum, with a particular focus on Railgun. Section 3 studies behavioral and usage patterns in the Railgun ecosystem. We formulate our deanonymization heuristics in Section 4 and evaluate them in Section 5. We review related work in Section 6. Finally, we conclude with open research directions in Section 7.
2
Background
2.1
Notations
To formalize the cryptographic and blockchain primitives discussed in this paper, we adopt the following notations: for a summary of our notations, see Table 1.
2.2
Railgun: A Cloak of Invisibility
Railgun is a privacy-enhancing layer on top of Ethereum implemented as a set of smart contracts. It is designed to allow users to deposit and withdraw funds from this private layer, often referred to as the Railgun shielded pool. Additionally, users can send confidential payments inside the shielded pool and can interact with on-chain decentralized applications Notation
Description
D, W, I Multiset of depositor, withdrawer, and internal transactions senders, respectively supp(D) The support of a (multi)set D 0x/0zk Public/private Ethereum address types di , w j The address that sent the ith deposit, and received the jth withdraw transaction B A blocklist containing flagged, non-compliant deposit addresses sender(wj ) The sender of the jth withdraw transaction t(di ) The timestamp when the ith deposit transaction had been sent tx(di , wj ) A boolean variable evaluating to true (1) iff there is a transaction sent from di to wj amt(di ) Deposit amount of the ith (similarly, we allow amt to withdraw) deposit tx d(x, y), ∥x∥ Hamming distance of two strings x and y, Hamming-weight of x. Table 1 Notations used throughout the paper.
Huseynov et al.
23:5
DEX 3) Swap tx
IN
OUT
From: 0x12..ab Amt: 7 ETH
To: 0x34..cd Amt: 3 ETH
1) Deposit tx
4) Withdraw tx 2) Internal tx
Shielded Pool
Depositors
Withdrawers
Figure 1 The Railgun privacy-enhancing overlay. Users can have four types of interactions with the Railgun smart contracts. Users can deposit (often shield) funds into the shielded pool. After funds are shielded, users can make internal transactions whose amounts are hidden, also known as confidential transactions. Users can use their shielded notes to unshield them and use them either in DeFi (e.g., Uniswap) or withdraw (unshield) it back to the public Ethereum transaction graph.
(dApp), e.g., decentralized exchanges, lending pools, decentralized finance applications, etc., in a private manner. Railgun introduces a new address type on Ethereum called 0zk addresses. 0x addresses This is the native Ethereum address type that does not provide confidentiality, i.e., any transaction to/from 0x addresses is visible on the blockchain with their transaction amounts exposed to the public. This allows any chain analyst to create a complete transaction history and accurate balance of every 0x address. 0zk addresses A new private address type implemented by Railgun. Any transaction between two 0zk addresses is confidential, i.e., the transaction amounts, and the sender/receiver 0zk addresses remain hidden to the public. Thus, in principle, no chain analyst can establish neither the balance nor the transaction history of any 0zk addresses. Next, we review the actors and their possible actions on Railgun focusing on the privacy details and omit all unnecessary cryptographic details. Depositors Users can deposit amt(di ) funds to any 0zk address within the shielded pool by issuing a deposit transaction di at time t(di ). Often we refer both to the public 0x sender address and the deposit transaction as di . Users may issue many deposit transactions. Railgun smart contract Every Railgun functionality (i.e., deposit, withdraw, and internal transactions) requires users to issue transactions with the Railgun smart contract as the recipient address. It stores a Merkle tree of cryptographic notes and nullifiers. Withdrawers An owner of a cryptographic note in the shielded pool may withdraw that note with value amt(wj ) back to the public 0x Ethereum address. Our primary focus in this work is to understand which withdrawer wj can be linked to a previous depositor di . Users Note that a Railgun user is not necessarily a depositor or withdrawer. One may receive and send funds inside the shielded pool without depositing or withdrawing them from the shielded pool, i.e., one can send and receive funds from a 0zk address they own.
CVIT 2016
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
Events/week
23:6
600
Deposit Withdraw
400 200 0
2022
2023
2024
2025
2026
Year Figure 2 Railgun weekly deposit and withdraw transaction counts on Ethereum L1.
Relayers When a user wants to withdraw funds to a fresh address wj , typically wj lacks funds to cover the transaction fees of the withdraw transaction. Thus, a third party may submit the withdraw transaction on behalf of the user (in exchange for a relayer fee) to avoid any unnecessary behavioural leakage. We identified 124 relayers, cf. Figure 8. Railgun users may issue the following types of transaction. Deposit (shield) transaction As of May 12, 2026, 122 477 deposit transactions have been issued with a total volume of $5 058 127 358 (Ethereum L1 and Arbitrum, Polygon, BSC). Importantly, Railgun applies a zero-knowledge compliance monitoring tool called Private Proofs of Innocence (PPOI). Every deposit transaction undergoes this analysis: if the depositor address di is on a blocklist, the deposited funds cannot be used inside the shielded pool. Subsequently, Railgun only allows one to withdraw the blocklisted deposited amount back to the very same deposit address di . Internal transaction Confidential transactions that occur inside the shielded pool between 0zk addresses are called internal transactions. A public observer only sees the number of input notes redeemed, and the number of newly created output notes, cf. Figure 20. Withdraw (unshield) transaction As of May 12, 2026, 328 520 withdraw transactions had been issued, cf. Figure 2. Swap transaction Users may unshield some of their shielded notes and use them in various DeFi applications, e.g., swapping assets on decentralized exchanges. This is a moderately used feature in Railgun, e.g., 3133 swap transactions at the time of writing. For comprehensive usage statistics on Railgun swap transactions see Figure 13.
2.3
Anonymity Guarantees and Their Measurement
In this work, we are primarily interested in breaking the following privacy guarantee provided by Railgun. Intuitively, every prior deposit transaction should act as an equally likely source for a given withdraw transaction. Next, we formalize this intuition. ▶ Definition 1. (Deposit-withdraw transaction unlinkability) This unlinkability privacy guarantee requires that for every PPT adversary A, and for a withdraw transaction wj that received (some of) its money from deposit transaction di , A has a negligible advantage in finding the real source di for withdraw wj . More formally, ∀di ∈ D(wj ) : Pr[A(D(wj ), wj ) = di ] −
1 ≤ negl(λ) , |D(wj )|
(1)
where D(wj ) := {di |t(di ) ≤ t(wj )}, i.e., is the set of deposit transaction issued before t(wj ).
Huseynov et al.
23:7
In a similar vein, one could define deposit-internal transaction unlinkability, deposit-swap transaction, or internal-withdraw transaction unlinkability, etc. We leave it to future work to define, assess and potentially break these privacy properties in Railgun. The adversary’s goal is to determine which deposit dj can be linked to a withdraw wi . To that end, the adversary outputs a discrete probability distribution over D(wi ). Thus, we want to measure the uncertainty of a given adversary A about the sources of funds for a withdraw transaction wj . ▶ Definition 2. (Entropic anonymity measure [7, 26]) For a withdraw wj and adversary A, let Xj,A denote the probability distribution over D(wj ) i.e., , for di ∈ D(wj ), we have Pr[Xj,A ∈ {di }] := pi . Let the anonymity measure A(wj ) of wj be the Shannon-entropy of Xj,A . Formally, we have A(wj ) := H(Xj,A ) = −
X
pi log2 (pi ) .
(2)
di ∈D(wj )
In the context of Railgun, when one wants to break deposit-withdraw unlinkability, cf. Definition 1, the ideal anonymity measure that Railgun achieves would be that for each withdraw transaction wj , the adversary deems each prior di equally probable. We call this the optimistic anonymity guarantee achieved by wj ▶ Definition 3. (Naïve or optimistic anonymity) We define an idealistic upper bound on the anonymity measure of wj as A(wj ) := log2 (|D(wj )|). The main goal of this work is to define adversarial strategies that give a more realistic upper bound than the optimistic Shannon-entropic measure on the achieved anonymity guarantees of Railgun. We focus on measuring anonymity using the classical Shannon entropy-based anonymity measures defined above. We leave it to future work to apply and evaluate other anonymity measures [35] for assessing the anonymity provided by Railgun.
2.4
Threat Model
We assume a passive adversary, i.e., we only assume access to the public Ethereum blockchain data. This adversary may be e.g., a blockchain analyst. In our analysis, we do not use metadata leakages that come from other layers of the decentralized technology stack, e.g., network-level leakages [37], or other public data sources (e.g., social media). However, we note that, for example, relayers or other Ethereum full nodes could link the depositor/withdrawer IP addresses to their public 0x Ethereum addresses. We leave it to future work to evaluate the efficacy of active attacks on privacy, for example, one could launch an active amount fingerprinting attack inside the shielded pool [3]. In this attack, the adversary sends a maliciously crafted transaction in the hope of altering certain digits in the 0zk balance of an address. If at withdrawal time those digits remain unchanged, then the adversary could follow the flow of funds back to the public part of Ethereum (i.e., 0x addresses).
3
Railgun Usage Statistics
3.1
Dataset
We collected every transaction of Railgun users in relation to deposit, withdraw, internal, and swap transactions, cf. Figure 3. In addition, we also collected every transaction sent from all identified Railgun users. We mostly focused on their ETH and ERC20 token transfers.
CVIT 2016
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum H2 post-2023 cutoff
Railgun Shield events Railgun Unshield events (V2) Railgun Internal transfers Railgun RelayAdapt swaps External ETH transfers External ERC20 transfers 2020 2020 2021 2022 2024 2024 2025 Year Figure 3 The coverage of our collected datasets. 10−1
Probability
23:8
10−5 10−9 1
h
12
h
1
k
d 1
th on
e we
1
m
d ear 3 18 1 y
Time difference [days] Figure 4 The probability density function of the time differences (t(wj ) − t(di )) between deposits di and withdrawals wj linked by Heuristic 1 (deposit-withdraw address reuse), cf. Section 4.1.
3.2
Limitations
We solely focus on the Ethereum Layer-1 blockchain, though Railgun has been deployed on other Layer-2 networks as well, such as Arbitrum, Polygon, and Binance Smart Chain. Moreover, this work focuses solely on the native currency ether, even though Railgun supports the shielding and unshielding of ERC-20 tokens (e.g., USDC, USDT, DAI, etc.) as well.
3.3
Railgun Usage
First, we study Railgun users’ behavior at large. Most importantly, we measure how much money is left and used in the shielded pool. We observe in Figure 5a, that as of 29th April, 2026, only 81 734 ETH has been left in the shielded pool, that is 15.00% of the total cumulative deposits in Railgun’s history. This suggests that the vast majority of Railgun users still treat Railgun’s shielded pool as a simple Tornado Cash-like cryptocurrency mixer that has only two functionalities: deposits and withdraws. We can derive a rough estimate for the average residence time of funds in the Railgun pool using a Little’s law style approximation [14]. Let R denote the average retained balance in the pool and let λout denote the average unshielding rate (ether/day). Under the assumption that the system is approximately in steady state over the observation window, the average residence time can be estimated per Little’s theorem as T ≈
R 58 633 WETH = = 183 days. λout 320 WETH/day
(3)
Using the observed cumulative unshield volume and the length of the observation period, we estimate an average outflow of roughly 320 WETH per day. Combined with an average retained balance of approximately 58 633 WETH (see Figure 5b), this suggests that the typical residence time of funds inside the Railgun pool is on the order of several months.
·105
·105
Shield Unshield
4 2 0
2022
2023
2024
2025
2026
1
shield(t) − unshield(t)
300 200
0.5 100
FIFO-style estimate 0 2023
2024
Year
2025
2026
0
Residence time [days]
23:9
Retained WETH
Cumulative WETH
Huseynov et al.
Year
(a) Cumulative WETH shielded and unshielded (b) Retained WETH balance (left axis) and FIFOover time. The retained balance, i.e., the difference style residence time estimates (right axis) derived from between the two curves, is shown on the right. cumulative shield and unshield flows.
Figure 5 Cumulative shield and unshield volumes and implied residence time estimates in Railgun.
Figure 5b also shows a FIFO-style estimate based on the horizontal lag between cumulative shield and cumulative unshield curves, i.e., the delay required for unshielded volume to “catch up” with prior shielded funds. This independent estimate yields a similar timescale, supporting the same several-month residence-time conclusion.
4
Heuristics: Tattering the Cloak of Invisibility
Next, we formulate our heuristics (cf. Figure 7 for a figurative illustration) that we empirically evaluate in Section 5 to link withdraw to deposit transactions. A trivial observation that we do not formulate as a separate heuristic is that a withdraw transaction wi cannot be linked to deposit transactions dj that occurred after wi , i.e., ∄(wi , dj ) : t(dj ) ≥ t(wi ).
4.1
Heuristic 1: deposit-withdraw address-reuse
Ethereum’s account-based ledger model encourages address reuse for better usability. Thus, in accordance with prior works [1, 38, 42], we formulate our first heuristic. ▶ Definition 4. (Heuristic 1 (H1)) If there exists (i, j) ∈ N2 such that di = wj ∧t(di ) ≤ t(wj ), then we consider the deposit di and withdraw wj transactions linked. This is our only heuristic that, by definition, cannot produce false positives.
4.2
Heuristic 2: direct transactional linkage
Many users falsely believe that withdraw addresses are “clean” addresses as their direct source of funds is the “clean” shielded pool. Thus, whenever they run out of liquidity at a withdraw address wi , they top its balance up by sending money from their other Ethereum accounts, often from a deposit address dj , cf. Figure 6. If a transaction occurs in either direction (di → wj ∨ wj → di ), we consider those deposit and withdraw transactions issued by the same user. ▶ Definition 5. (Heuristic 2 (H2)) If ∃(i, j) ∈ N2 : tx(di , wj ) = 1 ∨ tx(wj , di ) = 1, then we consider the deposit addresses di and withdraw wj linked. We acknowledge that this heuristic may introduce false positive links. Intuitively, Heuristic 2 exploits the connectedness of the deposit and withdraw addresses in the transaction graph. One could generalize Heuristic 2 such that it also considers deposit and withdraw
CVIT 2016
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
Txs/month
23:10
H2 post-2023 cutoff
ETH transferes ERC20 transfers
400 200 0
2019
2020
2021
2022
2023
2024
2025
2026
Year Figure 6 Number of monthly transactions between Railgun depositor and withdrawer addresses. The prevalence of these transactions motivates our formulation of Heuristic 2, cf. Section 4.2.
addresses being linked if they are k-hop away from each other in the transaction graph (e.g., for k = 1 think of a swap transaction on a decentralized exchange with different in and out addresses). We did not pursue this direction, as it would have introduced more false positives. Alternatively, one could generalize this heuristic where the link between di and wj is probabilistic and weighted by the number of transactions between the two addresses.
4.3
Heuristic 3: withdraw transaction gas payer address reuse
Currently in Ethereum, each transaction’s sender must pay the transaction fee in ether, Ethereum’s native cryptocurrency [24]. However, when a user wants to withdraw funds from Railgun to a fresh withdraw address wj that had not been funded, they cannot send the withdraw transaction from wj . Therefore, the withdraw transaction sender must be another unlinked address. Railgun provides two solutions to this privacy-usability dilemma. Relayed withdraw transactions Withdrawers may use a third-party, a so-called relayer, to send their withdraw transactions in exchange for a relayer fee. From a privacy point of view, this is the safest solution, since the relayer’s address is typically independent from the user’s withdraw address wj . Self-broadcast withdraw transactions Users may opt out from using relayers and broadcast their withdraw transaction from another address they own. We denote this address as sender(wj ). If the address sender(wj ) can be linked in some way to a depositor address di , then we can also link wj to di . Thus, we formulate our next heuristic as follows. ▶ Definition 6. (Heuristic 3 (H3)) If the sender address of a withdraw transaction sender(wi ) ∈ D and sender(wi ) itself is not a relayer, then we link wi and sender(wi ). We detail in Section 5.4, how we differentiate between “regular” (i.e., a user-relayed) and a relayed withdraw transactions. In other words, we need reliable and robust ways to identify relayers to reduce false positives produced by this heuristic.
4.4
Heuristic 4: fee-aware, knapsack matching
Users who withdraw amounts that closely match one or more of their prior deposit amounts reveal a behavioral trace even when there is no direct address or transactional relationship. We formalize this observation as a knapsack-type matching heuristic. We say that a withdrawal wj exactly matches a k-to-ℓ knapsack pattern with a subset of deposits S = {di1 , . . . , dik } (S ⊂ D) if: X amt(d) = amt(wj1 ) + · · · + amt(wjℓ ) ± ϵ (4) d∈S
Huseynov et al.
23:11
H3: Gas Payer Reuse H1: Address Reuse di
pool
wj
gas payer
H2: Direct Tx Link di
wj
pool
di
wj
pool
on-chain tx
di = wj
H4: Knapsack Matching
H5: Amount Fingerprint
amt(di1 ) + amt(di2 ) ≈ amt(wj )
amt(di ): 1.34567...
di1 pool
wj
di
di2
deposit address
di
pool
wj
match
amt(wj ): 0.34511...
withdraw address
pool
shielded pool
linking evidence
Figure 7 Illustrating our five heuristics. H1 links deposit and withdraw transactions that belong to the same address. H2 heuristically links deposit and withdraw transactions, if there is at least one on-chain transaction between the deposit and withdraw addresses. H3 links a depositor di and withdrawer wj , if the withdraw transaction was sent from the deposit address di . H4 aims to solve knapsack instances induced by the deposit and withdraw amounts. H5 looks for repeating patterns in the deposit and withdraw amounts that are likely not destroyed by internal or swap transactions.
for a small tolerance ϵ reflecting relayer and other protocol fees. ▶ Definition 7. (Heuristic 4 (H4)) A deposit set S = {di1 , . . . , dik } and withdrawal set T = {wj1 , . . . , wjℓ } are linked if (i) all elements of S precede all elements of T in time, (ii) their amounts satisfy the knapsack equality, cf. Equation (4), within a tolerance ϵ.
4.5
Heuristic 5: amount fingerprints
Unlike Tornado Cash, which enforces fixed deposit denominations, Railgun accepts arbitrary deposit and withdraw amounts. This flexibility is a privacy liability: users who deposit a psychologically salient or computationally convenient amount (e.g., exactly 1.234 567 ETH) tend to preserve the significant digits of that amount in their withdrawal, either through round-tripping or through an internal transfer that preserves the face value minus fees. We represent the decimal expansion of an amount a as a string of digits dig(a) = (a1 , a2 , . . . , an ) at a fixed precision (18 decimal places for ERC-20 tokens). We define the fractional fingerprint of a as the three most significant non-zero digits of its fractional part. Two amounts a, b are said to be fingerprint-matched if their fractional fingerprints agree. ▶ Definition 8. (Heuristic 5 (H5)) A deposit di and withdrawal wj are heuristically linked by H5 if frac3(amt(di )) = frac3(amt(wj )) and this fingerprint is globally unique in the dataset, i.e., no other deposit-withdrawal pair in the same token shares it.
5
Empirical Evaluation of Our Heuristics
We now evaluate the five heuristics introduced in Section 4 against our collected Railgun data set. We first characterize the time-sensitivity of deposit-withdraw pairs, then report
CVIT 2016
23:12
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
the per-heuristic coverage, and finally synthesize the results across all heuristics to estimate the overall anonymity loss, cf. Definition 2. Our evaluation was run on a machine with Intel Core Processor, 8 vCPUs, 16 GB RAM (no swap).
5.1
Time-sensitivity of withdraw-deposit pairs
A fundamental question for any timing-based analysis is how quickly users tend to withdraw after depositing. Short deposit-withdraw intervals shrink the effective anonymity set dramatically, e.g., a withdrawal that occurs one minute after a deposit has only a handful of plausible sources, regardless of how many deposits have accumulated in the pool overall.
5.1.1
Overall timing distribution
Figure 4 shows the empirical distribution of deposit-to-withdraw time differences ∆t = t(wj ) − t(di ) for the 2904 H1-confirmed pairs. The distribution is strongly right-skewed. The median ∆t is 0.84 days, meaning that half of all identified users wait less than one day between depositing and withdrawing. The P90 is 114.9 days and the P99 is 486.6 days, reflecting a long tail of users who leave funds in the shielded pool for months. This bimodal character — fast-cycling users who treat Railgun as a simple mixer, and long-term users who genuinely use the shielded pool — has direct implications for the effective anonymity set: fast-cycling users expose themselves to timing analysis regardless of the pool’s nominal size.
5.1.2
Fee-stratified timing
We further stratify the 2904 H1 pairs by the gas price paid on the deposit transaction, splitting them into equal halves at the median gas price (low-fee group: N = 1452; high-fee group: N = 1452). Counterintuitively, low-gas-price depositors withdraw faster than highgas-price depositors: the low-fee P50 is 0.73 days versus 0.98 days for the high-fee group, and the low-fee P90 is 58.9 days versus 178.2 days. One interpretation is that high-fee depositors are more privacy-aware users who pay for faster block inclusion and then exercise greater patience before withdrawing; low-fee depositors may be less sophisticated users who deposit and withdraw opportunistically. Regardless of the mechanism, both groups have a median withdrawal interval well under one day, making timing a potent signal in practice.
5.2
Heuristic 1: deposit-withdraw address reuse
H1 identifies 2904 unshield events (6.10% of the filtered unshield population (W) of 47 596) as directly reusing a known deposit address, covering 8.57% of unique addresses and 8.52% of WETH volume. Every H1 link is a certain true positive by construction. We note that 710 (1.49% of |W|) deposits were flagged by the PPOI compliance tools, thus, these addresses were forced to withdraw their funds to the very same deposit address. Nevertheless, H1 remains our second best performing heuristic in terms of linked withdraw transactions.
5.3
Heuristic 2: direct transactional linkage
H2 identifies 4272 unshield events (8.98% of W) via at least one on-chain transaction between the deposit and withdraw addresses. The breakdown by asset and direction is shown in Figure 12: ETH flows from deposit to withdraw account for 3139 transactions (all-time), while the reverse direction (withdraw to deposit) accounts for 3620 transactions —the larger of the two, reflecting users who send a portion of their withdrawn funds back
Total WETH volume
Huseynov et al.
23:13
104 100
Mixed-activity (N=1,658) Self-broadcaster (N=981) Broadcasters (N=124)
10−4
100
101
102
103
Distinct recipients served Figure 8 Recipient address frequency of withdraw transaction senders. We use these usage statistics to heuristically distinguish between regular users and relayers for withdraw transactions.
to a known deposit address. ERC20 transfers contribute 789 deposit-to-withdraw and 1253 withdraw-to-deposit transactions. Restricting to post-2023 activity yields similar proportions, indicating that this behavioral pattern has not decreased as Railgun has matured. The boundary-metadata signals — zero-output unshields and self-broadcast events — are closely related to H2 and together cover 6272 (13.18%) unshield events. Of these, 3433 are flagged by both signals, 1996 by the zero-output flag alone, and 843 by the self-broadcast flag alone. Self-broadcast events are particularly damaging for privacy: the depositor who acts as their own relayer directly exposes their deposit address in the withdrawal transaction, nullifying the primary anonymity benefit that relayers provide.
5.4
Heuristic 3: withdraw transaction gas payer address reuse
We identify 6856 withdraw transactions as self-broadcast transactions. These self-broadcast transactions have 2761 unique gas payer addresses, and among these there are 1658 (60.1%) addresses that are also depositors. There are two mutually exclusive subsets of this withdraw transaction set identified by H3. Gas payer address is the same as wi If the gas payer address is the same as the withdraw recipient address and this address is also a depositor, then this withdraw transaction has already been linked by H1, cf. Section 4.1. There are 1681 withdraw transactions in this subset with 1094 distinct gas payer addresses (among these 714 were deposit addresses). Gas payer address is not the same as wi We found 5175 withdraw transactions, that were self-broadcast and the gas payer address was distinct from the withdraw address. More importantly, out of the 1825 distinct gas payer addresses in this subset, 1049 were also depositor addresses allowing us to link these gas payer/depositor addresses to the withdraw addresses per H3.
5.5
Heuristic 4: knapsack matching
Although the knapsack problem is an NP-complete problem [13], in certain cases, one has hope to solve the arising real-world knapsack instances efficiently. This is also the case for Railgun. First, the arising knapsack instances are relatively small, and second, the capacities in the knapsack problem are not large. Thus, we chose to apply a pseudopolynomial-time (i.e., O(nC), where C is the knapsack capacity) dynamic programming algorithm to solve our knapsack instances. The algorithm we applied is due to Pisinger [22]. In our adaptation of his algorithm, we have two parameters (t, b) that determine the running time and the precision of the algorithm’s output. In our evaluation, we look primarily for k deposit amounts that sum up to a single withdrawal amount (we call this the k-to-1 direction). In Section A, we
CVIT 2016
23:14
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
also evaluate the 1-to-k direction, i.e., where a single deposit amount equals the sum of k different withdraw transactions. Time window t For a given withdraw transaction wj , we only consider deposit transactions di for which t(wj ) − t ≤ t(di ) ≤ t(wj ). Naturally, as t increases, we need to consider more potential deposit transactions, thus, increasing the algorithm’s running time, cf. Table 2. Bucket size b The dynamic programming algorithm builds a matrix of dimension n × C/b, where n is the number of deposits in our time-window, C = amt(wj ), and b is the bucket size. Recall our knapsack equation in Equation (4), thus, we have that the error term is ε = b/2. As expected, the larger the bucket is, the faster the algorithm runs (cf. Table 2). However, it produces more precise deanonymization results, it incurs higher anonymity loss for Railgun users cf. Figure 22. We observe that running knapsack solver algorithms for reasonable choices of time-window and bucket sizes is completely feasible already on a consumer laptop. We only experienced out-of-memory issues for the all-time and 10−5 ETH bucket size parameters. We expect that any well-motivated and more funded blockchain analyst (e.g., , government-supported agencies, private blockchain analysis companies (Chainalysis1 , TRM labs2 ), etc.) could run various knapsack/SMT solvers on Railgun for k-to-2 deposits-to-withdraw matchings or perhaps even for k-to-3 deposits-to-withdraw matchings. Table 2 Witness-enumeration runtime per cell, i.e., deposit or withdraw, (cap K = 2000 matching subsets, witness DFS in C, multi-process pool). Each cell processes all |supp(D)| = 29,307 shields (1-to-k) or |supp(W)| = 38,472 unshields (k-to-1). The all-time 10−5 ETH bucket is skipped on both sides: it would require ∼ 50 GiB per worker that is not supported by our limited experimental setup. Bucket size (b ETH) 10−2
Time window (t days)
10−3
10−4
10−5
(a) 1-to-k direction (laptop, Intel Core Ultra 7 155U, 19 GiB WSL RAM) 3 days 7 days 30 days 180 days all-time
0.9 s 2.5 s 4.7 s 22.4 s 1 min 15 s
2.1 s 3.5 s 10.5 s 56.7 s 2 min 34 s
6.8 s 10.1 s 36.3 s 4 min 41 s 15 min 41 s
44.7 s 1 min 14 s 6 min 36 s 1 h 12 min 45 s — (skip)
(b) k-to-1 direction (laptop, Intel Core Ultra 7 155U, 19 GiB WSL RAM) 3 days 7 days 30 days 180 days all-time
0.9 s 1.2 s 2.4 s 12.0 s 24.8 s
1.2 s 1.9 s 4.6 s 20.1 s 57.1 s
2.4 s 4.7 s 20.7 s 1 min 50 s 7 min 46 s
21.6 s 49.0 s 4 min 56 s 34 min 24 s — (skip)
In Figure 21 we study the capabilities of knapsack solver algorithms to decrease the anonymity guarantees of Railgun. For each withdraw wj , we take the optimistic anonymity measure as the Shannon entropy of the distribution that assigns equal probabilities to all prior deposit transactions, cf. Definition 3. In contrast, we applied our adaptation of Pisinger’s algorithm to amt(wj ). Typically, the algorithm outputs several candidate solutions for a
1 2
See: https://www.chainalysis.com/ See: https://www.trmlabs.com/
Huseynov et al.
23:15
# Deposits
1,000
500
0 100
200
300
400
500
600
700
800
900
999
700
800
900
999
# Withdrawals
(a) Deposit amounts grouped by first 3 fractional digits (000–999) 3,000 2,000 1,000 0 100
200
300
400
500
600
(b) Withdrawal amounts grouped by first 3 fractional digits (000–999)
Figure 9 Distribution of deposit and withdrawal amounts by the first three fractional digits.
given withdraw amount amt(wj ). We count how many times each deposit di appears in the candidate solutions produced by Pisinger’s algorithm. We convert these frequencies into a probability distribution and take its Shannon entropy to measure the reduced anonymity guarantees provided by our knapsack solver algorithm. For instance, in Figure 21, we find that for the parameters (t, b) = (30 days, 10−5 ETH), the median anonymity loss for withdrawals is 3.42 bits of entropy. For this parameter set, the knapsack solver algorithm has found 85 withdraw transactions to which there is a single subset of deposit transactions that sum up exactly to amt(wj ).
5.6
Heuristic 5: Amount Fingerprints
1
0.5
Deposits (|D| = 31 523) Withdrawals (|W| = 45 071)
0 0
500
1,000
3-digit fractional fingerprint (0–999) (a) Empirical cumulative distribution functions (CDF)
|CDFdep (x) − CDFwit (x)|
Empirical CDF
Finally, we examine whether deposit and withdraw transaction amounts themselves leave fingerprints usable for deanonymization. In particular, we look at the distribution of the first three digits after the decimal point for both deposit and withdrawal amounts cf. Figure 9.
·10−2 6 4 2
KS statistic = 0.0608
0 0
500
1,000
3-digit fractional fingerprint (0–999) (b) CDF difference
Figure 10 Kolmogorov–Smirnov test (KS-stat=0.0608, p = 3.95 × 10−60 ) for fractional-digit deposit and withdraw amount fingerprints, cf. Figure 9. The KS-test rejects the null-hypothesis.
CVIT 2016
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
As the histogram in Figure 9 shows, the distribution of fractional fingerprints is highly skewed: a small number of round-number fingerprints (e.g., all zeros) are extremely common, while the majority of fingerprints appear only a handful of times. This confirms that deposit and withdrawal amounts are not random decimal strings. We also experimented with using such amount fingerprints for deanonymization. However, large-value patterns are already largely captured by the knapsack heuristic, while the least significant digits of small amounts are likely obscured by transaction costs and gas-price choices, which are not observable from the shielded-pool amounts alone. We therefore did not find fractional amount fingerprints sufficiently reliable for deanonymization. Nevertheless, Figure 9 provides a useful diagnostic view of the empirical distribution of the first three fractional digits. To further inspect this effect, we compare deposit–withdraw transaction amount pairs with small Hamming distance as decimal strings. Figure 11 shows that these pairs often share long common substrings (typically 11–14 digits), and that the most frequent maximal non-zero substrings are dominated by round-denomination patterns (e.g., long runs of zeros after a small leading digit). Overall, amount strings exhibit structure, but it is driven mainly by global denomination/rounding effects rather than stable user-specific fingerprints. Consequently, beyond the knapsack signal, the remaining low-order digits are too noisy for reliable standalone deanonymization.
#(amt(di ), amt(wj ))
23:16
5000000000000 500000000000 50000000000000 50000000000 7500000000000 75000000000000 500000000000000 5000000000 2500000000000 50000000 750000000000 750000000000000 25000000000000 500000000 5000000 250000000000 5000000000000000 75000000000 500 250000000000000
1.6 1.4 1.2 1.0 0.8 0.6 0.4 0.2 0.0 0
5
10
15
Longest common substring (LCS) length
0
2 · 105
4 · 105
6 · 105
#(amt(di ), amt(wj )) pairs
(a) LCS length distribution low-Hamming pairs, i.e.,(b) Top 20 most common maximal non-zero substrings d(amt(di ), amt(wj )) ≤ 10 low-Hamming pairs, i.e., d(amt(di ), amt(wj )) ≤ 10
Figure 11 Longest common subsequence length distribution (left) and the most common maximal non-zero substrings among low-Hamming deposit-withdraw transaction amount pairs (right).
We further tested whether these fractional-digit patterns provide a robust signal. The Kolmogorov–Smirnov test in Figure 10 indicates that the empirical distributions of deposit and withdrawal transaction amount fingerprints are statistically distinguishable. However, this difference is mainly driven by global rounding and denomination effects, rather than by stable pair-specific fingerprints. The Hamming-distance diagnostics in Figure 14 –17 support the same conclusion. Lowdistance deposit–withdraw pairs do exist, and their differences are concentrated towards later fractional positions, while early fractional digits often agree. Moreover, unique common substrings are typically short, with most value-fingerprint substrings appearing at lengths around four to six digits. Overall, these patterns confirm that amount strings contain structure, but we did not find this structure sufficiently specific or stable to serve as an independent deanonymization heuristic beyond the knapsack-based analysis.
Huseynov et al.
23:17
Set
Cardinality
W D supp(W) supp(D) H1 (address reuse) of which PPOI-flagged H2 (direct tx link) H1∪H2 H3 (gas payer reuse) H1∪H2∪H3 H4 (knapsack matching)
47 596 34 747 38 472 29 307 2904 (6.10%) 710 (1.49%) 4272 (8.98%) 6003 (12.61%) 1049 (2.20%) 6715 (14.11%) 2097 (4.41%)
Total (H1∪H2∪H3∪H4)
8398 (17.65%)
Table 3 Summary of our findings. Cardinalities are counted at the raw unshield event level (one entry per filtered unshield in W); percentages are relative to |W| = 47,596. H1–H3 apply the event-level causal rule from Section 4; H4 is the union over all 5 × 4 knapsack cells of the k-to-1 witness pass of unshield super-rows whose matching subsets implicate a single depositor address (Hknap,addr = 0), expanded to raw events via w_agg_size.
5.7
Summary of Our Results
We provide an overview of all our heuristic findings in Table 3. We observe that H2 produces the largest number of heuristic deposit-withdraw links. Altogether, we find that the first four heuristics link 17.65% of all Ethereum L1 Railgun withdraws. Note that these are only the one-to-one links (di ↔ wj ) output by our heuristics. We study the probabilistic (i.e., non-unique) deposit-withdraw links and anonymity loss incurred by the knapsack matching Heuristic in Figures 21 and 22.
5.8
Privacy Recommendations
Our findings point directly to actionable recommendations for users who wish to obtain stronger privacy guarantees from Railgun. We organize these by the heuristic they address. Always use a relayer (H3). The single most impactful recommendation is to always use a third-party relayer when issuing withdraw transactions. Among the 6856 self-broadcast withdraw transactions in our dataset, 5175 were sent from an address distinct from the withdraw recipient, and 1049 of those gas-payer addresses were also depositor addresses, making them immediately linkable via H3. A relayer’s address is independent of the user’s deposit and withdraw addresses, eliminating this leakage channel entirely. Our broadcaster cluster analysis identified 124 active relayer-like addresses that together serve 89.12% of all relayed volume, so relayer availability is not a practical obstacle. Users should prefer relayers that have served a large number of distinct recipients, as these provide larger anonymity sets. Never reuse deposit and withdraw addresses (H1). H1 is the only heuristic that produces zero false positives by construction: if the same Ethereum address appears on both sides of the shielded pool, the link is certain. Yet 2904 (6.10%) of unshield events in our dataset reuse a known deposit address. Users should generate a fresh Ethereum address for every withdraw transaction and should never fund that address from a known deposit address prior to withdrawing. Avoid direct on-chain transactions between deposit and withdraw addresses (H2).
CVIT 2016
23:18
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
H2 identifies 4272 (8.98%) of unshield events via at least one on-chain transaction between the deposit and withdraw address. The most common pattern is users topping up a withdraw address with ETH from their deposit address to cover gas fees — a problem that is fully solved by using a relayer (see above). Users should treat the deposit address and the withdraw address as completely disjoint identities with no on-chain contact between them, not even through intermediary contracts or decentralized exchanges. Wait longer before withdrawing (timing). The median deposit-to-withdraw interval for H1-identified pairs is only 0.84 days. A withdrawal that occurs minutes or hours after a deposit has a very small effective anonymity set, regardless of the pool’s nominal size. Users who are genuinely concerned about their financial privacy should leave funds in the shielded pool for weeks or months, during which the pool accumulates additional deposits that expand their anonymity set. Our Little’s Law estimate suggests a characteristic pool residence time of roughly 183 days for the average deposited ETH; users who withdraw much faster than this are outliers and more easily identified. Avoid psychologically salient or round amounts (H4, H5). H4 exploits knapsack relationships between deposit and withdraw amounts. H5 exploits the fact that users tend to preserve distinctive digit patterns across transactions. Both heuristics are rendered ineffective if the amounts that enter and leave the shielded pool bear no predictable relationship to each other. In practice, this means: avoid withdrawing exactly the amount deposited; avoid splitting or merging deposits in simple integer ratios; and avoid depositing amounts with highly distinctive fractional digits (e.g., 1.234 567 ETH) that are unlikely to be destroyed by internal transactions or swap fees. Ideally, users should perform at least one internal transaction or private swap between depositing and withdrawing, so that the amount that ultimately leaves the pool bears no simple arithmetic relationship to the deposited amount. Use the full functionality of the shielded pool. We saw that 15.00% of deposited ETH remains in the shielded pool as of our measurement date, and that internal transactions are actively used (17 767 internal transfers over the observation period). Users who perform internal transactions and private swaps before withdrawing are more resistant to H4 and H5, since these operations transform the amount in ways that break simple arithmetic linkages. Importantly, users who leave funds in the pool for longer periods contribute to a larger anonymity set for all participants. Privacy in a shielded pool is a public good, and short-cycling users who deposit and immediately withdraw not only expose themselves but also reduce the privacy of other users by shrinking the effective anonymity set. Protocol-level recommendations. Beyond individual user behavior, our findings suggest several design-level improvements that the Railgun protocol could adopt to reduce behavioral leakage. First, the protocol could enforce a minimum residence time or introduce timelocked notes, making rapid deposit-withdraw cycling impossible. Second, Railgun could follow Tornado Cash’s model of offering fixed denomination tiers as an option, which would eliminate H4 and H5 for users who opt into that mode. Third, the relayer infrastructure could be improved to make relayer selection more uniform across the broadcaster population, reducing the fingerprinting potential of relayer choice patterns. We leave the formal analysis of the privacy improvements achievable by such protocol modifications to future work.
6
Related Work
Cryptocurrency transaction graph analysis has extensive literature [17, 23, 33, 34]. Many works apply machine learning tools in the context of enforcing KYC/AML regulations or
Huseynov et al.
23:19
extracting intelligence from public transaction graphs [21, 10, 41]. Next, we focus only on the literature on the deanonymization of privacy-enhancing tools on top of various blockchains.
6.1
Deanonymization of Bitcoin mixers
The earliest work on breaking unlinkability in Bitcoin focused on CoinJoin [15, 28], which merges the inputs of multiple users into a single transaction [8]. Möser et al. [18] showed that the small anonymity sets typical of deployed CoinJoin implementations allow a substantial fraction of transactions to be deanonymized. Later work identified address reuse, amount clustering, and transaction graph structure as dominant leakage channels [4, 9]. More recent large-scale empirical analyses of decentralized CoinJoin services, including Wasabi and Samourai, showed that even when the mixing transaction itself provides a larger nominal anonymity set, privacy can be substantially reduced by pre- and post-mixing behavior [30], address-selection patterns, and subsequent flows to exchanges [29].
6.2
Tornado Cash
The closest prior work to ours is the empirical analysis of Tornado Cash by Béres et al. [1], which introduced several of the heuristics we adapt and extend, including address reuse, direct transactional linkage, and value fingerprinting via the Danaan-gift attack. Wu et al. developed Tutela [42], an open-source tool that operationalizes these heuristics. Wang et al. [38] studied how zero-knowledge proof mixers improve and worsen user privacy, finding that optional shielding creates self-selection biases that reduce the effective anonymity set. Tang et al. [31] analyzed address linkability in Tornado Cash specifically. Our work differs in focusing on Railgun, which offers richer in-pool functionality and supports arbitrary token amounts, creating new leakage channels not present in fixed-denomination mixers. Complementary to deanonymization work, Wang et al. [39] studied the cost side of onchain mixers, showing how Tornado-Cash-like privacy pools can be made more cost-effective. While their focus is mixer design and transaction cost, our work studies the residual privacy loss that arises from user behavior and amount-level leakage in a richer shielded-pool setting.
6.3
Monero, Zcash
Möser et al. [19] provided a large-scale empirical analysis of traceability in Monero, showing that the zero-mixin era and subsequent hard forks introduced significant traceability. Temporal correlation attacks on ring member selection have been studied analytically, showing that non-uniform ring sampling degrades anonymity substantially [44]. These results parallel our findings: the practical anonymity set is often smaller than the nominal cryptographic set. Ye et al. [43] studied traceability in Zcash’s shielded pool, finding that founder and miner withdrawal behavior follows recognizable periodic patterns that reduce the effective anonymity of their transactions. The general lesson — that behavioral regularity defeats cryptographic privacy [2, 3, 12] — directly motivates our work.
6.4
Network-layer deanonymization
Several works have studied privacy attacks at the network layer rather than the blockchain layer. Biryukov et al. [4] exploited P2P connection patterns to link IP addresses to Bitcoin addresses. Heimbach et al. [11] applied similar techniques to Ethereum. Wang et al. [37] demonstrated a timing-correlation attack against RPC users achieving over 95% success rate.
CVIT 2016
23:20
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
Our work is complementary: we restrict ourselves to on-chain data, and our heuristics could be combined with network-layer observations for stronger deanonymization.
6.5
Wallet and gas fingerprinting
Soleti et al. [27] demonstrated that wallet software of Ethereum users can be identified from gas-pricing strategies, providing a fingerprint orthogonal to the amount and timing features we study. We leave the combination of wallet fingerprints with our heuristics to future work.
7
Conclusion and Future Directions
This work quantitatively assessed the practical privacy guarantees of Railgun users. We found that 17.65% of Railgun withdraw transactions can be heuristically linked to a single deposit transaction. However, we believe that in reality, the actual achieved privacy guarantees are even weaker due to the multiple layers (network, application, etc.) and heuristics we have not studied in this paper. We foresee the following fruitful directions for future work. Wallet fingerprints We did not exploit many types of metadata, i.e., typically it is possible to assess which wallet software an entity uses. For instance, different wallets use various algorithms to compute their applied transaction fees. These wallet gas fingerprints [27] could be used to further decrease the empirical Railgun anonymity set. Graph-embedding tools We did not apply machine learning tools to learn the Ethereum transaction graph [1] and use it to link deposit and withdraw addresses. Multi-layered privacy analysis So far, this paper has only focused on the Ethereum blockchain data. A more resourceful privacy analysis should take full advantage of network [11], application [32], cross-chain and other leakages as well. One may even consider “active” privacy attacks, e.g., when the adversary is one of the Railgun relayers or users. Acknowledgements István András Seres was supported by the Ministry of Culture and Innovation and the National Research, Development, and Innovation Office (NKFIH) within the Quantum Information National Laboratory of Hungary (Grant No. 2022-2.1.1-NL-202200004). János Tapolcai was supported by Grant No. K_23 146347 of NKFIH. References 1
2 3
4
5
6
Ferenc Béres, István A Seres, András A Benczúr, and Mikerah Quintyne-Collins. Blockchain is watching you: Profiling and deanonymizing ethereum users. In IEEE international conference on decentralized applications and infrastructures (DAPPS), pages 69–78. IEEE, 2021. Alex Biryukov and Daniel Feher. Deanonymization of hidden transactions in zcash, 2018. Alex Biryukov, Daniel Feher, and Giuseppe Vitto. Privacy aspects and subliminal channels in zcash. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, pages 1813–1830, 2019. Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. Deanonymisation of clients in Bitcoin P2P network. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 15–29. ACM, 2014. Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schär, and Ameen Soleimani. Blockchain privacy and regulatory compliance: Towards a practical equilibrium. Blockchain: Research and Applications, 5(1):100176, 2024. Nicolas T Courtois and Rebekah Mercer. Stealth address and key management techniques in blockchain systems. In ICISSP 2017-Proceedings of the 3rd International Conference on Information Systems Security and Privacy, pages 559–566, 2017.
Huseynov et al.
7 8
9
10
11
12
13
14 15 16 17
18
19
20 21 22 23 24 25
23:21
Claudia Diaz, Stefaan Seys, Joris Claessens, and Bart Preneel. Towards measuring anonymity. In International Workshop on Privacy Enhancing Technologies, pages 54–68. Springer, 2002. Jiří Gavenda, Petr Svenda, Stanislav Bobon, and Vladimir Sedlacek. Analysis of input-output mappings in coinjoin transactions with arbitrary values. arXiv preprint arXiv:2510.17284, 2025. URL: https://arxiv.org/abs/2510.17284. Steven Goldfeder, Harry Kalodner, Dillon Reisman, and Arvind Narayanan. When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies. In Proceedings on Privacy Enhancing Technologies (PoPETs), pages 179–199, 2018. Matan Harlev, Hsiao-Wei Sun Yin, Kai Langenheldt, Ram Mukkamala, and Ravi Vatrapu. Breaking bad: De-anonymising entity types on the bitcoin blockchain using supervised machine learning. In HICSS, 2018. Lioba Heimbach, Yann Vonlanthen, Juan Villacis, Lucianna Kiffer, and Roger Wattenhofer. Deanonymizing ethereum validators: The P2P network has a privacy issue. In 34th USENIX Security Symposium (USENIX Security 25), pages 1319–1338, 2025. George Kappos, Haaroon Yousaf, Mary Maller, and Sarah Meiklejohn. An empirical analysis of anonymity in zcash. In 27th {USENIX} Security Symposium ({USENIX} Security 18), pages 463–477, 2018. Richard M Karp. Reducibility among combinatorial problems. In 50 Years of Integer Programming 1958-2008: from the Early Years to the State-of-the-Art, pages 219–241. Springer, 2009. John DC Little. A proof for the queuing formula: L= λ w. Operations research, 9(3):383–387, 1961. Gregory Maxwell. CoinJoin: Bitcoin privacy for the real world, 2013. BitcoinTalk forum post. URL: https://bitcointalk.org/index.php?topic=279249.0. Sarah Meiklejohn and Rebekah Mercer. Möbius: Trustless tumbling for transaction privacy. Proceedings on Privacy Enhancing Technologies, 2018(2):105–121, 2018. Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M Voelker, and Stefan Savage. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference, pages 127–140, 2013. Malte Möser, Rainer Böhme, and Dominic Breuker. An empirical analysis of traceability in Bitcoin’s transaction graph. In Proceedings of the 1st Workshop on Bitcoin Research (BITCOIN), 2014. Also published as: Möser et al., “Anonymous alone? Measuring Bitcoin’s second-generation anonymization techniques,” IEEE EuroS&PW 2017. Malte Möser, Kyle Soska, Ethan Heilman, Kevin Lee, Henry Heffan, Shashvat Srivastava, Kyle Hogan, Jason Hennessey, Andrew Miller, Arvind Narayanan, et al. An empirical analysis of traceability in the monero blockchain. Proceedings on Privacy Enhancing Technologies, 2018(3):143–163, 2018. Alexey Pertsev, Roman Semenov, and Roman Storm. Tornado cash privacy solution, 2019. URL: https://tornado.cash. Thai-Thanh Pham and Sungroh Lee. Anomaly detection in bitcoin network using unsupervised learning methods. arXiv preprint arXiv:1611.03942, 2016. Pisinger. Dynamic programming on the word ram. Algorithmica, 35(2):128–145, 2003. Dorit Ron and Adi Shamir. Quantitative analysis of the full bitcoin transaction graph. Financial Cryptography and Data Security, 2013. István András Seres. On blockchain metatransactions. In 2020 IEEE international conference on blockchain (Blockchain), pages 178–187. IEEE, 2020. István András Seres, Dániel A Nagy, Chris Buckland, and Péter Burcsi. Mixeth: efficient, trustless coin mixing service for ethereum. In International Conference on Blockchain Economics, Security and Protocols (Tokenomics 2019). Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2019.
CVIT 2016
23:22
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
26 27
28
29
30
31
32
33
34 35 36
37
38
39
40
41
42
Andrei Serjantov and George Danezis. Towards an information theoretic metric for anonymity. In International Workshop on Privacy Enhancing Technologies, pages 41–53. Springer, 2002. Martina Soleti, Ankit Gangwal, and Mauro Conti. Attacking anonymity set in tornado cash via wallet fingerprints. In Proceedings of the 40th ACM/SIGAPP Symposium on Applied Computing, pages 376–385, 2025. Johann Stockinger, Bernhard Haslhofer, Pedro Moreno-Sanchez, and Matteo Maffei. Pinpointing and measuring wasabi and samourai coinjoins in the bitcoin ecosystem. arXiv preprint arXiv:2109.10229, 2021. URL: https://arxiv.org/abs/2109.10229. Rainer Stütz, Johann Stockinger, Pedro Moreno-Sanchez, Bernhard Haslhofer, and Matteo Maffei. Adoption and actual privacy of decentralized coinjoin implementations in bitcoin. In Proceedings of the 4th ACM Conference on Advances in Financial Technologies, pages 254–267, 2022. Petr Svenda, Jiří Gavenda, Vasilios Mavroudis, and Chris Hicks. Coinjoin ecosystem insights for wasabi 1.x, wasabi 2.x and whirlpool coordinator-based privacy mixers. Proceedings on Privacy Enhancing Technologies, 2026(2):557–592, 2026. doi:10.56553/popets-2026-0061. Yajin Tang, Chenxu Xu, Chao Zhang, Yajin Wu, and Liehuang Zhu. Analysis of address linkability in Tornado Cash on Ethereum. In China Cyber Security Annual Conference (CCSAC), pages 39–50. Springer, 2021. Christof Ferreira Torres, Fiona Willi, and Shweta Shinde. Is your wallet snitching on you? an analysis on the privacy implications of web3. In 32nd USENIX Security Symposium (USENIX Security 23), pages 769–786, 2023. Friedhelm Victor and Bianca Katharina Lüders. Measuring ethereum-based erc20 token networks. In International Conference on Financial Cryptography and Data Security, pages 113–129. Springer, 2019. Friedhelm Victor and Tina Weintraud. Detecting and quantifying wash trading on decentralized cryptocurrency exchanges. In Proceedings of The Web Conference, 2021. Isabel Wagner and David Eckhoff. Technical privacy metrics: a systematic survey. ACM Computing Surveys (Csur), 51(3):1–38, 2018. Anton Wahrstätter, Jens Ernstberger, Aviv Yaish, Liyi Zhou, Kaihua Qin, Taro Tsuchiya, Sebastian Steinhorst, Davor Svetinovic, Nicolas Christin, Mikolaj Barczentewicz, et al. Blockchain censorship. In Proceedings of the ACM Web Conference 2024, pages 1632–1643, 2024. Shan Wang, Ming Yang, Yu Liu, Yue Zhang, Shuaiqing Zhang, Zhen Ling, Jiannong Cao, and Xinwen Fu. Time tells all: Deanonymization of blockchain rpc users with zero transaction fee. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 3490–3504, 2025. Zhipeng Wang, Stefanos Chaliasos, Kaihua Qin, Liyi Zhou, Lifeng Gao, Pascal Berrang, Benjamin Livshits, and Arthur Gervais. On how zero-knowledge proof blockchain mixers improve, and worsen user privacy. In Proceedings of the ACM Web Conference 2023, pages 2022–2032, 2023. Zhipeng Wang, Marko Cirkovic, Duc V Le, William Knottenbelt, and Christian Cachin. Pay less for your privacy: Towards cost-effective on-chain mixers. In 5th Conference on Advances in Financial Technologies (AFT 2023), pages 16–1. Schloss Dagstuhl–Leibniz-Zentrum für Informatik, 2023. Zhipeng Wang, Xihan Xiong, and William J Knottenbelt. Blockchain transaction censorship:(in) secure and (in) efficient? In The International Conference on Mathematical Research for Blockchain Economy, pages 78–94. Springer, 2023. Mark Weber, Giulia Domeniconi, Jie Chen, Daniel Weidele, Claudio Bellei, Tom Robinson, and Charles Leiserson. Anti-money laundering in bitcoin: Experimenting with graph convolutional networks for financial forensics. In KDD Workshop on Anomaly Detection in Finance, 2019. Mike Wu, Will McTighe, Kaili Wang, Istvan A Seres, Nick Bax, Manuel Puebla, Mariano Mendez, Federico Carrone, Tomás De Mattey, Herman O Demaestri, et al. Tutela: An
Huseynov et al.
43 44
A
23:23
open-source tool for assessing user-privacy on ethereum and tornado cash. arXiv preprint arXiv:2201.06811, 2022. Claire Ye, Chinedu Ojukwu, Anthony Hsu, and Ruiqi Hu. Alt-coin traceability. Cryptology ePrint Archive, Report 2020/593, 2020. URL: https://eprint.iacr.org/2020/593. Zuoxia Yu, Man Ho Au, Jiangshan Yu, Rupeng Yang, Qiuliang Xu, and Wang Fat Lau. New empirical traceability analysis of CryptoNote-style blockchains. In Financial Cryptography and Data Security (FC 2019), pages 133–149. Springer, 2019.
Additional Measurements
#Transactions
Due to space constraints, we enclose many of our measurements in this section.
4,000 3,000
3, 620 3, 568 3, 139
All-time (baseline) Post-2023 sensitivity
2, 864
2,000
1, 253 1, 187 789
1,000
735
0 ETH D → W
ETH W → D
ERC-20 D → W
ERC-20 W → D
Asset and direction Figure 12 The prevalence of transactions across depositor (D) and withdrawer (W) addresses motivates the formulation of Heuristic 2, cf. Section 4.2.
CVIT 2016
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
WETH → USDC USDC → WETH WETH → USDT USDT → WETH DAI → WETH WETH → WBTC WETH → RAIL WETH → DAI WETH → ZKMEME APU → WETH RAIL → WETH WBTC → WETH WETH → CRVUSD JOE → WETH ZKMEME → WETH WETH → JOE WETH → DOG WETH → APU CRVUSD → WETH FLUID → WETH
745 518 451 282 132 122 118 100 79 69 67 49 35 32 28 28 22 19 15 10 0
100
200
300
400
500
600
700
800
Swap transactions
(a) Token pairs, top 20, n = 3,133 1, 726
uniswap pancakeswap fluid curve sushiswap maverick balancer defiswap shibaswap
430 401 268 184 84 26 11 3 0
400
800
1, 200
1, 600
2, 000
Swap transactions
(b) DEX venues, top 10
Figure 13 Swap transaction usage statistics. Majority of Railgun swap transactions are settled on Uniswap. The most popular trading pair is the WETH-USDC pair.
·106
Frequency
23:24
Observed Scaled Trunc-Binom(18, 0.9)
8 6 4 2 0 0
2
4
6
8
10
12
14
16
18
Hamming Distance d(amt(di ), amt(wj )) Figure 14 Histogram of hamming distances for deposit-withdraw transaction amounts.
Huseynov et al.
23:25
# pairs
·106 6 5 4 3 2 1 0 0
2
4
6
8
10
12
14
16
18
Digit position (0..17; left→right in zero-padded string)
P(match) for low-distance pairs
Figure 15 Differing Positions for Pairs with Hamming Distance at Most 10
1 0.8 0.6 0.4 0.2 0 0
2
4
6
8
10
12
14
16
18
Fractional digit index i (0 = first digit after decimal)
# Unique Substrings
Figure 16 Fractional Digit Agreement Probability for low-distance pairs (Hamming distance ≤ 10)
1,000
500
0 2
4
6
8
10
12
14
16
18
Substring Length
#Transactions
Figure 17 Length Distribution of Value-Fingerprint Substrings (appear in exactly 1 low-Hamming pair)
4,000
Deposits Withdrawals Internal Transactions
2,000 0 2023
2024
2025
Calendar year Figure 18 Weekly Number of Deposit, Withdraw and Internal Transactions to Railgun Pool
CVIT 2016
# Withdrawal fingerprints
# Withdrawal fingerprints
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
1
10
100 100
101
102
103
60 40 20 0 0
10
20
# Deposits sharing the same 3-digit fingerprint # Deposits sharing the same 3-digit fingerprint (a) Full range
(b) Zoomed: 0–20
Figure 19 Overlap Between Withdrawal Fingerprints and Deposits
·104
·104 3
#Internal txs
#Internal txs
23:26
2 1 0
2 1 0
1
2
(a) #Input notes
3
4
5
6
7+
0
1
2
3
4
5
6
7+
(b) #Output notes
Figure 20 Number of input and output notes in Railgun internal transactions.
Huseynov et al.
23:27
5
0
10
5
0
0 5 10 log2 (# pool addrs) [bits]
5
0
0 5 10 log2 (# pool addrs) [bits]
0 5 10 log2 (# pool addrs) [bits]
102
step = 0.00001 ETH median ∆H = 3.42 bits
Hknap,addr [bits]
Hknap,addr [bits]
step = 0.0001 ETH median ∆H = 3.56 bits
10
103
10
# deposit transactions
10
step = 0.001 ETH median ∆H = 3.68 bits
Hknap,addr [bits]
Hknap,addr [bits]
step = 0.01 ETH median ∆H = 3.59 bits
101 5
0
0 5 10 log2 (# pool addrs) [bits] 100
Figure 21 Entropy reduction heatmap due to Heuristic 4 (knapsack matching). The knapsack solver algorithm is run for t = 30 days and for various bucket sizes b ∈ {0.01, 0.001, 0.0001, 0.00001} (k-to-1, 30-day window).
CVIT 2016
A Tattered Cloak of Invisibility: Measuring Anonymity Loss in Railgun on Ethereum
step = 0.01 ETH median ∆H = 3.59 bits full deanon = 229
step = 0.001 ETH median ∆H = 3.68 bits full deanon = 66
3,000 # deposits
# deposits
3,000 2,000 1,000 0
0
2
4 ∆H [bits]
2,000 1,000 0
6
0
4 ∆H [bits]
6
3,000 # deposits
3,000 2,000 1,000 0
2
step = 0.00001 ETH median ∆H = 3.42 bits full deanon = 85
step = 0.0001 ETH median ∆H = 3.56 bits full deanon = 44
# deposits
23:28
0
2
4 ∆H [bits]
6
2,000 1,000 0
0
2
4 ∆H [bits]
6
Figure 22 Entropy reduction histogram (k-to-1, 30-day window). The orange components of the stacked bars correspond to deposits that are fully deanonymized by the knapsack heuristic, i.e., Hknap = 0. The dashed vertical lines indicate the median entropy reduction.