arXiv CSopen access

The Anatomy of Address Poisoning on Ethereum: Funding Mechanisms, Scam Signatures, and Laundering via Tornado Cash

arXiv:2609.23405v1 [cs.CR] 20 Sep 2026

The Anatomy of Address Poisoning on Ethereum: Funding Mechanisms, Scam Signatures, and Laundering via Tornado Cash Son Hoang Dau RMIT University

Thanh Nguyen RMIT University

Phuong Duy Huynh RMIT University

Hong Yen Tran CSIRO

Nicholas Huppert RMIT University

Jeff Nijsse RMIT University

Huong Ha RMIT University

Xun Yi RMIT University

Abstract

intended address [4]. In another major incident, the victim lost 2,000 ETH (about $4.4 million) after receiving several fake-token transfers (see Example 16). Existing work on APT scams focuses primarily on scam detection and victim analysis [7, 15, 23, 29]. This leaves several critical questions insufficiently explored, such as: What behavioural patterns are exhibited by scam addresses? How does scam funding operate? And to what extent are scam funding and proceed laundering carried out via public services like Tornado Cash? To address these gaps, we take a step toward a more comprehensive understanding of APT scams by examining three key aspects: scam funding mechanisms, scam signatures, and scam proceeds laundering. For scam funding mechanisms, we first establish a comprehensive classification of eleven types of APTs (see Fig. 3), instead of three types as in the literature. Then, based on this finer classification, we describe the funding mechanism for each APT type, noting that different APT types require different funding mechanisms (Sections 3, 4). For instance, while a phishing address deploying coin APTs (where APTs are in ETH) consistently requires a coin funder, an address deploying genuine-token APTs may not. Coin funding is only necessary if the token amount is nonzero, requiring ETH to approve a contract to spend tokens on its behalf, or if the address initiates the APT itself, requiring ETH to cover transaction fees. Equipped with new insights into APT scams, particularly their funding and attack mechanisms, we introduce five sets of scam signatures tailored to APT scams (Section 5). These signatures capture: (i) the contracts created and invoked by scam addresses, (ii) APT-value patterns, (iii) the relationships among funding values, APT values, and transaction fees, (iv) gas configurations used in APT-carrying transactions, and (v) the use of public services by scam addresses. Scam signatures are important because they could potentially provide evidence that seemingly distinct scam activities are likely operated by the same scammer group. For example, in the scam cluster shown in Fig. 1, beyond the explicit linkage via ETH transfers (an indicator largely overlooked in the APT literature), we observe consistent behavioural patterns:

Address-Poisoning Transfer (APT) is a prevalent blockchain phishing scam in which a scammer poisons a victim’s address book by generating a transfer with a phishing address that looks similar to a benign address that the victim has previously interacted with. Although simple, APT phishing attacks have cost users millions of dollars in recent years, which has captured the attention of the research community (Ye et al. WWW’24, Guan-Li CCS’24, Chen et al. NDSS’25, Tsuchiya et al. USENIX’25). In this work, we go beyond detection and investigate three important and underexplored aspects of APT: scam funding mechanisms, scam signatures, and scam proceeds laundering via public services. In particular, we propose five families of scam signatures that capture key aspects of APT operations, which are useful for address clustering. We also conduct the first investigation into usage of Tornado Cash for funding APTs and laundering scam proceeds.

1

Introduction

Global crypto scam revenue surpassed $10 billion in 2021 and has continued to rise steadily according to the Chainalysis 2025 Crypto Crime Report [6]. Ranked fifth among all scams in 2024 revenue by Chainalysis, Address-Poisoning Transfer (APT) is a widespread scam (see, e.g. [1, 4]) that exploits a combination of human’s limitations in remembering long address strings, their copy-and-paste habit, and the fact that most digital wallets only display the first and last few digits of their addresses. Also referred to as dust-value transfer (DVT), in its simplest form the scammer generates a phishing address p that looks similar to a benign address b that the victim address v has previously interacted with and transfers a tiny amount of a high-value token from p to v, hoping that the victim would later mistakenly transfer funds to p instead of the intended address. For example, a notable DVT scam occurred in May 2024 in which a crypto whale mistakenly transferred 1,155 WBTC (about $70 million) to a phishing address, which has the first four and the last five digits identical to the victim’s 1

Figure 1: An APT scam cluster with distinctive patterns: distributor-master-phishing funding hierarchy, distributors funding masters via 1inch or ETH transfers, APT amounts consistently in [10−6 , 10−5 ). Notably, the phishing address 0x4f512487a746 AB1638B5fFb0D8321dBDFA6Fb8eA, after receiving 50 ETH from a victim, reinvested by funding other distributors/masters. The master 0x03CEc7583846EEEe04cDd0752A0B35bC8F793bff, besides funding phishing addresses, sent 10 ETH via Tornado Cash to a distributor 0x306608Bf57e58A1263c491aD81b1A5fA2B420cfd, which then started a new cluster with an identical pattern.

2

these addresses repeatedly use 1inch to route funds to the funders of phishing addresses, and the APT amounts consistently contain exactly five zeroes after the decimal point. Such signatures could also be useful in tracing through mixers like Tornado Cash when these behavioural patterns persist.

Background and Data Collection

Ethereum. Launched in 2015, Ethereum is a decentralised blockchain that enables the creation of smart contracts that are capable of executing business logic [2]. The ERC-20 standard defines an interface for smart contracts to issue fungible tokens, ensuring interoperability between decentralised applications and various virtual assets, including shares, stablecoins, and user generated tokens. Each ERC-20 token has a name, e.g. Tether USDT, a symbol, e.g. USDT, and a contract address of its smart contract. Ethereum assets can be transferred in two main ways: by transferring the native currency ether (ETH), referred to as coin transfers, or by transferring ERC-20 tokens. One can also swap one asset for another via a Centralised Exchange (CEX) or a decentralised Exchange (DEX). Every transaction requires a digital signature associated with a unique Ethereum address through the user’s wallet. All transactions and associated wallet balances are publicly viewable on-chain, making it possible to trace transactions and limit privacy. Tornado Cash [21] was developed as a decentralised privacy protocol that allows users to unlink the origin and destination of their transactions, by employing zero-knowledge proof [14]. Data Collection. We used the APIs of Etherscan [12] and Google BigQuery [13] to fetch Ethereum data from 1/11/2022 to 07/05/2025 corresponding to blocks 15875000–22431083. Note that APTs were first observed about November 2022 (see, e.g. [15, Sec. 5] and [9]). We also collected a list of nearly 40 thousand public service addresses based on the public labels from Etherscan and manual inspections. Normal and Internal Transactions. A normal transaction is initiated by an externally owned account (EOA) and is stored directly on-chain as a transaction within a block. In con-

In Section 6, we present an attempt to group Tornado Cash users associated with scam activities, by introducing APT-specific heuristics that can establish connections among otherwise unrelated addresses. We note that address grouping/clustering is a fundamental problem in blockchain intelligence research (see, e.g. [3,16,19,20,24]). We also implement a tracing algorithm to estimate the total APT proceeds flowing into public services. The algorithm can keep track of individual tokens during laundering and handle token swaps. Our main contributions are summarised below. • We propose a classification of 11 sub-types of APT scams and an in-depth study of their funding/attack mechanisms. • We introduce five families of scam signatures capturing key operational aspects of APTs, and show that they are consistent, i.e. individual addresses tend to reuse the same signature values, suggesting automated scam operation. • We conduct the first investigation into how APT scammers utilise Tornado Cash (among public services) for funding and laundering. We also study how Tornado Cash user addresses can be grouped via APT operational connections. In particular, we provide the first estimate of roughly $38.09M APT scam proceeds entering Tornado Cash and $18.14M to other public services (11/2022–5/2025). 2

Figure 2: a) The typical APT attack setup: observing a legitimate transfer from a to b, the phishing address p, which looks similar to b, sends an APT to a. Note that the APT can also be made from a to p for genuine tokens (must be a zero value) and fake tokens. b) (Type-1) The standard scenario when a mistakenly transfers funds to p instead of the intended receiver b. c) (Type-2) A rarer scenario when the victim uses another address v instead of a to (mistakenly) transfer funds to p. trast, an internal transaction originates from a contract account (CA) as part of a smart contract execution. Unlike normal transactions, internal transactions are not recorded directly on the blockchain, but can be obtained in the EVM execution trace. Etherscan provides the API to get these transactions by specifying a block range. We collected 1,399,654,309 normal transactions and 639,829,207 internal transactions, occupying 1.7 TB in our local SQL database. ECR-20 Token Transfers. A token transfer refers to the movement of a digital token that follows the ERC-20 standard. When a user transfers an ERC-20 token, its smart contract emits a transfer event. We collect all transfer events of the top-100 tokens (ranked by market cap) from CoinGecko [8] including popular ones such as USDT, USDC, DAI, WETH, WBTC. We refer to these as genuine tokens, as opposed to the fake ones that mimic them (see below). Event logs for token contracts are retrieved via the getLogs method, filtered by the topic corresponding to the Transfer event signature, and decoded to extract the sender, recipient, and transfer amount. Fake Token Transfers. We adopt the approach by Guan and Li [15] that assumes that fake tokens often have token symbols resembling those of genuine tokens, while having malicious contracts. We extend and modify their approach to include fake tokens corresponding to the aforementioned top-100 genuine tokens. We generate a list of tokens with unique contract addresses from the publicly available token transfer data set on Google BigQuery. Then, every token that has the same symbol as a genuine token but with a different address is labelled as a fake token. A token is also classified as fake if its symbol is a Levenshtein edit distance of one from a genuine symbol and has either an unverified contract (on Etherscan) or a flawed contract that allows transfers from a zero-balance testing address (see [15, Sec. 4.2]). We have collected 55,064 fake tokens. The largest groups mimic USDT (13,196 - 24%), PEPE (7,452- 13.5%), USDC (6,106 - 11.1%), DAI (4,645 - 8.4%). The total ERC-20 token transfer data occupies 726 GB in our SQL database (see Appendix D). Tornado Cash Transactions. In Tornado Cash (TC), a user deposits a fixed amount of the available currency (e.g.

0.1, 1, 10, or 100 ETH) to a TC router contract. The router then forwards the deposit to a corresponding TC pool. This deposit is recorded with other deposits of the same amount, creating an anonymity set. When a user wants to withdraw, they provide their previously generated zero-knowledge proof that proves the ownership of their deposit without revealing their depositing address and request that the funds be withdrawn to a specified address. Optionally, users can withdraw via a third-party service (relayer) to enhance privacy. To collect deposit and withdrawal transactions, we first retrieve all TC pool and router addresses from Etherscan. Then we collect sender and receiver addresses from deposit and withdrawal transactions by decoding their calling functions. We have collected 36,435 deposit and 35,076 withdrawal transactions in TC pools for the period 11/2022–05/2025. ETH pools are the most active, accounting for about 98% of the transactions on TC (see also Table 3, Appendix D).

3

APT Phishing and Victim Datasets

Prior work on APTs [7, 15, 23, 29] considered three types of APT depending on whether ETH, genuine ERC-20 tokens, or fake tokens are transferred. We refer to these as coin APTs, genuine-token APTs, and fake-token APTs, respectively. We eventually classify APTs into 11 subtypes (see Section 3.1 and Fig. 3), which allows us to describe more aspects of APTs. Between 11/2022 and 05/2025 we build an APT dataset consisting of: 3,855,694 coin APTs, 14,799,949 genuine token APTs (using the top-100 ERC-20 tokens from CoinGecko), 37,708,070 fake token APTs (using the 55,064 fake tokens mimicking the 100 genuine tokens). We also build a victim dataset that consists of 4,209 victim transfers, totalling around $166.31M million USD. We first describe standard APT scenarios with examples (see also Fig. 2) before detailing the dataset construction. Example 1 (Type-1 victim). The phishing address 0xd9A1 C3788D81257612E2581A6ea0aDa244853a91 transferred 0 ETH (0x87c6e5d56fea35315ba283de8b6422ad390b6b 3

9d8d399d9b93a9051a3e11bf73) and also 0.05 fake token (0x9147d74ef5749b7f27eb2e2528e5a611060b3f609b43 5f7f50ac87f49e5b957c) to the victim 0x1e227979f0b5 bc691a70deaed2e0f39a6f538fd5, mimicking the victim’s intended receiver 0xd9A1b...B2853a91, which received 0.05 ETH from the victim (possibly a test transfer) a few minutes earlier. Due to the high similarity between the two addresses (the first four and last six digits are identical), the victim mistakenly transferred 1,155 WBTC (about $70 million USD) to the phishing address about an hour later.

a forward, active, positive-valued, genuine-token APT has an accompanying coin funder and a token funder, a backward, passive, genuine-token APT only has one accompanying coordinator and no funder. This distinction becomes critical when we construct the datasets of funders and coordinators from the datasets of APTs. We divide the construction process into three subprocedures that identify coin APTs, genuine-token APTs, and fake-token APTs separately. We present in this section the sub-procedure for genuine-token APTs as a representative, and leave the other two to Appendix E.1. Note that coin and genuine-token APTs are also called dust-value transfers (DVTs). Moreover, a coin APT is always forward and active, and a backward genuine-token APT always has a zero value. Our two lists of genuine and fake tokens are described in Section 2. Each fake token has a symbol that resembles that of a genuine token, referred to as its genuine counterpart.

Example 2 (Nonzero genuine-token APT). Within a single contract call 0x057054eb96d386dfbefef7fae2 979b3b0e4dd7f742647b47e80c4d5f30974de5 by the labelled address Fake_Phishing11701 to the contract Fake_Phishing11700, small amounts of USDT (e.g. 0.03 and 0.05) were transferred to several phishing addresses and then (the same amounts) to target addresses. Example 3 (Type-2 victim). The phishing address 0x5b93 73ba974f0f2b0c99e79004c517fc636ed866 did not target the victim 0xCe7c8d990a248B6E1b9750788a9219497F a41297, who still sent the phisher 28.99 ETH. Prior to this, it attacked another address 0xAeeF025bB585d47D9A1886 d1E8795Cba0816B0B6, and both the victim and the target transferred to a common benign address 0x5B93732311eb 61642058fa42202bC4fc496eD866, which shares the same first and last six characters with the phishing address.

Genuine-Token APT Dataset Construction Step 1. Identify the set TSgen of suspicious genuine-token transfers with values below 3 USD (at the time) in which both senders and receivers are EOAs and not identical. Step 2. From the set TSgen of suspicious transfers identified in Step 1, construct the set TAgen of genuine-token APTs and label them as follows. For each transfer t = (s, r) ∈ TSgen , first check if it is a forward APT, by searching the transaction history of r. If there was a nonzero transfer of the same token ℓ = (r, b) that occurred before t such that b ̸= s but b and s share at least three first and last digits, then include t in TAgen as a forward APT with s as the phishing address. If t doesn’t satisfy that condition, and val(t) = 0, then search in the transaction history of s for a nonzerovalue transaction ℓ = (s, b) that occurred before t and b ̸= r but b and r share at least three first and three last characters. If such ℓ is found, include t in TAgen as a backward APT with r as the phishing address. In either case, we refer to ℓ as the legitimate transfer associated with t and b its benign address. Finally, if the phishing address is also the sender of the normal transaction of the same hash as t then t is an active APT. Otherwise, it is passive, and the sender of the normal transaction is called the coordinator of the APT.

3.1 Detecting the Address Poisoning Transfers Our detection approach shares similarities with Guan-Li [15], Chen et al. [7], and Tsuchiya et al. [23], however, captures more nuance by dividing APTs into 11 subtypes shown in Fig. 3, providing a more complete understanding of how they work. In particular, having refined subtypes allows for extraction of APT scam signatures, which was not possible with existing approaches (see more in Section 5). We distinguish active APTs, in which phishing addresses initiated the transfers (and paid the fees of the transactions containing the APTs), from passive APTs, in which coordinator addresses rather than the phishing’s initiated the transfers. We also distinguish forward APTs, in which the transfers were from the phishing addresses to the target addresses, from backward APTs, in which the transfers were from the target addresses to the phishing addresses. We also consider if the value of the APT is zero or nonzero. We note that nonzerovalue passive genuine-token APTs require phishing addresses to send approve transactions that allow some contracts to spend the genuine tokens on their behalf, while zero-valued passive genuine-token APTs do not. Existing work overlooks these nuances, which could lead to miscalculations of the costs of different subtypes of APT. This finer classification also allows for more accurate tracing of the addresses directly supporting the phishing addresses. For instance, while

We find that among 3,855,694 coin APTs, 82.7% are nonzero-value APTs. Among 14,799,949 genuine-token APTs, 81.9% are zero-value, 80.3% are backward, and 83.5% are passive. Among 37,708,070 fake-token APTs, 99.7% are backward, and almost 100% are passive. See Appendix E for more analysis.

3.2

Identifying the Victims of APTs

Identifying victim transfers enables us to quantify the financial impact of APT scam and avoid mixing up scam-funders and victims. 4

Address Poisoning Transfer (APT)

Genuine-Token APT

Coin APT

Fake-Token APT

coin funder Forward Active

Zero coin funder

Passive

Nonzero

Zero

coin funder token funder

coordinator

Backward

Forward

Backward Active

Passive

Active

Passive

Active

Passive

coin funder

coordinator

coin funder

coordinator

coin funder

coordinator

coin funder: the address that transferred coins to the phishing address token funder: the address that transferred tokens to the phishing address coordinator: the address that initiated the APT by calling a contract

Nonzero coin funder, token funder coordinator

Figure 3: Eleven APT subtypes, classified based on whether the transfer is a coin, genuine-token, or fake-token transfer, whether it is forward (phishing to target) or backward (target to victim), whether it is active (initiated by the phishing address) or passive (initiated by another address), and whether its value is zero. Each APT, depending on the subtype, is supported by either a coin funder and/or a token funder and/or a coordinator, all referred to as master addresses. 5

Definition 1 (Victim Transfer). Let TA be a set of APTs. For each t ∈ TA , denote by p = Phishing(t) and a = Target(t) the phishing address and the target address of t, respectively. We refer to P ≜ {p : p = Phishing(t) for some t ∈ TA } as the set of phishing addresses and A ≜ {a : a = Target(t) for some t ∈ TA } as the set of targeted addresses. A transfer f = (v, p) of a coin or a genuine token is called a victim transfer (and v is the victim address) if f ∈ / TA and either of the following conditions is satisfied, with (C1) taking precedence if both are satisfied.

IsVictimTransfer(p, f = (v, p), TA (p)): p, f = (v, p), TA (p) - the phishing address, a positive-valued non-APT incoming coin/genuine-token transfer, and the set of all APTs of p, respectively; 2: for t ∈ TA (p) that occurred before f do 3: if Target(t) = f then 4: return TRUE; # type 1 victim transfer; 5: for t ∈ TA (p) that occurred before f do 6: b ← Benign(t); # the address that looks similar to p (see Section 3.1); 7: if there exists a positive-valued non-APT transfer from v to b then 8: return TRUE; # type 2 victim transfer; 9: return FALSE; # not a victim transfer; 1: Input:

(C1) There was an APT t ∈ TA with v = Target(t) that occurred before f . This is a standard scenario where v was targeted by an APT from p and then mistakenly transferred funds to p (see Fig. 2b and Example 1). This is a ‘Type-1’ victim transfer.

values of at least $1,000 USD, corresponding to $12.21 million in ETH and $153.6 million in tokens. Among these are the well-known cases of 20 million USDT (frozen by Tether) in 2023 and 1,155 WBTC in 2024 discussed in Example 1.

(C2) Before f , there were an APT t = (p, a) ∈ TA and the associated legitimate transfer ℓ = (a, b) with b ≈ p, and also a positive-valued non-APT transfer ℓ′ = (v, b) ∈ / TA , which could occur at any point. This is a more subtle scenario when the victim used two addresses a and v to transfer funds to a common address b, and the address a was the target of an APT, whereas v was the address that actually sent fund out to p (see Fig. 2c and Example 3). This is called a ‘Type-2’ victim transfer.

4

APT Masters and Distributors

We now shift our focus to APT master addresses, which execute or fund APTs, as well as their funders (called distributors). Masters play a central role in our study as the way they operate reveals significant insights into how the scammer organises their APT scams at scale (see Section 5). We first define three typical master types and then propose a systematic way to find them by pairing each APT with a set of masters supporting it. Such fine-grained APT-masters pairings allow us to capture a specific type of scam signature called fundingresidual signature (see Section 5.5), and provides an accurate way to connect ‘tainted’ TC depositors and withdrawers with their associated masters (see Section 6 and Appendix J).

We use TV to denote the set of victim transfers, and V ≜ {v : ∃ℓ = (v, p) ∈ TV } for the set of victim addresses. One can analyse TV to tally the total loss attributed to the APT scam. We build the victim transfer dataset by finding all victim transfers going into each phishing address using the procedure IsVictimTransfer, which implements Definition 1. We identified 4,209 victim transfers (4,180 type-1 and 29 type-2), in which 327 ETH transfers (322 normal and 5 internal) and 1,505 genuine-token transfers have (historical) 5

4.1

Three Master Types

some token to p and then immediately transferred that from p to the target. In this case, m2 plays the roles of both token funder and coordinator for APT. Another possibility is to have a separate token funder m3 ̸= m2 . Note that in a forward zero-value genuine-token APT, a coin funder is not needed because a zero transfer does not requires approval from p. The same goes for a backward genuine-token APT.

We define master addresses (or masters for short) as the nonservice EOA addresses that funded the phishing addresses (coin funders or token funders) or coordinated the APTs via contracts (coordinators). We first present typical ways an APT can be carried out and illustrate the different roles masters play in each case. Note that each phishing address can be involved in multiple types of APT and interact with different masters. The masters governing each of the 11 APT subtypes are shown in Fig. 3. Various examples of master-phishing interactions can be found in Appendix H. Coin APT. Each coin APT has at least one coin funder. Typically, one coin funder supplied sufficient ETH for the phishing to cover the APT amount and the transaction fee.

Figure 6: Typical operations for a passive fake-token APT. Fake-Token APT. In the typical fake-token APT, a master (coordinator) calls a contract that performs one or more transfers of fake tokens from phishing addresses to target addresses (see Fig. 6). No funding to the phishing addresses is required.

4.2 Figure 4: Funding for an active genuine-token APT.

Identifying the APT Masters

We developed a systematic approach to identify all master addresses and transactions associated to a given APT dataset (Section 3). For each phishing address p, we scan its list of APTs from oldest to newest and find all master addresses and transactions involved. Note that for each of the 11 APT subtypes, we know exactly the types of master we are looking for (see Fig. 3 and Section 4.1). Masters that are coordinators can be easily found by retrieving the EOA addresses that call the transactions containing the APTs. For coin funders and token funders, we match each APT with one or more nearest incoming nonzero non-APT (coin/genuine token) transfers that occur before the APT and collectively cover its cost including transaction fee. The (nonservice) EOA senders/transaction callers of these funding transfers are the master addresses. We allow partial funding, i.e. the same funding transfer can be used to fund multiple APTs with partial amounts. Our matching logic can handle complex cases including multiple funding transfers that are used for multiple APTs (Example 13), and victim transfers that are used to cover the cost of APTs (Examples 17, 18). We found 57,558,073 master records, corresponding to 5,307,343 unique transaction hashes, among which 2,780,856 transactions are for coin funding, 510,935 transactions are for genuine token funding, and 2,420,269 transactions are for APT coordination. Notable masters include 0x49c6246ab520 9733d2ed59af17f9081d6f138370 who performed 12,639 transactions as coordinator, supporting 189,645 phishing addresses, and 0xeFb3729Bc9C0ee64c718185d612C9538C0 323306, involved in 36,651 transactions as a coin/token funder, or coordinator, supporting 162,479 phishing addresses.

Genuine-Token APT. For each genuine-token APT, the phishing address may need a coin funder, a token funder, or both, or none, depending on the specific APT subtype (see Fig. 3 for more details). Fig. 4 shows the typical funding mechanism of an active, nonzero-value genuine-token APT, in which both coin and token funders are required (they can be identical). This is because in an active APT, the phishing address calls the transaction itself and hence needs coins to cover its fee. Furthermore, if it transfers a nonzero amount of genuine tokens then it also requires a token funder.

Figure 5: Funding for a passive genuine-token APT. Another common way for scammers to perform genuinetoken APTs is to let a master m2 (coordinator) perform multiple APTs in the same transaction by calling a contract c as depicted in Fig. 5. For a nonzero value APT, another master m1 (coin funder) must first transfer some coin to the phishing address p so that it can approve c to spend the token on its behalf. Then, in a single contract call, the contract transferred 6

5.2

There are 51,414 unique master addresses, 43,906 of which involved in one or two APT-funding/coordinating transactions. Many among them turn out to be phishing addresses. A random check shows that most belong to a long phishing chain (e.g. the one containing 0x6A968Fe887434Ba54dB5 4Ceca38A680A80f61224), likely run by the same scammer given the chain topology and identical gas signatures. We henceforth focus on 7,508 masters that were involved in at least three APT-coordinating/funding transactions. We also define distributor, which funded ETH to masters, and their funders (called distributor funders). Examining the distributor dataset, we found a number of public services used to fund APT masters, led by FixedFloat (funded 291 masters), ChangeNOW (132 masters), and WhiteBIT (39 masters). Distributors and distributor funders also play important roles in our approach for grouping ‘tainted’ TC depositors/withdrawers as intermediate addresses between such TC users and the masters (Section 6). More details about distributors and their funders are in Appendix H.

5

The cohesion score is developed based on the guilt-byassociation (GBA) graph, which ‘connects’ two masters if they support the same scammer address, or fund each other, or are funded by the same non-service distributor. As a common assumption in the literature (see, e.g. [15, 18, 23]), addresses that lie in the same weakly connected component of such graphs likely belong to the same scammer group. The concrete definition of the GBA graph can be found in Appendix I.2. We define cohesion at both the group and signature levels. For a group of masters sharing the same signature value, group cohesion is defined as the fraction of master pairs that lie in the same WCC of the induced GBA graph. Signature cohesion is defined similarly but over all such groups (of size at least two). The highest cohesion score is one, which means that every pair of masters that have the same signature value can be connected by a path in the corresponding GBA graph. The lowest cohesion score is zero, which means that none of the pairs of masters with the same signature value are connected in the corresponding GBA graph. The formal definition of signature cohesion can be found in Appendix I.2.

APT Scam Signatures

5.3

We formulate and study five groups of scam signatures tailored to address poisoning transfers. These signatures characterise the gas setting, the public service usage, the contract generation and usage, the relation between the APT values and benign values, and the relation between the APT values, transaction fees, and funding amounts. Such signatures capture different aspects of scam operations and allow us to gain deeper understanding of how scammers run their campaign, most likely by using a scam toolkit or automated software. We note that Tsuchiya et al. [23] briefly discussed the idea of scam signatures using terms like ‘attack strategies’, ‘behaviours’, ‘contract reuse’, without going into concrete details, except for the observation that one of the clusters used contracts with identical bytecodes. This section presents a detailed study of such behavioural patterns observed from the APT datasets. We evaluate scam signatures using two complementary metrics. Address-level consistency measures how consistently an address reuses the same signature values, while signaturelevel cohesion measures the extent to which same-signature address groups are corroborated by scam-operation evidence.

5.1

Cohesion Score for Scam Signatures

Gas Signatures

The sender of an Ethereum transaction can specify a few gasrelated parameters such as the gasLimit, which is the maximum gas provided by the sender, the maxFeePerGas (only for transactions of type-2, type-3), which is the maximum price (in Gwei) they are willing to pay for each gas unit, and the maxPriorityFeePerGas (only for transactions of type-2, type-3), which is the tip (in Gwei) they are willing to pay to the block builder per gas unit. These parameters, which are set by the scammer, can be used as scam signatures. Definition 2 (Gas Signatures). We define three gas signatures GL, MFPG, and MFPPG for each address a, corresponding to gasLimit, maxFeePerGas, and maxFeePerPriority as follows. Each signature is a multiset {(v1 , f1 ), . . . , (vk , fk )}, where the value vi appears fi times in the scam-related transactions of a. Example 4. The master m1 = 0xc16acf1380a144f673 411226c9dd913cf1eec182 performed more than 8,000 transactions, each of which carries many APTs and always has maxFeePerGas 80 Gwei and maxPriorityFeePerGas 3 Gwei, but with gasLimit 8,500,000 in early transactions and 18,500,000 in later transactions. More precisely, GL(m1 ) = {(18500000, 7071), (8500000, 1354)}, MFPG(m1 ) = {(80, 8425)}, and MFPPG(m1 ) = {(3, 8425)}. The master m2 = 0xefb3729bc9c0ee64c718185d612c9538c0323306 has GL(m2 ) = {(6000000, 31833), (500000, 3865), (2000000, 403), (3000000, 601)}, MFPG(m2 ) = {(80, 36702)}, and MFPPG(m2 ) = {(3, 36702)}.

Consistency Scores for Scam Signatures

We define the Inverse-Simpson/Shannon consistency scores to quantify how consistently an address reuses observed elements (e.g. contracts) relative to the number of scam-related transactions. The closer the score is to one, the more consistent the behaviour, i.e. using fewer values with larger frequencies. A more consistent signature reflects the behaviour of an address more faithfully. Details are provided in Appendix I.1.

Gas Signatures Consistency. We collect gas signatures restricted to APT-carrying transactions for all 7,508 master 7

Definition 5 (Private-Contract-Call Signature). Given an address set M and an APT/fake-token contract set F, the privatecontract-call signature CC(m) of m ∈ M is the multiset of modified addresses of the contracts called by m (with frequencies) that either are APT/fake-token contracts from F or created by some m′ ∈ M.

addresses that have at least three APT-related transactions. The consistency scores (Section 5.1) of these signatures are presented in Table 1. We found that MFPPG is the most consistent gas signature, with 65.9% of master addresses using exactly one value across all transactions, and average consistency scores 0.81 (IS) and 0.8 (SH). Although GL appears reasonably consistent, we note that among the 4,493 masters that used only one value for gasLimit, 2,085 used the default value of 21,000, which provides no useful insight.

Example 5. The master 0xc16a (see Example 4) created and called the APT contract 0xb9f6a074d8093cb7c48c53 d42776ca7dca6fda52 8,425 times. Thus, its CG and CC signatures are {0x40a8...75d5} and {(0x40a8...75d5, 8425)}, respectively, where 0x40a8...75d5 is the modified address of the contract. The master 0xA57188bD032cf7fA73 1 9 6 0 8 f 0 F D 9 F 1 5 5 b 3 8 7 2 0 5D generated and used six contracts, among which 0 x 4 b 0 1 8 b 9 9 d 9 9 0 8 2 5 0 7 9 c 9 794c382dfaa8bbd395a6 is an APT contract and was used 3,164 times, while the other five were used once (for setting the whitelist) and have identical bytecodes. By Definitions 4 and 5, its CG and CC signatures are {0xc527...c4b0, 0x5f31...c6ab} and {(0xc527...c4b0, 3164), (0x5f31...c6ab, 5)}, where 0xc527...c4b0/0x5f31...c6ab are modified addresses of the APT/whitelist-setting contracts.

Table 1: Percentages of masters that have gas signatures consistency scores of 1, at least 0.9, at least 0.8, and their mean. Each entry uses the format IS|Shannon. =1

≥ 0.9

≥ 0.8

mean

GL

59.8|59.8

65.3|64

68.6|68

0.78|0.77

MFPG

36.6|36.6

38.3|37.8

39.7|38.9

0.42|0.42

MPFPG

65.4|65.4

77.6|72.5

79.2|77.5

0.81|0.8

Sig/Score

Gas Signatures Cohesion. The gas signatures GL, MFPG, and MPFPG have cohesion scores 0.58, 0.88, and 0.69, respectively. This means, for example, that 88% of the master pairs that have identical MFPG signature values are ‘connected’ (i.e. having a path connecting them) in the corresponding scam-operation graph. These scores suggest that the gas signatures are reasonably effective in capturing master addresses that likely belong to the same scammer.

5.4

Generation of Contract Signatures. We generated the contract signatures for the list M≥3 of all 7,508 masters that were involved in at least three funding/APT transactions (see Section 4.2) as follows. First, we collected the transaction hashes of successful out-going normal transactions from all m ∈ M≥3 that have an empty ‘to’ field (i.e. contract-creation transactions). We then called an API from Etherscan to collect the list C(M) of 13,750 corresponding contract addresses generated by such transactions (by 3,472 masters). We also identified 1,133 APT/fake-token contracts that were not created by these masters (i.e. F \C(M)). Another API was called to retrieve the runtime bytecodes of such contracts, which were then hashed using Keccak256 to produced 14,883 modified addresses. The CG signature of m ∈ M is the set of modified addresses h(c) for c created by m, and its CC signature is the multiset of h(c) for c ∈ C(M) ∪ F called by m. Contract Signature Consistency. We identified 4,112 masters that called 6,176 private contracts c ∈ C(M) ∪ F. Their CC signatures are highly consistent, with 76.5% calling exactly one (modified) contract, and approximately 90% having their IS|Shannon scores at least 0.9. Both scores have mean 0.95. Consistency scores do not apply to CG signature as each master creates each contract once. Contract Signatures Cohesion. CC and CG signatures have remarkably high cohesion scores, 0.959 and 0.998, respectively. This means that more than 95% of pairs of masters that share the same contract signatures turn out to be connected by a path in their corresponding scam-operation graph. This signifies that contract signatures are highly effective for clustering master addresses controlled by the same scammer. Signature-Based Address Grouping. Based on the CG signature, we found that 3,415 master addresses that created

Contract Signatures

The contract signatures capture the observation that each scammer tends to generate or use contracts with identical (or similar) codes for funding APTs, coordinating APTs, moving funds among different addresses, or for fake tokens. In this section, we formulate the so-called contract-generation and private-contract-call signatures, and analyse these signatures over 7,508 master addresses. To avoid the expensive pairwise comparison of contract codes, we replace a contract address by the first 40 hex characters of the Keccak256 hash of its bytecode. Thus, contracts with identical bytecode will be referred to by a common (modified) address, eliminating the need for pairwise comparisons. For example, the APT contracts 0x7C439FDeB9F835A34221B09599Fd85e83B1Cdf3b and 0x11972d7E8aB2274F342b6B340C91CcD50b0459eB have identical bytecode, and hence both will be referred to using a new address 0x40a8dc0fb84193a1d20e95e76ae9 8e90a81075d5 obtained from the hash of their bytecode. Definition 3. A modified address c′ = h(c) of a contract c is obtained by concatenating 0x and the first 40 hex characters of the Keccak256 hash of its runtime bytecode. Definition 4 (Contract-Generation Signature). The contractgeneration signature CG(m) of an address m is the set of modified addresses of the contracts created by m. 8

some contracts contain 38 groups of sizes between 2 and 31, and four groups of sizes 1699 (CG: {0x9029. . . 649b}), 467 (CG: {0x5e66. . . c3c3}), 254 (CG: {0x5f31. . . c6ab, 0xc527. . . c4b0}), and 247 (CG: {0x5e66. . . c3c3}), referred to as Groups CG1, CG2, CG3, CG4, respectively. These groups funded and coordinated large numbers of phishing addresses and APT transactions. For instance, CG1-CG4 supported 485948, 125247, 1090933, 1476714 unique phishing addresses, and 352890, 37383, 539626, and 135398 unique APT-carrying transactions, respectively. Each remaining 534 masters has a unique CG signature. Cross-Signature Analysis. The above groups also demonstrate remarkably consistent gas signatures. In Group CG1, all masters used a single value of 3 for maxPriorityFeePerGas, 1643 out of 1699 masters used a single value of 200 for maxFeePerGas and 18,500,000 for gasLimit. In Group CG2, all 467 masters used identical gas signatures, with corresponding values 3, 200, and 18,500,000. In Group CG3, 251 masters used 1.5 as the only maxPriorityFeePerGas, and the remaining three used both 0.1 and 1.5. Group CG4 is less consistent, with 149 masters using 1 and 73 masters using 1.5 as their single maxPriorityFeePerGas, and a few others use both 1 and 1.5, or both 0.1 and 1. In addition, CG1, CG2, CG3 have perfect group cohesion scores of 1, whereas CG4 has a high cohesion score of 0.91, providing further evidence that each master group belongs to the same scammer. Interestingly, contract and gas signatures enable us to formalize and substantiate the qualitative observation by Tsuchiya et al. [23] that copying bots connect “two seemingly distinct large groups (based on their strategies and behaviours)”, which might have led to a possibly incorrect address grouping in [15] (see Appendix I.3 for further details).

5.5

fee market, occasional incorrect pairings of APT-carrying and funding transactions, or numerical errors in computation. For example, for θ = 0.8, both multisets {(1, 8), (2, 1), (3, 1)} and {(1, 10)} are flattened to {1}. Definition 7 (θ-Flattened Multiset). For θ ∈ (0, 1], the θflattened set of a multiset (vi , fi )ki=1 (with f1 ≥ f2 ≥ · · · ≥ ′ fk ) is {vi }ki=1 , where k′ is the smallest integer satisfying ′ ∑ki=1 fi ≥ θ ∑ki=1 fi . Example 6. The master 0x111701b067Ab44B8c3585147 75ba5322b3628BCc funded 0.000528850756707 ETH to the phishing address 0xB50B26e9681c6433fc82d106BA7D39 69CE185564, which then performed an APT of 0 ETH and a transaction fee exactly the same as the funding amount: 0.000528850756707 ETH. The funding residual for this pair of APT and funding transactions is 0. In fact, this master has the FR signature {(0, 4000), (v1 , 1), (v2 , 1), . . . , (v118 , 1)}. According to Definition 7, its 0.8-flattened FR signature is {0}. This FR value of 0 appears in 97% APT-funding transactions. Note that the FR signature applies to token APTs as well. For example, the master 0x3826705213c38a060769b56f68 80fd1f1ef999e9 always funded 0.00001 more USDT/USDC than the APT value. For instance, it funded the phishing address 0x4de97Dc7357823Cd601EcDd8f901DffCa9909416 2.75002 USDC, which in turn sent an APT of 2.75001 = 2.75002 − 0.00001 USDC. However, we do not investigate the FR signature for genuine tokens since from our observation most masters funded the exact token amounts needed for the APTs, making the residual 0 and the signature less useful. Funding-Residual Signature Consistency. We measured the Inverse-Simpson and Shannon consistency scores for the FR signatures of 3,535 master addresses that funded 3,806,347 coin APTs, and found that 34.3% have perfect consistency scores of 1, 91.3%|81.8% have scores at least 0.8, and with mean scores 0.9|0.87 for the IS|SH scores. Notable examples of masters with FR signature consistency at least 0.99 include 0xdbdcef4368d35267753a9958f965b24d60b47613 (funded 31,741 coin APTs, 99% with FR value 0 ETH), 0x1300080e2a951be01a5a87c6897bf59e65118013 (funded 16,827 coin APTs, 99% with FR value 9.99 × 10−8 ETH), 0x760cd3aa47f434887e75ff40fef466faf037f4df (funded 12,840 APTs, 99% with FR value 10−14 ETH), and 0x700c030143f08862eb64263679230b8bec00f699 (funded 3873 APTs, 99% with FR value 7.9 × 10−14 ETH). Funding-Residual-Signature Address Grouping. We first flatten the multiset that represents the FR signature of each master to a set of funding residual values and then form groups of master addresses that have similar or identical signatures using a dictionary with signatures as keys and the correlated masters as values. We use a threshold percentage θ when flattening the multisets to eliminate infrequent values. Setting θ = 80%, the set of 3,535 master addresses who served as coin funders of coin APTs can be partitioned into 250 groups.

APT Funding Residual Signatures

In a coin APT, the master must first fund x coins to the phishing address, which then performs an APT with value y and transaction fee z coins. The multiset of differences x − (y + z) forms the so-called funding-residual (FR) signature of the master address (Definition 6). This also extends to genuinetoken APTs with a slight modification (remove the fee z in the formula). To accurately collect the FR signatures, we must first pair the funding transfers and the APT transfers correctly, which is a nontrivial task (see Section 4.1) that none of the previous work on APTs has investigated. Definition 6 (Funding-Residual Signature). Suppose a master m funded xi ETH to its i-th coin APT, which has a value of yi ETH and costs a transaction fee of zi ETH, i = 1, . . . , k. Then, the funding-residual (FR) signature of m, denoted FR(m), is the multiset of the residuals xi − (yi + zi ), i = 1, . . . , k. To use a multiset signature for address grouping, we first flatten them into sets with a threshold θ ∈ (0, 1]. Setting θ < 1 eliminates outlier values due to unexpected changes in the 9

The four largest groups are: Group FR1 with 913 addresses (flattened FR signature {0}), Group FR2 with 344 addresses ({9.99 × 10−8 }), Group FR3 with 216 addresses ({10−18 }), and Group FR4 with 90 addresses ({2.1 × 10−9 }). These groups funded 407462, 400907, 72250, and 28641 unique phishing addresses, respectively. Note that an address having 0.8-flattened FR signature {r} means that the funding residual is exactly r in at least 80% of its funding transactions. Funding-Residual Signature Cohesion. (Flattened) FR signature has a low cohesion score of 0.52. The main reason is that the largest group of 913 masters FR1, which has signature {0}, has cohesion score of only 0.42. Our hypothesis is that the trivial value of 0 can be used by multiple scammers, which means that FR1 may consist of addresses from different scammers, which are not connected in the scam-operation graph. Further evidence supporting this hypothesis is discussed in the analysis of the Value-Pattern signature in the next section. On the other hand, removing FR1 from the calculation pushes the cohesion score to 0.97, which suggests that FR values other than 0 are more reliable for master address grouping.

5.6

d) do not match, then produce the string ‘OTHER’. Otherwise, set E = ⌊log10 (a)⌋. We note that the collected pairs (APT-value, benign-value) may have noise since an APT can sometimes be paired with a benign transfer that is algorithmically correct but was not the one intended by the scammer. We use a threshold θ to eliminate infrequent noise when aggregating the two signatures. Definition 10 (VP Signature). For θ ∈ (0, 1], the θAggregated-APT-Value-Pattern (VP) signature of a master address is a single string of one of the forms ‘CONST_a’, ‘MIMIC_d_E’, or ‘OTHER’, obtained as follows. Let ‘CONST_a’ and ‘MIMIC_d_E’ be the two strings with largest frequencies in the c-VP and the m-VP signatures of m, and rC and rM be the ratios of their frequencies versus the total number of APTs funded by m, respectively. Then the VP signature of m is ‘OTHER’ if θ > max{rC , rM }. Otherwise, it is ‘CONST_a’ if rC ≥ rM , or ‘MIMIC_d_E’ if rC < rM . Example 7. The master 0x8fe6b2257DD8aF5f4B83a497 C092F641Dd22F6b1 funded 5577 coin APTs, 4541 (81%) among which used a constant value of 0.00001 ETH regardless of the benign values (e.g. 0x18cb1d982339b6b3cb042dc6 4afdc7e221d6ebb4a097ac0be8d30cb4e65f8dcd). It also used ‘MIMIC_6_−5’ for 1775 (32%) APTs. For example, the APT 0xf2105ce09c1966728e68be3801eff71d809ac9 455f1b1f47c5200f1ed8deb015 has value 0.000016 ETH to mimic the benign value 16 ETH of the transfer 0x5315c88f af015fbd5e997d8b2e977ac9155b3f36239c980ef4de7b 08b2a9c43b. According to Definition 10, this master has VP signature ‘CONST_0.00001’ with θ = 0.8.

APT-Value-Pattern Signatures

We observe from the coin and genuine-token APT datasets that APTs funded by the same master address frequently exhibit either constant transfer values or values that systematically resemble corresponding benign transfers. For example, a benign value of 12345 may be met with an APT value of 0.012345, suggesting a deliberate transformation that preserves the digit sequence while altering scale. The intent is to mirror visual similarity between benign and malicious transactions when the decimal point is ignored, thereby enhancing the likelihood of deceiving the victim. To capture this class of signatures, a generic approach is to collect all (APT value, benign value) pairs associated with APTs funded by a given master address and derive a compact benign-to-APT mapping. We now formalise and evaluate the usage of two mappings: APT values are constant, or visually match the benign values while staying in a value range , e.g. [10−5 , 10−4 ). Such strategies potentially allow better control of the APT costs.

VP Signature Consistency. We examined 3,535 masters that funded coin APTs and found 17 groups (summing to 2,682 addresses) that have VP signatures (other than ‘OTHER’) with the threshold θ = 0.8. This means that 76% of the 3,535 master addresses of interest exhibited the same VP signatures in at least 80% of their APTs. The top groups include: VP1 with 1,238 addresses and VP signature ‘CONST_0’ (funded 522,731 APTs), VP2 with 605 addresses and VP signature ‘MIMIC_6_−6’ (funded 115,046 coin APTs), VP3 with 443 addresses and VP signature ‘CONST_10−10 ’ (funded 637,309 coin APTs), VP4 with 308 addresses and VP signature ‘CONST_10−6 ’ (funded 1,544,033 coin APTs). Other notable VP signatures include ‘CONST_a’ with a ∈ {10−18 , 10−4 , 10−5 , 10−8 } (65 addresses in total), and ‘MIMIC_6_−4’ (17 addresses). VP Signature Cohesion. VP signature has a low cohesion score of 0.24. The main reason is that the largest group VP1 (1,238 masters) has cohesion score of only 0.003. Our guess is that 0-value APTs are commonly used even among independent scammers due to its low cost. Removing VP1, however, increases the cohesion score to 0.79, which suggests that other VP values could still be useful for identifying master addresses likely from the same scammer group.

Definition 8 (Constant-VP Signature). The Constant-APTValue-Pattern (c-VP) signature of a master address m is the multiset of strings ‘CONST_a’ with their frequencies, where each string ‘CONST_a’ is obtained from an APT with value a funded by m. Definition 9 (Mimic-VP Signature). Given an integer d ≥ 1, the d-Mimic-APT-Value-Pattern (m-VP) signature of a master address m is the multiset of strings ‘MIMIC_d_E’ and ‘OTHER’ obtained from APTs funded by m as follows. For each pair (a, b) representing (APT-value, benign-value), if the d left-most digits of a and b after the scaling transformation (removing their decimal point and the 0’s on the left and right, and adding 0’s to the right if the number of digits falls below 10

Cross-Checking with Funding-Residual Signatures. Overlaps among some large groups of the two signatures are noticeable. For example, Group FR1 contains 595 out of 605 addresses from VP2, but also 93 from VP3 and 76 from VP1, suggesting that FR1 may not belong to a single scammer group. Group FR2, however, lies entirely inside VP3, and also has a perfect cohesion score of 1, strongly suggesting that its addresses could be run by the same scammer group (example master address: 0x309eecd11dd36c69ffbdfcc54a20ffb6 39a6600c).

5.7

of all previous outgoing laundering transfers. Second, it will revisit an address and reprocess its outgoing laundering transfers if it identifies new incoming laundering transfers. The most closely related money-laundering tracing algorithm to ours is MFTracer by Huo et al. [17]. However, as MFTracer converts the cryptocurrency flow into USD to simplify the tracing, it suffers from temporal valuation errors due to fluctuations in token prices (see [17, Sec. 5.3]). By contrast, our algorithm tracks individual tokens, and also handles token swaps via DEX. Further details can be found in Appendix F. Applying DLF to victim transfers of at least $1,000 and tracing up to 15 hops from the victim addresses, we identified 17,566.99 ETH (about $38.09 million at the time of transfer) in APT scam proceeds entering TC. This represents 22.97% of the total observed victim losses—approximately $165.82 million across 1,832 victim transfers between November 2022 and May 2025. The TC 100 ETH pool received approximately 91.62% of the observed TC inflow. APT scam proceeds also flowed into other services (see Table 2 and Appendix G).

Public-Service Signature

The public-service signature lists the addresses from public services used by the scammer. It is plausible that the same scammer may have a list of preferred services to interact with. Definition 11 (Public-Service Signature). The public-service signature PS(a) of an address a is the multiset of public service (EOA and contract) addresses with which a interacted. Example 8. The distributor 0x5a75cd71cE5eaC048a4b14 79abc98A804c828c87 (see Fig. 1) used only 1inch’s Aggregation Router V5 0x1111111254EEB25477B68fb85Ed929 f73A960582 to fund 25 master addresses and did not interact with other services. Therefore, its public-service signature is {(0x1111...0582, 25)}. One of its successful phishing addresses 0x4f51 (also mentioned in Fig. 1) interacted with just the Tornado Cash Router0xd90e2f925DA726b50C4E d8D0Fb90Ad053324F31b. In fact, these two public services were repeatedly used in this scam group, forming a distinctive mechanism to fund, reinvest or launder scam proceeds.

Table 2: Estimates of APT scam proceeds flowing into public services after running DLF for 15 hops.

6

Laundering Funders. We identified 944 laundering funders, who funded 1,525 successful phishing addresses (that received a victim transfer of at least $1,000) For example, the laundering funder 0xB1a2b6d0D19291C5354fe034B33f1e 98D7f4444A transferred 0.0277 ETH to the phishing address 0x67694AF0ee15792a89573c72cDd21e4560d375f7 so that it can transfer 300,000 USDT received from a victim.

Service

Usage of Tornado Cash in APT Operations

In this section, we provide an estimate of the total APT scam proceeds laundered via public services. We also investigate the Tornado Cash user addresses that are involved in APT scam operations with various roles such as phishing, master, distributor, laundering funder, and laundering addresses. Such addresses contributed to approximately ($38M) deposited into and withdrawn from Tornado Cash (11/2022-5/2025).

6.1

Amount ($M)

Share (%)

Tornado Cash Avalanche SWFT Swap FixedFloat eXch Others

38.09 4.83 3.39 3.38 2.33 4.21

67.735 8.595 6.026 6.016 4.139 7.488

Total

56.23

100.00

6.2 Tornado Cash User Addresses Related to Address Poisoning

Laundering via Public Services

Identifying Tainted TC User Addresses. ‘Tainted’ depositors are found by the laundering tracing algorithm DLF, whereas tainted withdrawers are those that also play one of the defined roles in APT operation, including phishing, masters (see Section 4.2), distributors and distributor funders (see Section 4.2 and Appendix H.2), and laundering funders (see Section 6.1). We identified 85 tainted depositors, which include 7 phishing, 4 masters, 9 distributors, 14 distributor funders, and 4 laundering funders (note that one address may be assigned several APT roles). We also caught 138 tainted withdrawers

To estimate APT scam proceeds laundered into public services, we propose a graph traversal algorithm called Dynamic Laundering Flow (DLF), which builds the collection of transfers that likely carry the scam proceeds within a bounded number of hops from the victim addresses. At its core, the algorithm has two distinctive features compared to standard BFS-based tracing algorithms (see e.g. [26, 28]). First, it follows the time-value constraint that the value of each outgoing laundering transfer should not exceed the total value of all previous incoming laundering transfers minus the total value 11

between master and phishing, which can be captured by APTbased heuristics, is not visible to traditional heuristics if the master uses a contract to attack and does not fund phishing directly.

Figure 7: APT-based heuristics for grouping addresses. Solid arrows refer to (nonzero, non-APT, non-self-transfer) asset transfers, whereas dashed arrows refer to coin/token funding or coordination of APT. Figure 8: Examining two depositors d1 , d2 , and one withdrawer w, which share four identical scam signatures. The scam cycle: Step 1 w withdrew 9.95 ETH from TC and funded masters m1 and m2 ; Step 2 m1 and m2 coordinated APTs involving phishing addresses p1 and p2 ; Step 3 p1 and p2 received victim transfers; Step 4 p1 and p2 received ETH from the laundering funder lf to cover the fees and transferred the victim funds to depositor d1 ; Step 5 d1 deposited the scam proceeds back into TC, and also via the depositor d2 .

that also play the role of phishing (3), master (16), or distributor (32), distributor funder (87), and laundering funder (27). Addresses from this group have deposited 20030.3 ETH across 476 transactions and withdrawn 1967.3 ETH across 233 transactions. APT-based Clustering Heuristics. We introduce four clustering heuristics based on the insight of APT operations (see Fig. 7). 1. (H1) User 1 is a master that coordinated/funded an APT involving a phishing that funded User 2.

Example. We consider the following two depositors (d1 : 0xdaa6849270123f7c0b437cbd4ed24ca24825c838, d2 : 0x536c3985d527b5ed823e6aa4f197e5bcf97ca53f) and one withdrawer (w: 0xe6ac0419c8737e6707d2d5c95c445a cab860772e). Being involved are also two phishing addresses (p1 : 0xDA63e7BEEbFEeedB4CCfc7c295A54cEd3329FB95, p2 : 0x9Fc67C82051D3C5839D4f1d35D9C37fcb58EaD98), two masters (m1 : 0xA8f409e600AC692f88038465ca1491 7aDF5fD47B, m2 : 0x675780CBd38AEEbE2Dc127F3676AA2 aAC676FC3F), and a laundering funder (lf: 0x4a9B236E55 A0dC226648018EF89B3e9FD41FF6fF). First, w withdrew 9.95 ETH from TC 10, then funded several masters including m1 and m2 . These masters coordinated thousands of token APTs, which involved phishing addresses such as p1 and p2 , before transferring the remaining amounts back to w. Based on the event timestamps, we observe that once these phishing addresses received the transfers from victims, the (common) laundering funder lf immediately transferred some ETH in so that they can pay fees to transfer the proceeds to d1 , which deposited ETH into TC. This depositor also transferred large amounts to d2 , which then also deposited into TC, ending a successful scam cycle. We end this section by adding a remark that apart from address grouping, we also discuss in Appendix J a few intriguing case studies in which we attempted to use scam signatures to match potential TC depositors and withdrawers.

2. (H2) User 1 is a distributor that funded a master that coordinated/funded an APT involving a phishing that funded User 2. 3. (H3) User 1 is a distributor funder that funded a distributor that funded a master that coordinated/funded an APT involving a phishing that funded User 2. 4. (H4) User 1 is a laundering funder that funded a successful phishing address that funded User 2. We also use two common heuristic that prove to be most useful in previous works such as [25]: (H5) - User 1 and User 2 have a direct asset transfer, and (H6) - Two depositors have a common funder. Findings. We have found 16 connections using (H1), 380 connections using (H2), 49 connections using (H3), 91 connections using (H5), and 53 connections using (H6). Note that these do not necessarily correspond to unique pairwise connections. Using (H5) and (H6) alone, we found 182 groups (connected components) among all tainted depositors and withdrawers, with sizes 17, 6, 5, 4, 4, etc. Using our heuristics alone, we obtained 174 groups of sizes 16, 11, 9, 4, 4, etc. Combining (H1)-(H6), these improve to 149 clusters with sizes 17, 16, 9, 8, 5, etc. We note that (H1)-(H4) can explain the semantic behind certain asset transfers. Also, the link 12

7

Related Work

8

Limitations

We acknowledge potential false positives/negatives in our datasets. The APT dataset (Section 3) may contain false positives where a user has addresses with identical first and last digits, either accidentally (this is rare according to [23]) or intentionally. It may also miss APTs in which phishing and benign addresses match fewer than three first and last digits (should also be rare given that such attacks are less effective). It may miss genuine-token APTs that use tokens out of our top 100, which could have been popular before, but not anymore when we built our list. We can also miss fake-token APTs with symbols that do not conform to our definition. The search for masters of each phishing address (Section 4) may fail for some rare cases, e.g. when the phishing address of an active nonzero genuine-token APT only has one coin funder and no token funder as anticipated. The reason is that the phishing address could have performed a swap of ETH for the necessary token used in the APT. This is rare because of the costly economic: swapping for tokens requires multiple steps and is usually more expensive than directly transferring tokens (or bundled in a batch contract call). The master fundings and APTs may not be paired correctly from time to time (as transactions might not be perfectly ordered in time), leading to noisy data when gathering the master’s signatures. However, we purposely design the consistency scores and flattened signatures to eliminate such noise. Finally, our collected data do not cover the period before 11/2022 and after 5/2025, which could lead to edge cases due to insufficient data, especially for transactions occurring near the period boundary.

APT Scams. The rise of address poisoning scams has recently attracted attention from the security research community [7,15,23,29]. Ye et al. [29] investigated zero-value APTs between July 2022 and June 2023 for ERC-20 tokens. Guan and Li [15] covered a wider range of address-poisoning scams on Ethereum between 11/2022 and 2/2024 using USDT and USDC and their counterfeits, covering genuine-token APTs and fake-token APTs. Chen et al. [7] studied the same types of address poisoning scams as [15] between 12/2022 and 10/2023, but extended the token range to cover a few other high-value tokens on Ethereum such as ETH, WETH, stETH, WBTC, BUSD, in addition to USDT and USDC. Tsuchiya et al. [23] further included BEP-20 tokens on BNB Smart Chain in their investigation. The main focus of prior work on APTs [7, 15, 23, 29] includes: (i) APT detection and statistical characterisation, (ii) victim and financial loss analysis, and (iii) address clustering using the scam-operation principle based on relationships among master addresses, phishing addresses, and APT/fake-token contracts. One exception is that Chen et al. [7] performed address clustering based on the cashingout/laundering process, however, ignored token swaps with DEXs. Tsuchiya et al. [23] also investigated the possibility of scammers using GPUs to generate phishing addresses that look similar to benign ones. We identify four research gaps in the state-of-the-art: (i) limited understanding of APT funding mechanisms, (ii) lack of formalisation and systematic analysis of behavioural scam signatures, (iii) insufficient investigation of how scam proceeds are laundered through public services (including CEXs, DEXs, and mixers), and (iv) the absence of studies on tracing activities across mixers such as Tornado Cash. We note that Tsuchiya et al. was the first to observe that some large APT groups use similar APT and fake-token contracts [23]. Address grouping/clustering is a fundamental problem in blockchain intelligence that has been the subject of extensive academic research ( [3, 16, 19, 20, 24] and references therein) as well as industry commercial development ( [5, 10, 22]). For law enforcement, identifying groups of addresses likely controlled by the same entity is valuable, as it can help link fraudulent activities (e.g. conducted by one address) to realworld identities (e.g. when another address in the group interacts with a KYC-compliant CEX). Most existing approaches rely on transaction histories, neighbourhood relationships, and address-level features. Tornado Cash demixing is a special case of address clustering. Matching depositors and withdrawers on TC is especially challenging due to its zero-knowledge-proofbased privacy mechanism, the lack of ground truths, and is often done case by case (see, e.g. ZachXBT’s investigation [30]). State-of-the-art research is based on either heuristic approaches [25, 27] or machine learning [11].

9

Conclusions and Future Work

In this work, we study important aspects of AddressPoisoning Transfer scams on Ethereum that have previously been overlooked in the literature, including funding mechanisms, scam signatures, and proceeds laundering. Our proposal of scam signatures gives rise to a complementary approach to traditional address clustering methods, which often rely heavily on the asset transfer network among addresses. Restricting to a specific type of scam provides abundant context for clustering, as scammers often follow distinctive operational patterns. Using scam signatures allows for the potential tracing of scammers through mixers, such Tornado Cash. This method succeeds where traditional network-based approaches fail, specifically when there are no direct or indirect transfer activities between depositors and withdrawals and their nearby neighbours. Extensions of this approach to other types of on-chain scam such as Rug Pulls and Ponzi are left for future work. We also observed that APT scammers sometimes reinvested their scam proceeds to initiate a new round of scams. We leave the investigation of scam reinvestment for future research. 13

References

[13] Google Cloud. Google BigQuery, 2026. URL: https: //cloud.google.com/blog/products/data-analy tics/ethereum-bigquery-public-dataset-sma rt-contract-analytics.

[1] Binance. Binance CEO discusses $20 million scam attempt, 2023. URL: https://www.binance.com/en -IN/square/post/910258. [2] Vitalik Buterin. A next-generation smart contract and decentralized application platform, 2013. URL: https: //ethereum.org/en/whitepaper/.

[14] Jens Groth. On the size of pairing-based non-interactive arguments. In Advances in Cryptology – EUROCRYPT 2016, volume 9666 of Lecture Notes in Computer Science, pages 305–326. Springer Berlin Heidelberg, 2016. doi:10.1007/978-3-662-49896-5_11.

[3] 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, 2021. URL: https://doi.org/10.1109/DAPPS52256.2021.00 013.

[15] Shixuan Guan and Kai Li. Characterizing Ethereum address poisoning attack. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, CCS ’24, page 986–1000, 2024. doi:10.1145/3658644.369027. The un[16] Martin Harrigan and Christoph Fretter. reasonable effectiveness of address clustering. In 2016 Intl IEEE Conferences on Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), pages 368–373, 2016. doi:10.1109/UIC-ATC-ScalC om-CBDCom-IoP-SmartWorld.2016.0071.

[4] Chainalysis. Anatomy of an address poisoning scam, 2024. URL: https://www.chainalysis.com/blog /address-poisoning-scam. [5] Chainalysis. The data accuracy flywheel: How Chainalysis consistently identifies and verifies blockchain entities, 2024. URL: https://www.chainalysis.com/ blog/chainalysis-data-accuracy/. [6] Chainalysis. The 2025 crypto crime report, 2025. URL: https://www.chainalysis.com/wp-content/upl oads/2025/03/the-2025-crypto-crime-repor t-release.pdf.

[17] Yicheng Huo, Yufeng Hu, Yajin Zhou, Ting Yu, Lei Wu, and Cong Wang. Shedding light on shadows: Automatically tracing illicit money flows on evm-compatible blockchains. Proc. ACM Meas. Anal. Comput. Syst., 9(3), 2025.

[7] Zhuo Chen, Yufeng Hu, Bowen He, Dong Luo, Lei Wu, and Yajin Zhou. Dissecting payload-based transaction phishing on Ethereum. In Usenix Network and Distributed System Security Symposium (NDSS), pages 1– 18, 2025. doi:10.14722/ndss.2025.230311.

[18] Phuong Duy Huynh, Son Hoang Dau, Nicholas Huppert, Joshua Cervenjak, Hoonie Sun, Hong Yen Tran, Xiaodong Li, and Emanuele Viterbo. Serial scammers and attack of the clones: How scammers coordinate multiple rug pulls on decentralized exchanges. In Proceedings of the ACM on Web Conference 2025, WWW ’25, page 1016–1033, 2025. doi:10.1145/3696410.3714919.

[8] CoinGecko. CoinGecko API Documentation, 2026. URL: https://docs.coingecko.com/. [9] Cointelegraph. Scam alert: MetaMask warns crypto users about address poisoning, 2023. URL: https: //www.binance.com/en/square/post/158741.

[19] Shlomi Linoy, Natalia Stakhanova, and Alina Matyukhina. Exploring Ethereum’s blockchain anonymity using smart contract code attribution. In 15th International Conference on Network and Service Management (CNSM), pages 1–9, 2019. URL: https://dl.ifip.org/db/conf/cnsm/cnsm2019/ 1570563994.pdf.

[10] Crypto Track. Crypto track pro, 2026. URL: https: //www.ctpro.io/products/ct-pro/. [11] Hanbiao Du, Zheng Che, Meng Shen, Liehuang Zhu, and Jiankun Hu. Breaking the anonymity of Ethereum mixing services using graph feature learning. IEEE Transactions on Information Forensics and Security, 19:616–631, 2024.

[20] Malte Möser and Arvind Narayanan. Resurrecting address clustering in Bitcoin. In Ittay Eyal and Juan Garay, editors, Financial Cryptography and Data Security, pages 386–403, 2022. URL: https://doi.or g/10.48550/arXiv.2107.05749.

[12] Etherscan. Etherscan APIs, 2026. URL: https://et herscan.io/apis. 14

[21] Alexey Pertsev, Roman Semenov, and Roman Storm. Tornado cash privacy solution version 1.4, 2019. URL: https://berkeley-defi.github.io/assets/mat erial/Tornado%20Cash%20Whitepaper.pdf.

[30] ZachXBT. How Lazarus group laundered $200m from 25+ crypto hacks to fiat from 2020–2023, 2024. URL: https://paragraph.com/@investigations/ho w-lazarus-group-laundered-200m-from-25-cry pto-hacks-to-fiat-from-2020-2023.

[22] TRM Labs. The rise of Monero: Traceability, challenges, and research review, 2024. URL: https://www.trml abs.com/resources/blog/the-rise-of-moner o-traceability-challenges-and-research-rev iew.

A

Open Science

To support reproducibility and open science principles, we provide the following artefacts:

[23] Taro Tsuchiya, Jin-Dong Dong, Kyle Soska, and Nicolas Christin. Blockchain address poisoning. In 34nd USENIX Security Symposium (USENIX Security 25), pages 1243–1262, 2025. URL: https://www.usenix .org/system/files/usenixsecurity25-tsuchiy a.pdf.

• Codebase: The source code for our data collection, clustering, and analysis is available at https://anonymous.4o pen.science/status/apt-network.

[24] Friedhelm Victor. Address clustering heuristics for Ethereum. In 24th International Conference on Financial Cryptography and Data Security, page 617–633, 2020. URL: https://doi.org/10.1007/978-3-030-512 80-4_33.

A.1

• Dataset: The anonymised datasets generated and used for evaluation are uploaded to the same Codebase repository

Data Artefacts

The submitted artefact contains a structured data snapshot intended to support schema inspection, validation of the construction logic on representative records, and reproduction of analyses over the released derived artefacts. Unless otherwise specified, all paths are relative to the dataset-submission/ directory. The artefacts herein are not intended to constitute a complete reproduction of all raw or intermediate datasets used in this work.

[25] 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, WWW ’23, page 2022–2032, 2023. [26] Jiajing Wu, Dan Lin, Qishuang Fu, Shuo Yang, Ting Chen, Zibin Zheng, and Bowen Song. Toward understanding asset flows in crypto money laundering through the lenses of ethereum heists. IEEE Transactions on Information Forensics and Security, 19:1994–2009, 2024. doi:10.1109/TIFS.2023.334627.

A.1.1

Address-Poisoning Samples

We provide a sample of the three APT datasets: the coin subset, the genuine-token subset, and the fake-token subset. These subsets are stored in the normal/, token/, and fake-token/ subdirectories of address-poisoning/. They cover coin transfers, genuine-token transfers, and fake-token transfers.

[27] Mike Wu, Will McTighe, Kaili Wang, Istvan A. Seres, Nick Bax, Manuel Puebla, Mariano Mendez, Federico Carrone, Tomás De Mattey, Herman O. Demaestri, Mariano Nicolini, and Pedro Fontana. Tutela: An opensource tool for assessing user-privacy on Ethereum and Tornado Cash, 2022. URL: https://arxiv.org/ab s/2201.06811, arXiv:2201.06811.

A.1.2

Victim Transfer and The Laundering Graph

We provide the Victim transfer list, which contains information about the incidents, such as how much a victim has lost and which APT caused it. The laundering graph is provided in laundering-dataset/. Each row corresponds to a traced laundering edge from the algorithm F IND L AUNDER ING F ROM .

[28] Chuyi Yan, Chen Zhang, Meng Shen, Ning Li, Jinhao Liu, Yinhao Qi, Zhigang Lu, and Yuling Liu. Aparecium: Understanding and detecting scam behaviors on Ethereum via biased random walk. Cybersecurity, 6, 10 2023. doi:10.1186/s42400-023-00180-x.

A.1.3

[29] Guoyi Ye, Geng Hong, Yuan Zhang, and Min Yang. Interface illusions: Uncovering the rise of visual scams in cryptocurrency wallets. In Proceedings of the ACM Web Conference 2024, WWW ’24, page 1585–1595, 2024. doi:10.1145/3589334.364534.

Funding activities

We provide multiple csv files that record funding operations: (1) from distributor to master; (2) from master to APT phishing; and (3) funding to successful phishing addresses before or during laundering activity. All under funding-activities/. 15

A.1.4

APT Scam Signatures

evade future detection. However, public disclosure of these mechanisms is necessary to advance defensive countermeasures, enable the development of robust detection models, and ultimately protect blockchain scam victims.

We provide multiple csv files that list all the scam signatures of the master addresses of interest. Available under scam-signatures/. A.1.5

C

Tornado Cash Grouping

GitHub Copilot, Cursor, Codex were utilised as coding assistants in the writing of the software implementation for this research. All AI-generated code was manually reviewed, executed, and validated by the authors to ensure functional correctness and accuracy prior to inclusion in the final experimental framework. This paper was edited for grammar and style using Writefull and ChatGPT.

We provide csv files that show identified connections of Tornado Cash users via different heuristics. Available under tc-grouping/. A.1.6

Market Data and Fake Tokens

We provide the pricing data of genuine ERC20 tokens examined in this study; along with the fake-token addresses that mimic those genuine ERC20 in the path resources/data. A.1.7

D

Excluded data

D.1

The complete database used is not redistributed because it contains full-scale public Ethereum transactions consisting of normal and internal transactions, token transfers, and receipt tables, whose size makes artefact hosting impractical. The artefact set also excludes private database configuration files, local caches, full PostgreSQL chain tables, and intermediate working files that support our internal analysis.

B

Generative AI Usage

Data Collection Fake Token Data Collection

To identify fake tokens, we design a matching algorithm to find these traits: (1) Fake token, T , has the same symbol as one of the top-100 tokens with a different contract address; (2) T has a symbol of edit-distance 1 from a top-100 token symbol and either (2a) has a flawed contract permission logic or (2b) does not have a verified contract on Etherscan. Step 1 - Data Collection. We retrieve metadata for the top 600 cryptocurrency tokens from CoinGecko’s public API by market capitalisation, establishing a baseline dataset of legitimate token symbols and their corresponding contract addresses. This is an attempt to address false positive cases, such that some symbols trying to mimic a token that is not in the top 100, but is highly similar (e.g. oUSDT is highly similar to USDT, so oUSDT will be classified as counterfeit). Subsequently, we obtained the complete list of unique contract addresses from the token transfer dataset from Google BigQuery to extract complete contract interaction data. Step 2 - Token Analysis and Matching. This step implements a dual-criterion detection system. Step 2a - Type 1 detection. We employ string similarity analysis similar to that of Taro et. al. [23]. This step uses three primary pattern recognition strategies to normalise a symbol:

Ethical Considerations

This research involves the analysis of public blockchain transactions, specifically targeting APT phishing scams and subsequent fund laundering. The following ethical protocols govern the methodology and publication of findings: • Data Privacy and Acquisition: All data analysed in this study consists of publicly available transaction logs from the blockchain ledger. Address attributions and identity heuristics utilise pre-existing public labels sourced from block explorers (e.g., Etherscan). No private, proprietary, or off-chain personally identifiable information (PII) was collected, nor was any independent active probing conducted to link addresses to real-world identities.

1. Additional character insertion: where tokens append extra characters to legitimate symbols such as transforming USDT to USDTT,

• Address Clustering Limitations: The address clustering technique based on scam signatures is designed to trace illicit APT scam proceeds and identify associated malicious actors. It targets addresses exhibiting specific scam-related behavioural signatures and is not intended to de-anonymise legitimate users of mixing services. In the absence of such signatures, legitimate users are unlikely to be clustered by our method.

2. Leetspeak substitution recognises number-letter replacements such as converting DAI to D4I, and 3. Unicode homoglyph substitution identifies visually similar characters from different character sets, such as Cyrillic letters substituted for Latin equivalents. For example, by substituting the Latin ‘S’ and ‘C’ with the Cyrillic homoglyphs ‘S’ (U+0405) and ‘C’ (U+0421), the ticker appears identical to USDC.

• Dual-Use Assessment: The formalisation of scam signatures and laundering patterns presents a theoretical dual-use risk, as malicious actors could analyse these heuristics to 16

Fake-Token DVT Dataset Construction Step 1. Identify the set TSfake of fake-token transfers in which both senders and receivers are EOAs and not identical. Step 2. From the set TSfake of fake-token transfers identified in Step 1, construct the set TAfake of fake-token APTs and assign relevant labels to them as follows. For each transfer t = (s, r) ∈ TSfake of a fake token τ, first check if it is a forward APT, by searching the transaction history of r. If there was a nonzero transfer of τ’s genuine counterpart ℓ = (r, b) that happened before t such that b ̸= s but b and s share at least three first and last digits, then include t in TAfake as a forward APT with s as the phishing address. If t doesn’t satisfy that condition, then examine the transaction history of s and look for a nonzero transfer ℓ = (s, b) of τ’s genuine counterpart that happened before t such that b ̸= r but b and r share at least three first and last digits (ignoring the case). In that case, include t in TAfake as a backward APT with r as the phishing address. In either case, we refer to ℓ as the legitimate transfer associated with t and b its benign address. Lastly, if the sender of the normal transaction with the same hash as t coincides with the phishing address then t is labelled active APT. Otherwise, it is passive, and the sender of the normal transaction is referred to as the APT coordinator.

After normalisation, the edit distance of the symbol from its legitimate symbol is calculated. At this point, tokens that have an edit distance of 0 from the real token in the top 600 list are deemed fake. Step 2b - Type 2 detection. If the token in step 1 has an edit distance of 1, we implement behavioural contract analysis, similar to the approach of Guan and Li [15]. Specifically, the system attempts to trigger the transfer function using test accounts with insufficient balances and the transferFrom function without proper allowances. Legitimate contracts should reject these operations, while fraudulent contracts often implement permissive logic allowing unauthorised transfers, thereby revealing their malicious nature. We also check if the token address exists in the list of Etherscan verified contracts. Therefore, a token symbol of distance 1 is fake if its contract is flawed or not verified on Etherscan. In total we collected a list of 55,064 fake-token addresses.

D.2

Tornado Cash Data Collection

Table 3: The numbers of deposit and withdrawal transactions in Tornado Cash ETH pools (11/2022–05/2025). These account for about (98%) of all activities on Tornado Cash in this period.

E E.1

Pool

No. deposits

No. withdrawals

100 10 1 0.1

7,748 10,840 10,264 6,945

7,025 10,446 10,045 6,796

A few important points to clarify the APT dataset construction. In Step 1, we require that both senders and receivers of an APT must be EOAs. This is because while scammers can use contracts to perform multiple transfers simultaneously (for funding or scamming) to save gas cost, it is unlikely that the phishing address itself is a contract address for several reasons: 1) deploying a contract requires on-chain storage and computation cost, which is expensive, and 2) a single contract can only be used as a look-alike phishing address for very few target addresses (due to the randomness of addresses), which would further increase the cost of APT.

APT Datasets Dataset Construction

We include in this appendix the sub-procedures for finding coin APTs and fake-token APTs. Coin APT Dataset Construction Step 1. Identify the set TScoin of all suspicious normal transfers with (historical) values at most 3 USD in which both senders and receivers are EOAs and not identical (see Remark E.1). Step 2. Based on TScoin , construct the set TAcoin of coin APTs as follows. For each transfer t = (p, a) ∈ TScoin , where p and a are potential phishing and target address, respectively, search the normal transaction history of a. If there is a nonzero transfer of the same coin ℓ = (a, b) that happened before t such that b ̸= p but p and b share at least three first and three last characters (ignoring the case), then include t in TAcoin . Here ℓ is a legitimate transfer associated with t ∈ TAcoin and b its benign address.

In Step 2, we require that the legitimate transfer ℓ has a nonzero value, for otherwise we may mistakenly identify a zero-value victim-to-phishing transfer as a legitimate one. Note that as opposed to Guan-Li [15], we do not require that ℓ is non-suspicious in the first two procedures, because it is possible that ℓ is a test transfer of a small value and hence would belong to the set of suspicious transfers in Step 1. Lastly, to speed up the search for APTs, we apply the method from Tsuchiya et al. [23] and let the algorithm scan for a potential legitimate transfer within a 20-minute window preceding the APT of interest, and only searching the entire history of the relevant address if such a transfer is not found. 17

E.2

Analysis

consent and authorisation.

Our analysis encompasses 56,363,713 APTs spanning 918 days of blockchain activity (1 November 2022 – 7 May 2025), providing insight into the evolution and sophistication of address poisoning attacks. Our token APT datasets and those from Tsuchiya et al. [23] overlap significantly, with 16,076,923 common records (30.6% of ours, 92.6% of Tsuchiya et al.). The nonoverlapping parts (36,431,096 unique to ours and 1,289,030 unique to Tsuchiya et al. are due to different temporal coverage (ours 11/2022–05/2025 compared to 7/2022–6/2024); another reason is the differences in fake token identification - we follow the approach in Guan-Li [15], which focuses on fake tokens mimicking the top 100 tokens by market capitalisation. Table 4 summarises the transaction type data collected.

E.2.1

Table 5 shows the distribution between tokens across the APT datasets. USDT dominates the transfer volume and stablecoins (USDT, USDC, and DAI) account over 98.8% of all APTs. Table 5: Distribution of APT by token for both genuine token and fake token data shows USDT and USDC make up the majority of all APT activity. Genuine Token

Table 4: Comparison of our APT Dataset against relevant publications showing number of transactions grouped by coin, token, and fake token.

Fake Token

Genuine Token

Coin

Our Dataset (%) Zero Nonzero

667 483 3 188 211

Total

3 855 694

Zero Nonzero Forward Backward Active Passive

12 121 499 2 678 450 2 910 129 11 889 820 2 448 299 12 351 650

Total

14 799 949

Forward Backward Active Passive

102 034 37 606 036 6 37 708 064

Total

37 708 070

CMU Dataset (%)

17.3 82.7

– –

81.9 18.1 19.7 80.3 16.5 83.5

7 185 298 308 881 491 757 7 002 422 – – 7 494 179

0.3 99.7 0.0 100.0

134 233 9 737 542 – – 9 871 775

PTXPhish

104 22 – – – –

Transfers

(%)

Fake Token

Transfers

(%)

USDT USDC DAI WETH WBTC Others

10,524,432 3,818,807 212,010 45,895 36,870 161,935

71.1 25.8 1.4 0.3 0.2 1.1

fake_USDT fake_USDC fake_DAI fake_LINK fake_WBTC Others

25,726,615 11,010,611 454,049 193,640 93,201 229,954

68.2 29.2 1.2 0.5 0.2 0.6

Total

14,799,949

100.0

Total

37,708,070

100.0

E.2.2

126 1.4 98.6

Fake Token

Token

Note: Transfers are counted per token symbol across all addresspoisoning transactions. Fake-token totals include both zero-value (0.2%, 23,734) and non-zero-value transfers (99.8%, 14,024,968). Stablecoins (USDT, USDC, DAI) account for 98.8% of APTs, consistent with prior work [15, 23].

– –

95.9 4.1 6.5 93.5

Token Distribution

Address Similarity

Primary attack concentrations occur at low-complexity configurations, peaking at the 4-character head and 4-character tail (4,4) match configuration with 17.4 million attempts, followed by 15.9 million attempts at the (3,6) match configuration. A secondary cluster occurs at (7,8), with over 1.4 million attempts, indicating substantial computational resources used to generate these APT addresses.

– – – – 100

The APT dataset comprises 3,855,694 direct Ether transfers, 14,799,949 genuine ERC-20 token transfer events, and 37,708,070 fake-token transfer events. Due to Ethereum’s protocol, each native ETH transaction generates a single transfer event; these transfers are classified as 100.0% active and forward-directed because only private-key holders can initiate native ETH transactions. Genuine-token transfers are predominantly passive (12,351,650 transfers, 83.5%) and backwarddirected (11,889,820 transfers, 80.3%). These patterns emerge from ERC-20’s transferFrom mechanism, where a token owner grants approval to a spender who then executes transfers from victim accounts to phishing addresses. Fake-token transfers show an even stronger pattern: 37,708,064 transfers are passive and only 6 are active, while 37,606,036 transfers (99.7%) are backward-directed. Like genuine tokens, multiple fake-token transfer events can occur within a single contract transaction call; counterfeit contracts can also implement arbitrary transfer logic and emit events independently of victim

F

Tracking APT Profit Laundering

In this appendix, we provide the algorithmic details of DYNAMIC L AUNDERING F LOW. For brevity, we present only the skeleton of our algorithm ignoring the swap logic and different token types. DYNAMIC L AUNDERING F LOW takes as input the sets of victim addresses V , the set of victim-to-phishing transfers TV , the set of Tornado Cash pool addresses D, and the depth limit k, and returns the dictionary L of all predicted scam-proceed laundering transfers within d hops from the victim addresses, as well as the dictionary LTC of transfers that go into Tornado Cash. The algorithm first adds all victim addresses to the queue, Q, and sets their depth at 0. While Q is not empty, dequeue to obtain a node/address x and call F IND L AUNDER ING F ROM () to obtain all laundering transfers Lout from x. For 18

DynamicLaunderingFlow(V, TV , D, k):

FindLaunderingFrom(x, L,V, TV ):

1: Input: victim-address set V , victim transfers TV , TC pool

1: Input: an address x, the dictionary of laundering transfers

addresses D (or a set of public service addresses), depth limit k 2: L ← TV # a dictionary: key = transfer ID, value = (src, dst, τ, amt), where

L, the sets of victim addresses V and victim transfers TV 2: if x ∈ V then 3: Lout ← victim transfers in TV from x return Lout # if x is a victim, return the (known) victim transfers from v 4: 5: Lin ← laundering transfers to x in L, ordered by τ (time) 6: Lout ← ∅ # a dictionary of laundering transfers from x

src is sender, dst is receiver, τ is time stamp, amt is laundering amount

3: LTC ← ∅ # laundering transfers entering Tornado Cash pools 4: Q ← ∅ # the queue for nodes/addresses to be (re)processed 5: depth[·] ← −1 # initialise depth -1 for every node 6: for all v ∈ V do 7: E NQUEUE(Q, v); depth[v] ← 0 8: while Q ̸= ∅ do 9: x ← D EQUEUE(Q) 10:

Lout ← F IND L AUNDERING F ROM(x, L,V, TV ) # Lout con-

11: 12:

for all ℓ ∈ Lout do if (ID(ℓ) ∈ / L) or (ID(ℓ) ∈ L but with a smaller amt) then U PDATE(L, ℓ) # if ID(ℓ) ∈/ L: add ℓ to L, else: update amt y ← dst # the receiver of the laundering transfer ℓ from x if depth[y] = −1 then depth[y] ← depth[x] + 1 # y hasn’t been visited before else depth[y] ← min{depth[y], depth[x] + 1} if y ∈ / Q and depth[y] < k and y ∈ / D then E NQUEUE(Q, y) # unlike in standard BFS, y is reprocessed

7: Tout ← the list of out-going transfers from x that occur

after at least one transfer in Lin , ordered from old to new 8: for all t ∈ Tout ordered by τ(t) from old to new do 9: σin ← ∑ℓ∈Lin :τ(ℓ)<τ(t) val(ℓ) # total incoming laundering by τ(t) 10: σout ← ∑ℓ∈Lout :τ(ℓ)<τ(t) val(ℓ) # total outgoing laundering by τ(t) 11: a ← min{σin − σout , val(t)} # t launders as much as possible 12: if a > 0 then
13: ℓout ← key = ID(t), value = (x, dst(t), τ(t), a) 14: Add ℓout to Lout 15: return Lout

tains all laundering transfers from x

13: 14: 15: 16: 17: 18: 19: 20:

F IND L AUNDERING F ROM takes as input an address x, the dictionary of currently known laundering transfers L, and the set of victim transfers TV , and outputs the dictionary Lout of outgoing laundering transfers from x. If x is a victim, the algorithm simply returns the known victim transfers from x. Otherwise, let Lin be the dictionary of laundering transfers in L to x, and Tout be the ordered list of outgoing transfers from x that occur after at least one transfer in Lin . For each t ∈ Tout ordered from oldest to newest, the algorithm computes the total amount σin of incoming laundering transfers in Lin and the total amount σout of outgoing laundering transfers in Lout before the time τ(t). The balance of laundering funds, σin − σout , is the amount available to be transferred out at time τ(t) for x. The laundering amount a for t is thus the minimum of σin − σout and val(t). If a > 0, then the algorithm identifies t as an outgoing laundering transfer ℓout from x with a as the laundering amount and adds it to Lout . Our underlying assumption is that scammers prioritise laundering speed over other activities. In other words, if there are still proceeds not yet laundered, then the next outgoing transfer will use as much as possible. A step-by-step demonstration of how our algorithm works can be found in Example 9 in Appendix F. We use an example to demonstrate key steps in the DYNAM IC L AUNDERING F LOW algorithm presented in Section 6.1.

whenever there’s a novel incoming laundering transfer

21: if y ∈ D then 22: U PDATE(LTC , ℓ) # similar to Line 13 23: return L, LTC

each ℓ ∈ Lout , if ℓ is new, i.e. either its ID is not already included in L, or its val is smaller than the new val, update L with ℓ (add ℓ to L or update its val). In either case, let y be the receiver of ℓ, setting its depth if necessary. If y has not reached the max depth k and is not a TC depositor, then add y to the queue for processing. The algorithm always terminates because the number of nodes entering the queue (apart from the victim addresses) is bounded from above by the number of laundering edges. Unlike BFS, a node can be added to Q and processed multiple times: whenever the algorithm identifies a novel incoming laundering transfer to a node y, it adds y to the queue to recompute outgoing laundering transfers from y. This is crucial for accurately capturing the laundering transfers (see Example 9 in Appendix F). An output of DYNAMIC L AUNDERING F LOW is the total amount of all ℓ ∈ LTC that gives an estimate of the total amount of scam proceeds that flow into Tornado Cash. Our algorithm operates under the assumption that scammers try to launder proceeds as fast as possible (discussed next). Furthermore, due to the depth limit, this estimation serves as a lower bound for the true amount.

Example 9. To illustrate how DYNAMIC L AUNDERING F LOW works, consider an example with three victims V = {v1 , v2 , v3 }, two phishing addresses P = {p1 , p2 }, two intermediate addresses q1 , q2 , and one TC pool address d (see Fig. 9). Set the exploration depth k = 3. We have TV = {t1 ,t2 ,t5 }, with values given in Fig. 9, e.g. val(t1 ) = 10. The label val(ℓi ) in the figure refers to the laundering amount carried by the corresponding transfer ti , which can be smaller than val(ti ). We assume that ti occurs before t j if i < j. The 19

G.1

Asset flows show a shift from stablecoin-heavy theft to ETHheavy exit. At entry, victims mainly transfer stablecoins: USDT accounts for 1,012 victim-to-phishing edges totaling $61.60M, and USDC for 394 edges totaling $20.14M. ETH is still material, with 327 edges and $12.21M in losses, while DAI accounts for 28 edges totaling $2.00M. Aggregate losses are heavily influenced by four WBTC transfers totaling $68.47M, including one historically notable but atypical transfer worth $68.46M. At observed exits, ETH dominates: it carries $47.68M across 1,149 edges, with WETH contributing another $4.83M across 19 edges. The contrast is especially clear for clusters that ultimately route funds to TC. Their entry assets total $34.72M across 263 victim edges, of which USDT and USDC account for 239 edges and 79.77% of value. Direct inflows to TC are almost entirely ETH, comprising 422 edges totaling $38.09M, alongside one USDT edge worth approximately $100. In short, funds are often collected in stable-value assets and exited through ETH.

Figure 9: Illustration of DYNAMIC L AUNDERING F LOW. Here vi ’s, pi ’s, qi ’s, and d represent victim, phishing, intermediate, and TC pool addresses, whereas ti ’s and ℓi ’s represent the transfers and the laundering transfers, respectively.

queue Q first contains v1 , v2 , v3 (as of Line 6-7 in DYNAMI C L AUNDERING F LOW ). After these victim addresses are processed, the dictionary of laundering transfers L = {ℓ1 , ℓ2 , ℓ3 }, where ℓi is identical to ti , i = 1, 2, 3. Also, Q = (p1 , p2 ). In Iteration 1, p1 is dequeued from Q, which has Lin = {ℓ1 ≡ t1 } with val(ℓ1 ) = val(t1 ) = 10. As t7 occurs after ℓ1 , Lout = {ℓ7 } with val(ℓ7 ) = 10 (it will become 15 in a later iteration when p1 is processed the second time). We have L = {ℓ1 , ℓ2 , ℓ3 , ℓ7 }, Q = (p2 , q1 ).

G.2

Services

Tornado Cash is the dominant service used for laundering APT scam proceeds. We provide detailed usage statistics for Tornado Cash ETH pools in Table 6. Here we use historical USD price for ETH.

In Iteration 2, p2 is dequeued, which has Lin = {ℓ2 , ℓ5 }, Tout = {t3 ,t6 }. First, ℓ2 occurs before t3 , and so, val(ℓ3 ) = min{val(ℓ2 ), val(t3 )} = min{8, 6} = 6. Next, both ℓ2 and ℓ5 occur before t6 , and so, val(ℓ6 ) = min{val(ℓ2 ) + val(ℓ5 ) − val(ℓ3 ), val(t6 )} = min{8 + 3 − 6, 7} = 5. We have L = {ℓ1 , ℓ2 , ℓ3 , ℓ5 , ℓ7 }, Q = {q1 , q2 , p1 }. Note that p1 is enqueued the second time.

Table 6: Tornado Cash usage statistics for APT laundering (11/2022–05/2025).

Fast forward to Iteration 5, p1 is dequeued, and its Lin = {ℓ1 , ℓ6 }, where ℓ6 is the newly identified laundering transfer into p1 in Iteration 2. Following Line 9-11 in F IND L AUNDERING F ROM, val(ℓ7 ) is updated from 10 to 15 = min{10+5, 20}. A typical BFS would miss this update. Eventually, the fund flow entering d is 18 = 12 + 6.

G

Flow of Assets

Pool

Deposits

ETH

USD ($M)

% Share

100 10 1 0.1

173 125 66 58

16,301.98 1,193.24 65.97 5.80

34.90 2.98 0.20 0.02

91.62 7.81 0.52 0.05

Total

422

17,566.99

38.09

100.00

G.3

Laundering Cluster Case-Studies

We present three exemplar clusters in Figure 10 to demonstrate APT asset flows towards transfers out to Tornado Cash. Figure 10a shows the simplest laundering topology among the three case studies. The phishing address appears three times in the victim’s history prior to the theft. The stolen value then follows a minimal victim → phishing → depositor → Tornado Cash chain: USDT is converted into 286.823 ETH and forwarded to the final depositor. Manual inspection indicates that the scammer then adds their own 13.4 ETH1 from FixedFloat to round up to 300 ETH to fit into the TC-100

Anatomy of the Laundering Networks

We analyse what happens after phishing addresses receive victim payments. Starting from the victim-to-phishing dataset, we trace any record of victim transfer to phishing address of above $1,000, yielding 1,832 seed transfers, and follow them for 15 hops using F IND L AUNDERING F ROM. The goal is to characterise how stolen funds are organised and moved after the initial theft. All USD values are computed from oracle prices at the time of each transfer.

1 tx:0x2ad464aaa5d36000e2466e6fc934c605df9cb7531e9e6528d80c19e3ee

affd9a

20

first transferred 0.00088027 ETH8 and then 0.2 USDC9 twelve seconds later (1 block later) to the phishing address 0x0E0A10 , which performed an APT of exactly 0.2 USDC in less than three minutes (11 blocks) later, with a fee of 0.00054222 ETH (less than what it received).

pool. This case also motivates us to design F IND L AUNDER ING F ROM to filter and constrain the laundering flow to avoid commingling with external funds. Figure 10b shows that the phishing address attacked twice before the 2000 ETH theft. After receipt, they split the funds into four sibling branches. One branch, 0x2be8e5...26bef9, first receives 496.99 ETH directly and later absorbs 2.56 ETH in residual transfers from its siblings before sending 498.8 ETH to Tornado Cash. This residue re-convergence inspired the node revisitation mechanism in F IND L AUNDERING F ROM, rather than regular BFS. Figure 10c provides the complementary large-graph case. Several victim-facing branches are preceded by repeated APTs, indicating an ongoing multi-target poisoning campaign rather than a single incident. The internal flow remains mixedasset, with multiple local consolidation points. The final cashout converges on the TC-100 pool.

H

Example 13 (Genuine-token APT, one coordinator, multiple coin funders). The phishing address 0x2aFa11 (labelled Fake_Phishing-55731 on Etherscan) received five coinfunding transfers from four different masters before it could cover the fee for the transaction12 that approved the contract labelled Fake_Phishing11700 to spend on its behalf (see Fig. 5). About six minutes (29 blocks) later, the master (coordinator) 0xefb3 (labelled Fake_Phishing11703 on Etherscan) called a function on this smart contract13 to perform 32 token transfers, corresponding to 16 APTs. In particular, the contract transferred 0.05 USDT to the phishing address in one transfer, then in the next, it transferred 0.05 USDT out of that node to a target node 0xD717. The same thing went for phishing addresses 0xfB6814 and 0x211C15 . This was perhaps caused by the fluctuation of the gas price, impacting the scammer’s prediction of the fee.

Master and Distributor Datasets

H.1

Examples of Master-Phishing Interactions Example 14 (Genuine-token APT, one coordinator, no coin funders). Consider the same phishing address 0x2aFa as in Example 13. It had no coin fundings before the master (coordinator) 0xc16a (labelled Fake_Phishing48029 on Etherscan) called a function on the smart contract labelled Fake_Phishing4803016 to perform 80 (zero-value) backward APTs, including one involving this phishing node. In total, 0x2aFa was involved in 14 such backward passive genuinetoken APTs.

Example 10 (Coin APT, direct funding). Fake_Phishing327990, which successfully got 72 million worth of WBTC after the APT attack (see Example 1), received a direct funding of 0.00021 ETH from the master 0xDCdd2 labeled Fake_Phishing343305, which funded more than twenty thousand phishing addresses. Example 11 (Coin APT, contract funding). The master 0x15523 , labeled Fake_Phishing463645, called the same contract labeled Fake_Phishing4646454 almost six thousand times, each call funding multiple phishing addresses in ETH. For instance, a single call on 12/3/20255 funded 14 phishing addresses, most of which performed an APT worth 0.000001 ETH with fee 0.00001155 ETH, summing up exactly to the funding 0.00001255 amount ETH. Note that some of the phishing addresses, e.g. 0x26606 also performed genuine-token APTs (e.g. USDT/USDC) and was funded by other contracts and masters.

Example 15 (Successful fake-token APT, one coordinator). The phishing address 0x4e7C1d617 were involved in two backward fake-token APTs, coordinated by the same master 0xA57118 using the same scam contract19 . The APT20 , in which the phishing address received 120,763.518627 fake USDC (identical to the amount of USDC in the benign transac8 tx:0x435a1cdbd991f7d190de791a0aebd1ab4d810d1ce4b9161a394d40eea8 2564d4 9 tx:0xb66d9465d0d2b36ab400d31aebbb6b7a08036f2446ea15f6a650483c55 6e3ee2 10 0x0E0A49391a6f9309cf6f576B470c7bBc1ce070F9 11 0x2aFa81f87BC9ABC0fFfE88cd92b8CBF5D4B38BCE 12 tx:0x602406479e8050b6bf2b84c321549d908c7e1de6e3dce9bbc02c76ba26 542672 13 tx:0x3a927afd654d7c74b3420b9f85a0aba6ee85471da057895df54e939e16 424d38 14 0xfB68e1531B752aA77Fb1db8e199F934595264954 15 0x211C50FedA71148a072aAB5741369228dFe2c882 16 tx:0x4a25cdebe1a39e672b452e9c4628be56d3e21f42568b59245456f42a68 33afac 17 0x4e7C1d68eD7bD6754e7ddD3863836b5cAec7ea87 18 0xA57188bD032cf7fA7319608f0FD9F155b387205D 19 0x4b018B99d990825079C9794c382DfAa8bbd395a6 20 tx:0xb13375c675d4fd021586aea0de717b104b982d86ec2ed0cb857aa94be3 2484af

Example 12 (Master funding ETH and USDC directly). The master 0x3C6a7 , labeled Fake_Phishing442895, funded more than ten thousand phishing addresses using the same mechanism: first transferred ETH, then the token, which allows the phishing address to perform a token APT. For instance, it 2 0xDCddc9287e59B5DF08d17148a078bD181313EAcC 3 0x1552dE3db8B4c9E0f7e9a426623b4469D1f10931 4 0xf396998cd79369fE3b4F336Ab2f5F438f238Ab2a 5 tx:0xa136f83785440a3c16dc0caf35258408246f64de1bf6c3358f65dbaae2 afb51b 6 0x266098D6fE5F706516Cc24Eefd83E3321585A68D 7 0x3C6a325bE174845bC4889C37be70B18DB4EFC2f1

21

(a) Minimal victim → phishing (0xe07222cb87725f1e88ef48dd17e9a8ccb86adfea) → depositor → Tornado Cash chain. The scammer tops up by 13.4 ETH (see the history of 0xdc07748cbc104005bd077a4dd758440fc011dc7e) to send 300 ETH to the TC-100 pool.

(b) The phishing address (0xba8ba758357d82a2862e1369d51c983a2a05c0e6) successfully acquires 2000 ETH, splits it into 4 sibling branches and consolidates to ensure a round number eligible for the TC-100 pool. A total of 1998.8 ETH is transferred to TC.

(c) A large-graph case indicating an ongoing multi-target poisoning campaign. The internal flow is mixed-asset; the final cash-out converges on the TC-100 pool (top). Some of the phishing addresses includes: 0x06b3022f191a957e169e9b4ce8913b14859e27e8, 0xb08cfcbe73d381 3648ca7f96e6178d7208a74a2f, 0x55b714f59f71b65cc63201fc9fc8a817adba9d79 and more.

Figure 10: Comparative analysis of asset flows across three exemplar clusters. Victim nodes are in blue, internal laundering nodes in green, and transfers out to TC in brown. 22

tion21 ) from the victim, was successful. The victim mistakenly transferred over 130,000 USDC22 to the phishing address. Subsequently, the address 0x55e623 transferred 0.02 ETH to the phishing address to cover the fees for exchanging USDC for ETH on Uniswap, and for transferring the scam revenue of about 56 ETH to another address.

to the phishing address 0xCFab33 . This phishing address received a funding of 0.5 ETH34 from a laundering funder, which was subsequently used to cover the transaction fee for a swap of USDT into ETH via Metamask Swap. 0xCFab then turned itself into a master (coordinator) by creating an APT contract and coordinated near 800 transactions involving 0USDT APTs. The cost of running such APTs was also covered by 10.33 ETH transferred from 0x04C335 , another successful phishing node. Eventually, 0xCFab transferred 6.1 ETH and 0.083294513 ETH to two aggregator nodes 0x0Eb936 and 0x51fb37 , respectively. 0x0Eb9 deposited 40 ETH into TC, whereas 0x51fb continued to transfer more than 82 ETH to another node, which then deposited 100 ETH into TC.

Example 16 (Successful fake-token APT gaining 2000 ETH). The fake-token APT 0x57d624 , which mimicked the benign transfer 0x69ea25 , led to a sizable victim transfer of 2000 ETH26 (worth 4.4 million then). See also Fig. 10b in Appendix G.3 for the laundering. Example 17. The phishing address 0x06CF27 received the first funding transfer of 0.005 USDC from the master 0xbb94 and then attacked the victim 0x81A8 with 0.005 USDC, mimicking a benign transfer28 . The victim mistakenly transferred 5,000 USDC to the phishing, which took 0.015 USDC out of this transfer to send another APT to the same victim, before transferring the remainder (4,999.985 USDC to another address). The victim fell again for this APT and lost another 5,000 USDC. The phishing repeated the action, and succeeded the third time! It used the victim transfers to fund for three other APTs to 0x81A8 three more times before transferring all the remaining USDC to another address.

Example 20. The successful phishing address 0x04C338 also behaved in the same way as the phishing address 0xCFab mentioned in Example 19. The master that funded this phishing address after it succeeded used mostly 3 Gwei as Max Priority but also 1.5 Gwei in one transaction (why the inconsistency?). Its three contract creation transactions all used 6 Gwei as Max Priority.

H.2

Example 18. The phishing address 0x3bF229 sent nine consecutive coin APTs of 0.000001 ETH, in which the first one mimicking a previous benign transfer30 . These APTs were funded with exact amounts (covering precisely the APT values and the transaction fees) by nine internal transactions. But once received a victim transfer of 19.2754893 ETH, it used this to fund the next APT to the same victim before transferring the remaining amount (including some small APT amounts coming in from other scammers) to another address.

Identifying the APT Distributors and Their Funders

Distributors. We define APT distributor addresses (or distributors for short) as those that funded the APT master addresses. More specifically, funding transfers for a master from its corresponding distributors can be identified by collecting all nonzero-value non-APT non-self-transfer incoming ETH or genuine token transfers before its last APTfunding/coordinating transaction and extracting their EOA callers. We found 500,866 distributor transfers initiated by 420,997 unique distributors to support 7,508 master addresses. Non-service distributor addresses that funded the most number of masters include 0x38401e2af98ee72b c8bffeea2f395fc4d256d235 (funded 65 masters) and 0x0c7c3643de2f39ffd2dcc7d9d88a497f2ce1baa4, which consistently used 1inch to fund 55 masters. We identified 88 public service addresses that funded APT masters, led by FixedFloat (funded 345 masters), ChangeNOW (132), WhiteBIT (39), and Kraken (39). Note that these services implement KYC at various levels: Kraken and WhiteBIT require identity verification, while FixedFloat and ChangeNOW are non-custodial and do not require KYC. The distributor dataset can be used to determine master clusters (see Section 5.4) in which master addresses not only have similar scam signatures, but also fund each other. Such

Example 19. A zero-UDST APT 31 (and perhaps also the ones preceeding it) led to a victim transfer32 of 5,000 USDT 21 tx:0xe1518167d0c6f7e244e94c9d540651a4a0791f47d6a372d749f5d5b71d 98145d 22 tx:0x05e62526912bf4dd6322929f28642f879a9316cc7a724327cc3ec49997 dd4876 23 0x55e6e031c37B270aF3ebb788938bD32F9E6Cc19d 24 tx:0x57df61872793d02a33e27e3bb77ffb7f525a91f681183b5c72b3c15a08 9526c5 25 tx:0x69ea28b1d395bc23e5a59641100c7b88c46a8cf601c132e535830ac342 08c057 26 tx:0xa8d0ac9c1f495af05b748749833e2b94012410132ac40c3aa0aa5200a6 5a6523 27 0x06CFbd19BB436D8d75499d5cbb995C38018c7322 28 tx:0xb442a6c219f4bdb993bdad6b16ff69bb8ba7f74f1ad26731481a8f4fe6 a29363 29 0x3bF2dE59432Ce0C257bfe3ed6A0375e840331737 30 tx:0x7951ffb45feb2420b9c07b3d7544ccb9651f1ebbc20f8c66dfb1b46972 ab6ce1 31 tx:0x6068f5fa7703f1dea289ca82c5f04e44e1e9602738adead78443bbaaf2 f595a2 32 tx:0x3d22e9cb448498a32923f17badd8739146e020255e7f5a8eeda1c355c2 d1ce3a

33 0xCFabEF41fC0076f9736EDe647a39468A426667cA 34 tx:0x39b01f641f6ebc880cc031f6e9d827bbdba5a6cdee2c572cf0443f8e12 cc28fe 35 0x04C37956972727fc0C52aA4CD64aed18b0a62aEC 36 0x0Eb9b84c20538A742022B2cc8C9995D0e9052322 37 0x51fb0E9F117A9be64FD9a3fd0daDf6d1Ae90FFac 38 0x04C37956972727fc0C52aA4CD64aed18b0a62aEC

23

M = {(v1 , 1), (v2 , 1), . . . , (vk , 1)} (each element appears exactly once). Note that the Simpson index and the Shannon capacity measures diversity of values, ignoring the total number of elements. For example, they give the same values for M1 = {(v1 , 2), (v2 , 1)} and M2 = {(v1 , 2000), (v2 , 1000)} as pi ’s are the same for both multisets. Our consistency scores, however, take into account the total number of observations N, and give much higher scores for M2 (CSH (M2 ) = 0.87 > CIS (M1 ) = 0.25), which fits our purpose.

addresses are labelled as both masters and distributors. Overall, there are 4,428 distributors that are also masters that supported at least two APT-funding/coordinating transactions and funded other masters. There are 272,199 distributors that are also phishing addresses, which include a) phishing addresses that transferred the remaining amounts after receiving some funding back to masters, e.g. 0xf0c3ce7e061816d545bffc b809d4a423ef3a92c7, and b) successful phishing addresses that transferred to master addresses for either laundering or initiating new rounds of APTs (see Fig. 1). Distributor Funders. Similarly, we define distributor funders as addresses that transferred ETH to distributors before their last funding transfers to masters. An example of a distributor funder is 0xf4C4263ED3Abb1431c40929B F55321e843B17A65. After receiving 9.95315 ETH from Tornado Cash, it transferred about 5 ETH to the distributor 0xF8Bc7b2C5985b7129125AcD87f78e09349e78206, which subsequently funded dozens of masters via 1inch’s Aggregation Router V5. As mentioned in Section 4.2, distributors and distributor funders are intermediate addresses on the ‘tainted’ ETH-transfer paths that link scam-related TC depositors and withdrawers to APT masters. When creating the tainted paths, we ignore distributors and distributor funders that are public-service addresses or TC relayer addresses to avoid obvious false positives. We captured 656,762 unique distributor funders in our datasets (restricted to the set of 7,508 masters of interest). Among these, 138,009 are also distributors, 4,612 are also masters, 120,814 are also phishing addresses, and 994 are public-service addresses.

I

APT Scam Signatures

I.1

Consistency Scores

I.2 Guilt-by-Association) Graph and Signature Cohesion Score We provide in this appendix the formal definitions of the guilt-by-association graph and the signature cohesion score. Definition 12 (Guilt-by-Association Graph). Given a set M and D of master and non-service distributor addresses, respectively (see Section 4), the guilt-by-association (GBA) graph G(M, D) = (V, E) is a directed graph constructed via the following steps: Step 1) set V = M, Step 2) add the edge e = (m1 , m2 ) to E if two masters m1 ̸= m2 in M support the same phishing address, Step 3) for two masters m1 and m2 in M, if m1 is a distributor of m2 then add e = (m1 , m2 ) to E, Step 4) for each distributor d ∈ D \V , if d fund h ≥ 2 masters m1 , . . . , mh in M, then add d to V and ei = (d, mi ) to E for i = 1, . . . , h. Note that existing work already used a version of Step 2 to group master/phishing addresses when two master addresses coordinate APTs involving the same phishing address [15,23]. However, they missed master-to-master and distributor-tomaster ETH transactions. Steps 3 and 4 are introduced in our work to fill that gap.

Let M = {(vi , fi )}ki=1 denote a multiset of k observed elements, where each distinct element vi appears with frequency fi , N = ∑ki=1 fi is the total number of observations, and pi = fi /N is the relative frequency of the vi . Then the consistency score is defined as C(M) ≜ 1 − log keff / log N if N > 1, and C(M) ≜ 1 if N = 1, where keff is the effective number of elements, defined as follows. Using the Inverse-Simpson index, we have keff = keff (IS) ≜ 1/ ∑ki=1 p2i . If the Shannon k entropy is used, then keff = keff (SH) ≜ e− ∑i=1 pi log pi . For instance, for M = {(1, 99), (2, 1)}, we have keff (IS)(M) = 1.02 and keff (SH)(M) = 1.06, representing the fact that although two values appear, most of the time it is just one. We use CIS (M) and CSH (M) to denote the corresponding consistency scores. Note that C(M) ∈ [0, 1], and the closer it is to one, the more consistent the values of M are, i.e. fewer values with larger frequencies. Clearly, CIS (M) = CSH (M) = 1 if M = {(v1 , f1 )} (only one element appears), and CIS (M) = CSH (M) = 0 if

Definition 13 (Signature-Level Cohesion). Let M and D be sets of master and distributor addresses, respectively, and σ be a scam signature. Let σ(m) denote the corresponding signature value of m ∈ M. Let {σ1 , . . . , σr } be the set of all distinct values of σ(m), m ∈ M, so that each set Mi ≜ {m ∈ M : σ(m) = σi }, i = 1, . . . , r, has at least two elements. Let i {Ci, j }kj=1 be the weakly connected components (WCC) of the scam-operation graph G(Mi , D) (see Definition 12). We define the cohesion score of the address group Mi as ki

    |Ci, j | |Mi | cohM,D (Mi ) ≜ ∑ / ∈ [0, 1]. 2 2 j=1 The cohesion score of the signature σ is defined as r

ki

  r   |Ci, j | |Mi | cohM,D (σ) ≜ ∑ ∑ /∑ ∈ [0, 1]. 2 2 i=1 j=1 i=1 24

I.3 Explaining the Copying Bot Case from [23]

positor, we make use of the laundering transfers between the victim addresses and the TC addresses captured in the output set L of the DLF algorithm (see Section 6.1 and Appendix F). Using the laundering transfers from L, we construct a shortest laundering path from each victim transfer to each reachable depositor (there are 85 such addresses). For each depositor address, using the master dataset (see Section 4.2), we find all the master addresses that coordinated or funded APTs targeting the victim before the victim transfer and involved the corresponding phishing and victim address. A tainted path for each depositor and each related APT consists of a) the transaction initiated by the master to coordinate the APT, b) the APT-carrying transaction, c) the victim transfer, and d) the laundering path (represented by a sequence of transaction hashes) from the phishing address to TC pools (including the depositor). Tainted Paths for Withdrawers. Next, we collected 16,376 unique withdrawer addresses from 35,076 TC withdrawal records (see Table 3), and find the associated master addresses for each withdrawer as follows. We consider four types of tainted withdrawers depending on the role they play regarding APTs: Type-1 - masters (coordinate/fund APTs), Type-2 - distributors (fund masters), Type-3 - distributor funders (fund distributors), and Type-4 - laundering funders (fund successful phishing addresses after they receive the first victim transfer and before the last laundering transfer). For the withdrawers that are masters themselves, each is its own associated master. For the withdrawers that are distributors but not masters, we find their associated masters by using the distributor dataset discussed in Section H.2. We also identified withdrawers that are funders of some distributors. For such addresses, the associated masters can be found via the distributor and distributor funder datasets (see Section 4.2 and Appendix H.2).Finally, we include withdrawers (mostly of pools 0.1 ETH) that are laundering funders (e.g. 0x388A798cA776E7781FEb7Cf9B03739703a05bd88). Their associated masters are those that coordinated/funded the APTs leading to the laundered victim transfers. The tainted path for a Type-1 withdrawer (a master) contains only the transaction hash of the corresponding TC withdrawal transaction. A tainted path for a Type-2 withdrawer (a distributor) consists of the transaction hashes of the corresponding TC withdrawal transaction and the ETH transfer from the withdrawer to a master funded by the depositor. A tainted path for a Type-3 withdrawer (a distributor funder) consists of the transaction hashes of the corresponding TC withdrawal transaction, of an ETH transfer from the withdrawer to a distributor, and of an ETH transfer from the distributor to a master. Note that there can be multiple tainted paths for withdrawers of Type-2 and Type-3, whereas Type-1 withdrawers only have one tainted path. Note that the TC withdrawal transaction must happen before the withdrawer’s transfer and the transfer from distributor to master must happen after the transfer from the distributor funder to the distributor. The

The presumed copying bot 0x7D5739 called two contracts to perform APTs using two type-0 transactions with gasLimit 165,807 and 53,082, respectively. On the other hand, the first contract was created by the master 0x937640 , who repeatedly called it 314 times using type-2 transactions with gasLimit 18500000, maxFeePerGas 200 Gwei, and maxPriorityFeePerGas 3 Gwei. It turns out that this address belongs to Group CG1 of 1,699 master addresses (see Section 5.4), which all generated contracts with identical bytecodes and had consistent gas signatures. The second contract was created by another master 0x7DC441 , which belongs to Group CG3 of 254 master addresses (see Section 5.4), which generated contracts with two distinct bytecodes and almost always used type-2 transactions and maxPriorityFeePerGas 1.5 Gwei. Thus, the copying bot, Group CG1, and Group CG3 have completely different contract and gas signatures, substantiating the observation in [23].

J

Grouping User Addresses on Tornado Cash via Scam Signatures

In this appendix, we explore an approach that could suggest pairs of matching TC deposit and withdrawal. More specifically, we first identify tainted TC depositors and withdrawers, which are associated with APT masters via tainted paths. Scam signatures from those masters are then collected and aggregated for such tainted TC user addresses. Finally, deposits and withdrawals that are closest in time and initiated by tainted depositors and withdrawers with similar scam signatures are suggested as potential candidate matches.

Figure 11: TC depositors and withdrawers are assigned scam signatures from their associated masters via ‘tainted’ paths. Tainted Paths for Depositors. To identify the tainted depositors and the master addresses associated with each de39 0x7D575a7C732D1c502c07f18BB822D29CF7DBf9E8 40 0x9376C9c73D8C7AC9b6ae159ADaA06b42dbBef1B4 41 0x7DC44D10499EE4c3F4bbbfCD6Ed428dDC7b99451

25

Figure 12: A potential deposit-withdrawal match for TC depositor (0x03CEc7583846EEEe04cDd0752A0B35bC8F793bff) and withdrawer (0x306608bf57e58a1263c491ad81b1a5fa2b420cfd) with similar FR, VP, MPFPG signatures.

Figure 13: A pair of TC depositor (0x2be8E539B43b09Ef7d066C8580E12F6f1f26bEf9) and withdrawer (0x140FCB5DD975 078B1E394446d3F2958B7880Fd39) that potentially belong to the same scammer/group due to similar CG, CC, and MPFPG signatures. Note that 0xc527. . . and 0x5f31. . . are modified addresses of the APT contract and the fake-token contracts. gregated signature if its frequency exceeds a threshold θ = 0.8 of the sum of all frequencies. If such a high-frequency signature doesn’t exist among the masters, then assign ‘OTHER’ as the (useless) signature for the depositor/withdrawer. For signatures other than VP, which are represented by sets (after flattening - see Section 5), we use two thresholds for aggregation. The first threshold γ = 5 and the second threshold θ = 0.8. THe first threshold is applied as follows: if a master’s signature (as a set) has more than γ values, then it will be excluded from aggregation. The intuition is that if the master uses many value for its signature, than their behaviour is not consistent enough to be counted. The second threshold θ is used as usual: after applying the first threshold, we calculate the frequencies of the remaining sets (signatures), and pick the sets with largest frequencies that sum up to at least θ fraction of the sum of all frequencies. We then assign the set union of such sets as the aggregated signature of the corresponding depositor/withdrawer. Otherwise, assign 0/ as the (useless) aggregated signature. Deposit/Withdrawal Matching Methodology. Scam signatures are first assigned to tainted depositors and withdrawers as before. Then, given a deposit (withdrawal), the predicted counterpart is the nearest in time withdrawal (deposit) con-

tainted path for a Type-4 withdrawer (a laundering funder) consists of the transaction hash of master’s transaction that funded or coordinated the APT leading to the victim transfer that requires fund laundering, the transaction hash of the transaction that carries the APT itself, the transaction hash of the victim transfer from the victim to the phishing address, the transaction hash of the TC withdrawal, and the transaction hash of the laundering funding transfer to the phishing address. Note that the laundering funding transfer must happen after both the TC withdrawal and the victim transfer. Signature Aggregation. We consider two types of masters: coordinators and coin funders (see Section 4.1). We retrieve the CG and the three gas signatures for coordinator masters and the FR and VP signatures for coin-funder masters (see Section 5). For each tainted depositor and withdrawer, we assign to them the aggregated signatures from the set of the associated masters identified via the tainted paths described above. Note that during signature aggregation, we ignore useless signature values such as ‘OTHER’ for VP signature and 21,000 for GL signature. For VP signature, which is represented by a string, we calculate the frequencies of all string-signatures from all associated master, and assign the highest-frequency signature as the ag26

ducted by a tainted TC user with similar scam signatures. We discuss two examples to demonstrate the proposed methodologies. Example 21. The TC depositor 0x03CEc (see Fig. 12) received 10.05 ETH from a successful phishing 0x4f512, who got 50 ETH from a victim thanks to a previous coin APT. This coin APT was funded by the master 0x7bc59. Thus, the FR, VP, and MPFPG signatures of this master are assigned to the depositor. The withdrawer 0x30660, on the other hand, after received 9.95 ETH from TC (about 6 hours after the deposit by 0x03CEc), funded 30 APT masters that all have identical FR, VP, and MPFPG signatures, which are then aggregated and assigned to the withdrawer. The depositor and withdrawer have identical FR and VP signatures, and also similar MPFPG signatures. Given the timing and the three highly similar signatures, the deposit and the withdrawal are potentially a match and the two addresses may be from the same scammer orgnisation. Example 22. Another example similar to Example 21 is illustrated in Fig. 13.

27