Blockchain Transaction Simulation Phishing Xiaocan Wang
Shixuan Guan
Tong Yang
Stevens Institute of Technology [email protected]
Stevens Institute of Technology [email protected]
Rutgers University [email protected]
Xiapu Luo
Yue Duan
Kai Li
The Hong Kong Polytechnic University [email protected]
Singapore Management University [email protected]
Stevens Institute of Technology [email protected]
arXiv:2607.28747v1 [cs.CR] 30 Jul 2026
ABSTRACT Cryptocurrency users have increasingly become targets of phishing and scam attacks. To mitigate these threats, leading crypto wallets (e.g., MetaMask) have introduced transaction simulation, which previews a transaction’s balance changes before on-chain execution. While effective against traditional fund-draining attacks, we show that this defense can itself be exploited by a new phishing technique, which we term transaction simulation phishing. This attack uses carefully-crafted smart contracts whose execution depends on dynamic blockchain state, causing simulations to display benign or profitable outcomes while the actual on-chain execution redirects users’ funds to attacker-controlled addresses. We present the first comprehensive study of transaction simulation phishing. We first develop a taxonomy of phishing contracts that can be utilized to facilitate this attack. Then, we propose SimGuard, a bytecode-level detection system that combines static and dynamic program analysis to identify phishing contracts. Applying SimGuard to Ethereum, Binance Smart Chain, Avalanche, and Polygon, we detect over 4,000 phishing contracts deployed between August 2024 and June 2025. Our analysis identifies more than 5,700 victims and approximately $3.48 million USD in losses, 91.5% of which occurred on Ethereum. Moreover, our clustering result reveals that the largest phishing contract cluster alone accounts for about 83% of the total losses. These results expose a critical weakness in current wallet defenses and highlight the urgent need for more robust transaction simulation mechanisms.
CCS CONCEPTS • Security and privacy → Distributed systems security;
KEYWORDS Blockchain Phishing, Transaction Simulation ACM Reference Format: Xiaocan Wang, Shixuan Guan, Tong Yang, Xiapu Luo, Yue Duan, and Kai Li. 2018. Blockchain Transaction Simulation Phishing. In Proceedings of Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. Conference acronym ’XX, June 03–05, 2018, Woodstock, NY © 2018 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-XXXX-X/2018/06. . . $15.00 https://doi.org/XXXXXXX.XXXXXXX
Make sure to enter the correct conference title from your rights confirmation email (Conference acronym ’XX). ACM, New York, NY, USA, 15 pages. https: //doi.org/XXXXXXX.XXXXXXX
1
INTRODUCTION
The rapid advancement of blockchain technology has stimulated substantial growth in the global cryptocurrency market. Unfortunately, this growth has been accompanied by a surge in cybercrime, including phishing and scam attacks that exploit multiple layers of the blockchain ecosystem. Prior studies have shown that attackers abuse smart contracts [18, 39, 44, 50, 56], crypto wallets [36, 37, 41– 43, 49, 54, 59], and social media platforms [45–47, 55, 57] to deceive victims and steal cryptocurrency assets. The financial impact is severe, with losses in the first half of 2025 alone exceeding $2.17 billion USD [1]. These trends underscore the urgent need for effective countermeasures to protect cryptocurrency users. Crypto wallets serve as the primary interface through which users manage and transfer digital assets and therefore play a critical role in safeguarding user funds. To mitigate phishing attacks, wallet developers have widely adopted transaction simulation, a feature that has grown in popularity in recent years. Leading wallets such as MetaMask [19], Coinbase [8], and Trust Wallet [27] now integrate transaction simulation modules that speculatively execute a transaction before it is submitted on-chain. By previewing the expected balance changes, transaction simulation enables users to assess whether a transaction’s outcome aligns with their expectations, thereby improving transparency and security. Consequently, many existing phishing attacks [36, 42, 45, 49, 59] that directly drain users’ funds can be effectively exposed during simulation, significantly reducing their success rates. New phishing threat: Despite its defensive intent, transaction simulation has inadvertently introduced a new attack surface. In this paper, we demonstrate that attackers have exploited transaction simulation itself to deceive wallet users, a novel phishing tactic that we term transaction simulation phishing. This attack leverages carefully-crafted phishing contracts whose execution semantics depend on dynamic properties of the blockchain environment. During simulation, such contracts can exhibit benign and profitable outcomes, inducing users to approve the transaction. However, after submission, changes in blockchain state or transaction context cause the on-chain execution path to diverge from the simulated one, which redirects the user’s funds to attacker-controlled addresses and results in financial losses to them. Taxonomy and detection system: Motivated by this emerging phishing threat, we conduct a comprehensive study of transaction
• Taxonomy of phishing contracts: We systematically analyze dynamic blockchain properties and construct a taxonomy of six classes of phishing contracts exploiting transaction simulation. • A new detection system: We design and implement SimGuard, a bytecode-level detection system that integrates symbolic execution, phishing-specific transfer recognition, and runtime verification, achieving zero false positives in the evaluation results on a ground-truth dataset. • Large-scale measurement: Applying SimGuard to four major blockchains, we identify over 4,000 phishing contracts, more than 5,700 victims, and approximately $3.48 million USD in losses. We further reveal temporal trends and coordinated attacker clusters. We have open-sourced SimGuard and released the collected dataset to support future research1 .
simulation phishing and develop techniques to detect phishing contracts at scale. Based on the insight that any dynamic element of the blockchain execution environment may be exploited to manipulate a contract’s execution flow, we systematically analyze blockchain variables that influence transaction semantics and construct a taxonomy of six classes of transaction simulation phishing contracts: storage-control, external-control, Gas-control, Gaspricecontrol, blocknumber-control, and timestamp-control. Building on this taxonomy, we design SimGuard, a bytecode-level detection system capable of detecting these phishing contracts at large-scale across EVM-compatible blockchains. At a high level, SimGuard first symbolically executes contract bytecode to enumerate all possible execution traces and then identifies suspicious fund transfer behaviors based on the characteristic of transaction simulation phishing, where one branch returns funds and apparent profits to the caller while another redirects funds to external addresses under the attacker’s control. To minimize false positives, SimGuard further validates suspicious contracts via runtime testing in a controlled execution environment. Detection results and research findings: We apply SimGuard to four major EVM-compatible blockchains, including Ethereum mainnet, Binance Smart Chain (BSC), Avalanche (Avax), and Polygon, and identify a total of 4,224 phishing contracts, including 480 on Ethereum, 293 on BSC, 3,316 on Avax, and 315 on Polygon. Our analysis shows that Gas-control contracts dominate in prevalence, while Avax hosts the largest number of deployed phishing contracts. The timeline analysis reveals that transaction simulation phishing first emerged in August 2024 and intensified between March and May 2025, with over 100 contracts deployed in a single day across the four blockchains. By tracing the on-chain transaction histories of each detected phishing contract, we identify more than 5,700 victim addresses suffering losses exceeding $3.48 million USD, with 91.5% occurring on Ethereum. Among all phishing types, our analysis indicates that storage-control contracts are the most profitable, accounting for over $2.97 million USD (85.34%) of total losses, which is primarily due to their characteristics in offering a deterministic control over the execution outcome. Our further analysis reveals that although the number of daily victims remained high between March and May 2025, the most severe losses were concentrated in the early stages of the campaign, including a single day in January 2025 with losses exceeding $1 million USD. Moreover, our investigation shows that attackers also achieve extraordinarily high returns, with return-on-investment (ROI) ranging from 4,463% to 83,495% across four blockchains. Finally, our clustering result shows that a small number of coordinated attacker groups dominate the phishing campaign, with the largest cluster on Ethereum alone accounting for approximately $2.88 million USD (83% of total profits). Collectively, these findings demonstrate the severity, scalability, and economic incentives of transaction simulation phishing and highlight the urgent need for more robust wallet defenses. Overall, our work makes the following contributions:
2 BACKGROUND 2.1 Ethereum and Smart Contract Ethereum is one of the most widely adopted Proof-of-Stake (PoS) blockchain platforms and a pioneer in supporting general-purpose smart contracts. The smart contract feature has enabled a wide range of applications, including Decentralized Finance (DeFi), NFTs, gaming, and supply chain management. On Ethereum, users deploy and execute smart contracts via transactions, which update the contract’s state on the blockchain. Contract execution is handled by the Ethereum Virtual Machine (EVM), which runs on every node in the peer-to-peer network to replicate execution and confirm results. The EVM is a stack-based virtual machine with a standardized set of opcodes [12], including arithmetic, storage, and control flow instructions that operate on a last-in, first-out (LIFO) stack. Each opcode manipulates stack values, and complex contract logic emerges from these sequential operations. While contracts execute as EVM bytecode, developers typically write them in higher-level languages such as Solidity [24], which are then compiled into bytecode for deployment.
2.2
EVM-compatible Blockchains
Inspired by the success of Ethereum, people have also adopted the EVM standard in other blockchains, including Binance Smart Chain (BSC), Avalanche (Avax), and Polygon. Unlike Ethereum, BSC [5] offers faster block intervals and reduced transaction costs through its Proof-of-Staked Authority (PoSA) mechanism. Avax [3] adopts a multi-chain architecture and a custom consensus protocol designed for low latency and high throughput. Polygon [20] provides a scaling framework that offers high-speed and cost-efficient transactions. Despite the differences in the consensus protocols and transaction fee mechanisms, all of them are EVM-equivalent and retain full compatibility with the smart contract programming language, Solidity. In other words, the same smart contract can be seamlessly deployed on all these EVM-compatible blockchains to produce equivalent execution results.
2.3
• Comprehensive analysis: We present the first comprehensive study of transaction simulation phishing, an emerging threat that specifically exploits transaction simulation mechanisms in modern crypto wallets.
Crypto Wallet and Transaction Simulation
On blockchains, the user’s cryptocurrency account is also referred to as external owned address (EOA), which is used to hold and 1 https://anonymous.4open.science/r/Blockchain-Transaction-Simulation-Phishing-BE81
2
connection, the website initiates a transaction to transfer the user’s funds (e.g., ETH) to a phishing smart contract (step 2 ). Before signing, the wallet forwards the transaction to its integrated transaction simulator (step 3 ), which executes it against the current blockchain state and generates a simulated execution result (step 4 ). The wallet then displays a preview showing the expected post-transaction balance change (step 5 ). To deceive the user, the phishing contract is crafted to return the deposited funds plus a tiny profit during simulation, making the balance appear increased. Meanwhile, the attackers submit a separate transaction (step 6 ) that manipulates the phishing contract’s state, such as blacklisting the user’s address. This alters the transaction’s actual execution path, redirecting the users’ deposits to an attacker-controlled address. The wallet fails to detect this concurrent state change and does not update the simulation. Consequently, when the user approves and submits the transaction on-chain (step 7 ), the deposited funds are immediately transferred to the attacker (step 8 ), causing financial loss. To better illustrate the attack, we show a representative phishing contract in Listing 1. The contract has a claim() function that will be invoked by the victim user’s transaction. This function contains an if–else branch whose execution depends on whether the caller’s address appears in a blacklist. If the caller is not blacklisted, the branch at line 6 is executed, which returns the transferred funds along with a small additional reward intended to entice the victim. When the crypto wallet simulates the victim’s transaction, the simulation result would indicate an apparent profitable outcome as the caller’s address is not yet blacklisted. However, because the phishing website has already connected to the victim’s wallet and obtained its address, the attacker can immediately submit a separate transaction to invoke add(victim) and add the victim’s address to the blacklist. When the victim subsequently submits the original transaction to execute the claim() function on-chain, the contract’s state has changed. As a result, the execution enters the alternative branch at line 8, which redirects the transferred funds to an attacker-controlled address. It can be seen that this attack exploits the classic time-of-check-to-time-of-use (TOCTOU) race condition between transaction simulation and on-chain execution. The time window between simulation and execution allows the attacker to stealthily manipulate the contract state, causing the actual execution semantics to diverge from the simulated result. Consequently, users who trust the wallet’s simulation results are deceived into approving transactions that ultimately result in financial loss rather than the anticipated profit.
Figure 1: The transaction simulation feature on MetaMask.
manage cryptocurrency assets. To help users manage the cryptocurrency accounts, various crypto wallets are available in the App market. Due to the blockchain’s anonymity and irreversibility natures, crypto wallet users are increasingly targeted by various attacks [37, 49, 59] and phishing scams [36, 41, 42, 45, 54, 59], leading to significant financial losses. To protect users against the threat, leading crypto wallets such as MetaMask, Coinbase, and Trust have integrated a transaction simulation module, which would executes the users’ transaction based on the current blockchain state before they sign and submit it to the blockchain. As shown in Fig. 6, when a transaction request is initiated on the MetaMask wallet, a preview of the transaction’s simulation outcome is presented to users, which shows the balance change to its account. The goal of transaction simulation is to enhance the transaction’s security and transparency so that users can verify whether the transaction execution result aligns with their expectations.
3
TRANSACTION SIMULATION PHISHING
A key motivation for integrating transaction simulation is to reduce wallet users’ exposure to phishing and scam attacks. By previewing a transaction’s execution outcome, wallets can reveal unexpected balance reductions or unknown transfer destinations, prompting users to scrutinize and potentially reject suspicious transaction requests. While this mechanism is effective against traditional phishing attacks that directly drain users’ funds, we find that the ongoing arms race between attackers and defenders has led to a new attack vector. Specifically, transaction simulation itself introduces a new attack surface that can be abused by carefully-crafted phishing contracts to produce plausible profitable outcomes during simulation, thereby disguising malicious transactions as benign. We refer to this emerging attack vector as transaction simulation phishing. In the following, we first present a concrete example demonstrating how this attack exploits transaction simulation, and then introduce a taxonomy of phishing contracts that enable such behavior.
3.1
1 2 3 4 5
A Motivating Example: Storage-control Phishing Contract
6 7
Fig. 2 illustrates the workflow of a transaction simulation phishing attack. As reported [26], the attack begins with a phishing website promoting a fraudulent "free cryptocurrency" campaign. The attackers lure users to visit the website via social media (e.g., X.com) (step 1 ). The website presents a "claim" button that, when clicked, triggers a wallet connection request. Once the user approves the
8 9
contract phishing { function add ( addr ) public { blackList . push ( addr ) ;} function claim () public { if ( msg . sender not in blackList ) { msg . sender . transfer ( msg . value +0.0001 ether ) ;} else { attacker . transfer ( msg . value ) ;}} }
Listing 1: A sample storage-control phishing contract.
3
Figure 2: The workflow of the transaction simulation phishing: The victim first visits a cryptocurrency airdrop website that will connect to the victim’s crypto wallet and initiate a transaction to deposit funds to a phishing contract. The wallet then forwards the transaction to the integrated transaction simulator for simulation. The simulation result will show that the victim’s balance will be increased. The victim then signs and submits the transaction to the blockchain. Meanwhile, the attacker sends another transaction to frontrun the victim’s transaction to manipulate the phishing contract’s state, which alters the victim transaction’s execution and redirects the victim’s deposits to the attacker.
The phishing contract described above uses contract storage as the control variable to determine the transfer destination. By exploiting the dynamic and mutable nature of smart contract storage state, the attacker manipulates the contract’s execution flow to deceive crypto wallet users. We therefore denote the contract as a storage-control phishing contract.
3.2
them less suitable for this phishing purpose. A detailed justification for each variable is provided in Appendix D. Based on this analysis, in addition to storage-control phishing contracts, we identify five additional variants of phishing contracts, as illustrated below. External-control: This contract is similar to stotage-control, except that the blacklist is maintained in an external contract. This contract references the external contract to determine whether the caller exists in the blacklist. If not, the contract returns the caller’s deposits along with a tiny amount of profit. Otherwise, the contract redirects the deposits to the attacker. Gas-control: This contract uses the transaction’s Gas limit (e.g., tx.gas) as the control variable. If below a predefined threshold (e.g., 5 million), the contract rewards the caller with a tiny amount of profit. Otherwise, the caller’s deposits are moved to the attacker. The phishing website sets a large Gas limit (e.g., 6 million) in the initiated transaction. However, the transaction simulator may use a smaller default Gas limit to simulate the transaction, producing a profitable outcome. If the user approves the original transaction with the large Gas limit, its deposits are sent to the attacker. Gasprice-control: This contract is similar to Gas-control, except that the Gas price (e.g., tx.gasprice) is used as the control variable. If it is below a threshold (e.g., 1000 Gwei), the contract transfers funds back to the caller. The phishing website sets a large Gas price (e.g., 1100 Gwei) in the transaction, while the transaction simulator may use a smaller default Gas price to simulate the transaction, producing a profitable outcome. Similarly, if the user approves the original transaction, the funds are sent to the attacker. Blocknumber-control: This contract implements a malicious claim(uint256 number) using block.number as the control variable. The contract compares block.number with the supplied number
Taxonomy of Phishing Contracts
In principle, any dynamic property of the blockchain execution environment can be abused as a control variable in the phishing contracts. To ensure comprehensive coverage, we systematically analyze all blockchain property variables to identify those that can feasibly be exploited to control a contract’s execution path. The property variables in blockchain fall into two broad categories [4]: transaction variables and block variables. For transaction variables, the phishing website would typically set from, to, and value, Gas, Gasprice, and data fields when constructing the transaction. However, the transaction simulator (or user) could adjust the Gas and Gasprice fields [14]. Such flexibility thus makes them possible control variables in the phishing contracts. While the value field could also be adjusted by users, since phishing attackers tend to drain the victim’s entire balance, which varies across victims. Hence, it is unlikely to be selected as the control variable, as setting an appropriate threshold to value would be challenging. For block variables, we identify block.number and block.timestamp as practical control variables, as they are increased monotonically and therefore provide attackers with deterministic control over the execution path. In contrast, other block variables, such as block.basefee and block.coinbase, do not exhibit predictable behavior, making 4
0x6060... bytecode
Filtering
bytecode
Deduplication
Blockchains
Preprocessing
TAC
suspicious contract
0xc: JUMPI v9(0x2c), v8 ... Symbolic Execution
testcase: TX1
testcase: TX0 Suspicious Contract Recognition
0x6060...
TX1
Runtime Verification
phishing contracts
Figure 3: The phishing contract detection pipeline of SimGuard.
supplied in the transaction. If block.number is smaller, the contract transfers funds back to the caller. Otherwise, the funds are moved to the attacker. The phishing website sets number to the next block height (i.e., block.number + 1) to invoke claim() in the transaction. During simulation, the condition holds and the simulator produces a profitable outcome. However, when the transaction is executed on-chain, multiple blocks could have been produced, causing block.number to exceed number. As a result, the victim’s deposits are sent to the attacker. Timestamp-control: This contract works similarly to the above except that it uses block.timestamp as the control variable. If block.timestamp is smaller than the supplied timestamp in the transaction, the contract transfers funds back to the caller. Otherwise, the deposits are sent to the attacker. The phishing website sets timestamp slightly ahead of the victim’s local time (e.g., by adding a few seconds) to invoke claim(). During simulation, the condition evaluates to true. However, when the transaction is executed on-chain, multiple blocks could have been produced and block.timestamp exceeds the supplied timestamp, causing an altered execution flow that sends the victim’s deposits to the attacker.
4
transactions on the EVM-compatible blockchains. We leverage the Ethereum-ETL [11] tool to retrieve the detailed transactions and the associated receipts, which are further parsed to extract the bytecode of deployed contracts and the deployed addresses. After collecting the deployed contracts and the bytecode, we then preprocess the collected dataset by filtering out benign contracts (e.g., popular ERC-20 tokens, DEXs) that are well-known. Since the blockchain may have duplicate contract code deployed, we further deduplicate the collected bytecode to reduce our analysis overhead. Symbolic execution and suspicious contract recognition: After preprocessing, SimGuard leverages the existing tool, greed [40, 52], to symbolically execute each remaining bytecode, producing a three-address-code (TAC) Intermediate Representation (IR). The symbolic execution tool takes the contract’s bytecode as input and traverses all possible branches to generate various execution traces, which are saved into the TAC form consisting of simple instructions, each with at most three operands. After obtaining the TAC, SimGuard then detect suspicious transfer patterns based on the characteristics of each phishing contract variant. First of all, a common behavior of all phishing contracts is that they include multiple branches to execute the transfer operation. In one branch, funds (caller’s deposits + additional amount) are returned to the caller. In other branches, the caller’s deposits are sent to another address. Based on such a characteristic, we detect suspicious transfer patterns from the TAC using the following criteria:
DETECTION SYSTEM: SIMGUARD
With the above taxonomy of phishing contracts, our work aims to detect them in real-world blockchains at a large scale. However, this is a challenging task, as most smart contracts do not provide source code, especially those containing malicious intent [28]. In this work, we propose SimGuard to detect phishing contracts directly from the bytecode.
4.1
• In one basic code block, there is a JUMPI instruction connecting two successor basic blocks that both contain a CALL operation. • In one successor basic block, the CALL sends funds to CALLER, with the transferred amount greater than the caller’s deposit (CALLVALUE). • In the other successor basic block, the CALL sends the caller’s deposit (CALLVALUE) to an external address, which is loaded from the contract’s storage via SLOAD or returned by another CALL.
Technical Design and Implementation
The detection pipeline of SimGuard is presented in Fig. 3. At a high level, for smart contracts deployed on the EVM-compatible blockchains, SimGuard first leverages symbolic execution to convert the bytecode into the three-address-code (TAC) representation [25]. Then, SimGuard parses the contract’s TAC to detect suspicious transfer operations based on the characteristics of each phishing contract variant. Finally, contracts with suspicious transfer patterns will be further validated through dynamic analysis, which involves sending testing transactions to confirm whether their runtime behaviors align with the phishing activity. Overall, SimGuard is fully automated and can be applied to detect phishing contracts in EVM-compatible blockchains. Data collection and preprocessing: Our detection pipeline begins with collecting smart contract bytecode from the historical
With the above criteria, SimGuard will identify contracts with suspicious transfer patterns, with one returning the deposit as well as additional amounts to the caller, and the other moving the caller’s deposit to another address. After identifying such suspicious contracts, SimGuard further analyzes them by tracing the data flow of the control variable referenced in the JUMPI instruction. If one of the below conditions meets, the suspicious contract is classified as the associated phishing contract variant. • Storage-control: data flow dependent on both SLOAD and CALLER. 5
• External-control: data flow dependent on both CALLDATA and CALLER. • Gas-control: data flow dependent on tx.gas. • Gasprice-control: data flow dependent on tx.gasprice. • Blocknumber-control: data flow dependent on block.number. • Timestamp-control: data flow dependent on block.timestamp.
identified contract, we search its label on Etherscan and include only those explicitly labeled as "phishing" in the dataset. Using this snowball-sampling approach, we found 14 storage-control phishing contracts. Because no labeled contracts were found for the remaining four phishing types, we synthesized additional phishing contracts to ensure coverage. Specifically, we instruct Gemini [16] to implement phishing contracts following the specifications described in Sec. 3.2. In addition to straightforward implementations (e.g., a single if-else branch), we also ask Gemini to incorporate various obfuscation techniques, including multiple branches, loops, dummy functions, and complex arithmetic expressions, to obscure the transfer logic. We thereby obtain five contracts for each phishing contract variant. In total, our phishing dataset consists of 44 contracts, spanning all six categories in our taxonomy. Benign contracts: There is a public benign contract dataset released by Forta [10], which comprises 139,451 contracts that were obtained with a machine learning predictive model from the Ethereum mainet [17]. Since the dataset was published three years ago and may not represent the current state, we expanded this dataset by looking into contracts deployed from Jan. 2024 to Aug. 2025 that have the source code published on Etherscan without a "phishing" label. In addition, we only consider contracts that have at least 100 transaction interactions. We then parse each contract’s source code and classify them into the following three categories: (1) have no "transfer" operations; (2) have "transfer" operations but none of them are conditional; (3) have at least one conditional "transfer" operation. Through this process, we respectively expanded 8,145, 14,350, and 1,029 benign contracts in each category. In total, our benign dataset includes 139,451 + 23,524 = 162,975 contracts. Evaluation results: Table 1 summarizes the evaluation results of SimGuard. Among the 44 phishing contracts in our dataset, SimGuard successfully detects 43 of them. The only false negative is a synthesized Gasprice-control phishing contract employing multiple obfuscation techniques, including opaque predicates, redundant loops, and indirect branch routing. These obfuscations prevent SimGuard from correctly tracing the data dependency between the JUMPI instruction and the Gasprice variable, leading to a missed detection. Nevertheless, SimGuard still shows the ability to detect the vast majority of phishing contracts (including all 14 real-world contracts labeled on Etherscan), achieving a recall of over 97%. On the two benign contract datasets, SimGuard produces no false positives, resulting in 100% precision. In addition, the evaluation result also suggests that SimGuard incurs a small execution overhead, with an average analysis time of 4.3 seconds on each phishing contract and 6.5 seconds on each benign contract.
Using the above detection criteria, SimGuard can identify highly suspicious contracts. SimGuard implements the detection criteria as an algorithm with the pseudo code provided in Appendix B. Runtime verification: For each highly suspicious contract, SimGuard confirms whether its runtime execution aligns with the expected phishing behavior by sending transactions to execute it in a local environment using Foundry [15]. We send two groups of transactions, where the first group simulates the profit scenario and the second group simulates the financial loss scenario. For example, to test "storage-control" contracts, the first group only includes one transaction depositing funds to the contract. The expected behavior is that the contract will return the deposit as well as additional amounts, representing the profit scenario. The second group sends two transactions, with the first manipulating the storage state of the contract (e.g., invoking the add() function to blacklist the caller) and the second depositing funds to the contract. The expected behavior is that the contract will redirect the funds to another address, representing the financial loss scenario. Similarly, to test other phishing contract variants, we respectively test the profiting and financial loss scenarios by manipulating the storage state of the external contract or changing "tx.gas", "tx.gasprice", "number", and "timestamp" accordingly. To accurately trigger the profit and financial loss scenarios, we utilize the constraint solver [22] to construct the correct parameters in the testing transactions. For instance, to test "storage-control" phishing contracts, we locate CALL instructions that return funds to the caller (the profit scenario) and set that location as the target. Then, the constraint solver would resolve the required parameters for the transaction’s execution to reach that location. To test the financial loss case, we then set the target location to statements manipulating the contract storage (e.g., SSTORE). For multiple solutions found, we will exhaust all of them in the testing transactions to ensure no phishing contracts will be missed. Finally, if both profiting and financial loss behaviors are observed, we confirm that the tested contract belongs to a phishing attacker.
4.2
Evaluation of SimGuard
This section evaluates SimGuard with a ground-truth dataset. Phishing contracts: Transaction simulation phishing is a newly emerging threat, so currently, no public ground-truth datasets exist. We construct our own dataset from a publicly reported phishing contract [26] and use it as a seed contract to expand the dataset with a snowball-sampling approach. Specifically, we identify phishing contracts through three complementary strategies: (1) tracing contracts deployed by the same address and collecting those with similar bytecode; (2) querying Etherscan’s Similar Contract API [23] to retrieve contracts similar to the reported one; and (3) identifying contracts that internally transfers to the same address and retaining those with similar bytecode. The bytecode similarity is measured by the existing method [7] with a similarity threshold of 90%. For each
5
PHISHING CONTRACTS IN THE WILD
This section presents the detection results and an in-depth analysis of phishing contracts in real-world blockchains.
5.1
Overview of Detected Phishing Contracts
We apply SimGuard to analyze smart contracts deployed up to August 2025 across four EVM-compatible blockchains: Ethereum mainnet, Binance Smart Chain (BSC), Avalanche (Avax), and Polygon. In total, we detected 4,224 phishing contracts, as summarized in Table 2. Specifically, 480 phishing contracts were identified on 6
Table 1: Evaluation result of SimGuard on the ground-truth datasets. Ground-truth Phishing Contracts (P) Benign Contracts (N) Snowball-sampling Gemini Synthesis Forta Source-code Expansion 14 30 139,451 23,524
Table 2: Overview of detected phishing contracts.
Blockchain Ethereum BSC Avax Polygon Total
Phishing Contract Storage GasTimestamp -control control -control 18 453 9 2 290 1 2 3,134 0 0 315 0 22 4,192 10
Total No
416 257 12 214 899
64 36 3,124 101 3,325
FP 0
Recall 97.72%
Avg. Time (s) Phishing Benign 4.38 6.50
Labeling status: All four blockchain explorers actively label addresses and contracts involved in phishing scams and other malicious activities based on off-chain intelligence and community or human reports, including Etherscan [13] (Ethereum), BscScan [6] (BSC), SnowScan [2] (Avax), and PolygonScan [21] (Polygon). We query the labeling status of each detected phishing contract from the corresponding blockchain explorer to determine whether it has been assigned a “phishing” label. The results are summarized in Table 2. Among the 480 phishing contracts detected on the Ethereum mainnet, 416 have been flagged as phishing by Etherscan, while the remaining 64 have not yet been labeled. On BSC, 257 contracts have been flagged, and 36 remain unlabeled. On Avax, only 12 phishing contracts have been flagged, whereas the other 3,124 contracts have not yet been labeled. On Polygon, 214 contracts have been flagged, while 101 remain unlabeled. Overall, these results suggest that although off-chain intelligence and human reports provide a useful mechanism for identifying phishing contracts, additional efforts are needed across all four blockchain explorers to comprehensively detect and label phishing contracts involved in transaction simulation phishing. This issue is particularly pronounced on Avax and Polygon, where a large fraction of the phishing contracts identified in our study remain unflagged.
Label Status Yes
TP 33
SimGuard Detection Result TN FN Precision 162,975 1 100%
480 293 3,136 315 4,224
Ethereum, 293 on BSC, 3,136 on Avax, and 315 on Polygon. On the Ethereum mainnet, among the 480 phishing contracts, 18 employed the storage-control strategy, 453 adopted the Gas-control strategy, and 9 used the timestamp-control strategy. On BSC, 2 contracts were classified as storage-control, 290 as Gas-control, and 1 as timestampcontrol. On Avax, only 2 contracts leveraged the storage-control strategy, while the remaining 3,134 contracts exclusively relied on Gas-control. On Polygon, all 315 detected phishing contracts adopted the Gas-control strategy. Observations: Overall, the distribution indicates that Gas-control is the dominant phishing contract type, contributing more than 4,100 samples and accounting for 99.2% of all detected phishing contracts. Among the four blockchains, Avalanche (Avax) is the most affected, with over 3,100 samples (74.2%). Interestingly, our results show that External-control, Gasprice-control, and Blocknumbercontrol phishing contracts have not been observed in the wild. We conjecture that the absence of External-control contracts stems from their functional overlap with storage-control contracts, while incurring higher implementation complexity and deployment costs. As a result, attackers may prefer the simpler and more cost-effective storage-control contracts. For Gasprice-control contracts, a likely explanation is the difficulty of selecting a stable and effective Gas price threshold. Most crypto wallets automatically set the gas price based on network congestion status, which can vary significantly over time. Although attackers could choose an extremely high threshold (e.g., 100K Gwei), doing so would require victims to hold a minimum balance of approximately 2.1 ETH2 , thereby substantially reducing the pool of potential victims. The lack of Blocknumber-control contracts may be attributed to the additional operational overhead required by phishing websites to obtain up-to-date block heights (e.g., via RPC calls). This introduces extra network latency and uncertainty, making it harder for attackers to reliably control the execution outcome of victims’ transactions. Therefore, these practical constraints likely discourage attackers from adopting Gaspricecontrol and Blocknumber-control strategies in real-world attacks.
5.2
Timeline Trend of Phishing Contracts
This section analyzes the timeline trend of phishing contracts. We retrieve each phishing contract’s deployment date from the contract creation transaction and aggregate them by their deployment dates.
Figure 4: The timeline trend of phishing contracts deployed on four different blockchains.
Fig. 4 shows the number of phishing contracts created on the four blockchains in different time periods, which reveals several interesting observations. First, the phishing contracts were introduced in Aug. 2024 on three blockchains: Ethereum mainnet, Avax,
2 Assuming a minimum Gas consumption of 21,000 units
7
Table 3: Overview of victim transactions and the associated financial loss.
Blockchain
# Lucky Tx
# Victim Tx
# Victim Address
# Profited Contract
Ethereum BSC Avax Polygon Total
31 1 0 114 146
3,154 1,790 215 1,064 6,223
2,780 1,719 213 1,030 5,742
257 168 138 127 690
and BSC. On Polygon, the phishing contracts were introduced last, which occurred in March 2025. Second, before April 2025, the phishing contracts were occasionally created on the four blockchains, with fewer than 10 contracts deployed on several dates in the first seven months. Third, from April 8th to April 25th, 2025, the number of deployed phishing contracts on Avax experienced a significant growth, with the peak occurring on April 22nd, 2025, when there were more than 550 phishing contracts deployed in a single day. After that, the number dropped to below 10. During the same time period, the daily deployed phishing contracts on the other three blockchains remained at a much smaller number, which was less than 10. Then, later on May 3rd, 2025, the phishing contracts deployed on all four blockchains reached another peak, with more than 100 contracts deployed in a single day. Since then, the daily deployed phishing contracts on the four blockchains remained at a steady rate, mostly fluctuating between 5 and 11. Overall, our timeline trend analysis indicates that the phishing contracts were first introduced by the attackers in Aug. 2024. Then, in the first seven months, the attackers were less active in deploying phishing contracts. Starting in Mar. 2025, the attackers became much more active and created ≈ 10 contracts daily, and the phishing contracts on three blockchains (Ethereum mainnet, BSC, and Polygon) follow a similar trend. However, on Avax, the attackers were much more active in deploying the phishing contracts. Then, on May 3rd, 2025, all four blockchains witnessed a spike of more than 100 phishing contracts deployed on the same day.
5.3
Financial Loss Amount USD Value 1,104.70 ETH $3.19M 277.24 BNB $182.32K 4,308.33 AVAX $111.53K 9,602.15 POL $2.15K $3.48M
After that, we then retrieve the transaction history of each phishing contract to determine the lucky and victim transactions. We first filter out transactions that were sent from the attackers themselves to avoid overestimating the scale of victims and the financial loss. We do so by checking each transaction’s sender against the contract’s deployer address and the funding address. The deployer address refers to the address sending the contract creation transaction to publish the phishing contract to the blockchain, and the funding address refers to the first address that deposits funds to the contract, serving as the contract’s initial bait for attracting victims. After removing such irrelevant transactions, we then determine the type of each remaining transaction based on the above criteria. For each victim transaction, we estimate the associated financial loss based on the market value of the transferred cryptocurrency assets at the time when the transaction was included in the blockchain. Specifically, for each blockchain, we referenced the historical price of its cryptocurrency asset from the corresponding explores (Etherscan, BscScan, SnowScan, and PolygonScan, respectively). Overview of victim transactions: Table 3 shows an overview of the victim transactions and the financial loss to the phishing contracts on the four blockchains. First of all, we can see that on the Ethereum mainnet, BSC, and Polygon, there are, respectively, 31, 1, and 114 lucky transactions that escaped from the phishing trap. On Avax, there is no lucky transaction. Although the lucky transactions have not lost funds, their profit from the phishing contracts is also negligible, as all the phishing contracts only transferred a tiny amount (10K wei) to them. Second, the table also shows that there is a total number of 6,223 victim transactions from 5,742 addresses on the four blockchains, indicating that some victim addresses lost funds twice or more to the phishing contracts. Among all the victim transactions, the Ethereum mainnet contributes the majority (3,154), and Avax contributes the lowest portion (215). In addition, it can be seen that the number of profited contract addresses (CA) on the four blockchains varies between 127 and 257, which is smaller than the number of deployed phishing contracts, indicating that not every phishing contract has made a profit. Among the four blockchains, phishing contracts on the Ethereum mainnet have the highest profitable rate, which is 257/480 = 53.5%. Finally, the total financial loss from all the victim transactions reaches $3.48 million USD. Among them, the Ethereum mainnet is still the dominant blockchain that contributes more than 1,104 ETH, which is worth $3.19 million USD and accounts for 91.5% of the total financial loss. On BSC, victims have lost more than 277 BNB, which is worth more than $182K USD. On Avax and Polygon, victims have lost more than 4,300 AVAX and 9,600 POL, respectively worth $111K USD and $2.15K USD. Overall, our analysis suggests that the phishing
Financial Impact of Phishing Contracts
This section presents our analysis of the victim transactions and the associated financial loss. As previously mentioned, the success of the phishing contracts requires certain conditions to be met, such as the attacker’s transaction successfully frontrunning the victim transactions and the victims manually modifying their transaction fields. Hence, the phishing contracts cannot achieve a 100% success rate, and there could exist some lucky users who escaped from the phishing trap. We thereby define the lucky transaction and victim transaction as follows. • Lucky transaction: If a transaction deposits funds to the phishing contract and then receives back more than the deposited amount, it is deemed a lucky transaction. • Victim transaction: If a transaction deposits funds to the phishing contracts and the funds are immediately moved to another address, it is deemed a victim transaction. 8
Table 4: Profit distribution among different types of phishing contracts.
Blockchain Ethereum BSC Avax Polygon Total
Storage-control # CA Profit (USD) 12 $2.69M 2 $168.26K 2 $110.89K 16 $2.97M (85.37%)
# CA 244 166 136 127 673
Gas-control Profit (USD) $186.59K $14.06K $639.16 $2.15K $203.44K (5.85%)
attackers gained the majority of the profits on the Ethereum mainnet. One potential reason could be that compared to the other three cryptocurrencies, ETH has the highest value and is more popularly owned by users, which hence leads to more victim transactions and the majority of the financial loss on the Ethereum mainnet. In contrast, although Avax has the highest number of phishing contracts, due to most of them not making any profits, its victim transactions and financial loss thereby remained at a small scale. Financial loss by phishing contract type: In Table 4, we show the distribution of the profit collected by different types of phishing contracts on the four blockchains. From the table, we can obtain several interesting findings. First, it can be seen that the "storage-control" phishing contracts have gained most of the profits. With only 12 profited contracts on the Ethereum mainnet, the total profit gained by them exceeds $2.69 million USD. A similar distribution can also be observed on BSC and Avax. With only 2 profited contracts on each blockchain, the total profit gained by them respectively exceeds $168K and $110K USD. In total, the profit collected by "storage-control" phishing contracts is above $2.97 million USD, accounting for 85.3% of our total uncovered profits. Second, compared to "storage-control", "Gas-control" has many more profited contracts, which vary between 127 and 244 on the four blockchains. However, the total profit collected by them is much lower, which is around $203K USD. Third, the table also shows that "timestamp-control" has only one profited contract on the Ethereum mainnet. Despite that, the profit gained by the single contract exceeds $305K USD. Overall, the distribution result suggests that "storage-control" is the most profitable type. We believe one potential reason is that the "storage-control" phishing contract can give the attacker a more deterministic control, as it does not rely on victims to modify certain transaction fields as required in the "Gas-control" contract, or rely on victims to submit transactions with some delays as required in the "timestamp-control" contract. The attacker of the "storage-control" contract can simply bid a high "Gasprice" in their transactions when adding the victim to the blacklist, which can ensure to frontrun the victims’ transactions at a high success rate. Timeline trend of victims’ financial loss: We then present the timeline trend of victim transactions and the associated financial loss in Fig. 5. First of all, from Fig. 5a, we can see that the earliest victim transaction occurred in Aug. 2024 on the Ethereum mainnet, BSC, and Avax, following a similar trend of the deployed phishing contracts. Since then, among the four blockchains, the Ethereum mainnet has always had the highest number of daily victim transactions until May 2025, varying mostly between 10 and 100. In the meantime, the daily number of victim transactions on
Timestamp-control # CA Profit (USD) 1 $305.71K 1 $305.71K (8.78%)
# CA 257 168 138 127 690
Total Profit (%) $3.19M (91.50%) $182.32K (5.24%) $111.53K (3.20%) $2.15K (0.06%) $3.48M
BSC and Avax remains stable, mostly varying between 5 and 50. Then, starting May 9th, 2025, BSC surpasses the Ethereum mainnet to become the leader in the daily number of victim transactions. During the entire period, Polygon has the lowest number of victim transactions most of the time, which varies between 1 and 10. However, the timeline trend of the associated financial loss does not follow a similar pattern. As shown in Fig. 5b, the daily financial loss on the Ethereum mainnet is always one or more orders of magnitude higher than the other three blockchains, which is primarily due to the high value of ETH. In addition, the highest daily financial loss all occurred in Jan. 2025 on the three blockchains, including Ethereum mainnet, BSC, and Avax, respectively, with $1 million USD, $100K USD, and $30K USD. After that, the daily financial loss on the four blockchains remains relatively stable, with occasional spikes on several dates such as Apr. 28th, 2025, and May 12th, 2025. Such a timeline trend indicates that phishing contracts usually can collect a much larger profit when they were first introduced. Later, when the blockchain and crypto wallet community has gained more knowledge, it becomes more difficult for them to sustain the same level of profit due to phishing contracts being continuously labelled and crypto wallet users becoming more cautious. Attackers’ transaction cost: We also look into the attackers’ investment by measuring their transaction cost, which includes the transaction fee paid for deploying the phishing contracts, depositing initial funds to the phishing contracts, and adding users to the blacklist in the "storage-control" phishing contracts. The result is summarized in Table 5. We can see that on all four blockchains, the action of deploying the phishing contracts dominates the attackers’ transaction cost, respectively costing 2.92 ETH, 1.04 BNB, 4.55 AVAX, and 46.25 POL. In comparison, depositing the initial funds to the phishing contracts only costs the attackers 0.08 ETH, 0.01 BNB, 0.04 AVAX, and 0.49 POL, respectively, on the four blockchains. Such an observation can be explained by that although deploying the phishing contracts and depositing the initial funds both incur one-time transaction cost, deploying phishing contracts is much more expensive action, with extra Gas paid for writing the contract bytecode to the blockchain storage, while depositing the initial funds does not involve such a cost and can be completed with the minimum transaction cost of 21,000 Gas. In addition, another part of the attackers’ transaction cost comes from transactions blacklisting users in the "storage-control" contracts. On Ethereum, BSC, and Avax, the attackers respectively spent 21.75 ETH, 0.10 BNB, and 0.57 AVAX to blacklist users, while Polygon does not involve such a cost due to no "storage-control" contracts being detected. Adding up all the transaction costs, the attackers have respectively spent 24.75 ETH, 1.15 BNB, 5.16 AVAX, and 46.74 POL 9
(a) Trend of daily victim transactions.
(b) Trend of daily financial loss in USD.
Figure 5: The timeline trend of victim transactions and the associated financial loss on the four blockchains. Table 5: Overview of attackers’ transaction cost and blacklisted users. Blockchain Ethereum BSC Avax Polygon
Contract Deployment 2.92 ETH 1.04 BNB 4.55 AVAX 46.25 POL
Attackers’ Transaction Cost Initial Blacklisting Subtotal (USD) Funding Users 0.08 ETH 21.75 ETH 24.75 ETH ($77.3K) 0.01 BNB 0.10 BNB 1.15 BNB ($690) 0.04 AVAX 0.57 AVAX 5.16 AVAX ($121) 0.49 POL 46.74 POL ($10)
Table 6: Top phishing contract clusters and their profits. Cluster 1 2 3 4
# Blacklisted Users 3,160 208 124 -
Profit in USD (%) $2.88M (90.4%) $182.32K (100%) $111.53K (100%) $2.15K (100%)
Blockchain Ethereum BSC Avax Polygon
Most Profited Contract 0x4805a2***108433 0xcada58***5c3b78 0x00000c***d00000 0x000049***960000
the same address, we group them together; (3) If the victim’s funds sent to two phishing contracts are internally transferred to the same address, we group them together. Applying the above criteria to the detected phishing contracts, we identify 8 clusters comprising 724 contracts in total. Among them, one dominant cluster emerges on each blockchain and accounts for the majority of the profits on that chain, as summarized in Table 6. In addition, we identify four small clusters, with sizes ranging from 2 to 8 contracts. Three of these appear on the Ethereum mainnet and one on Avax. However, we omit them from the table because none of them generated measurable profit. As shown in Table 6, the largest cluster on the Ethereum mainnet controls 268 phishing contracts and has extracted more than $2.88 million USD, accounting for 90.4% of the profits on Ethereum (approximately 83% of the total profits across all blockchains). The remaining three major clusters are found on BSC, Avax, and Polygon, respectively. Each controls between 130 and 169 contracts and captures 100% of the total profit observed on its corresponding blockchain.
on four blockchains. Comparing with the profits on each blockchain shown in Table 3, the return-on-investment (ROI) of this phishing attack is respectively 4,463%, 24,108%, 83,495%, and 20,544%. Blacklisted users in "storage-control": Among the phishing contracts, one unique characteristic of the "storage-control" phishing contract is that, in order to victimize users, the attackers have to send transactions to add users to the blacklist. Thanks to this characteristic, we can thereby trace the phishing contract’s transaction history to estimate the number of users that have been blacklisted in the "storage-control" phishing contracts. We do so by looking for transactions that add users to the blacklist (e.g., those invoking the add() function) and then retrieving the blacklisted address from the transaction’s input field. The result is presented in Table 5. We can see that there are, respectively, 3,160, 208, 124 unique addresses blacklisted in the "storage-control" phishing contracts on the Ethereum mainnet, BSC, and Avax. Such a result reveals the potential number of users who have visited the phishing website established by the attacker. In addition, we can also see that the number of blacklisted addresses is higher than the actual number of victim addresses on the three blockchains, implying that there were some cautious users who visited the attacker’s phishing website but did not fall victim.
5.4
# Contract 268 169 142 130
5.5
Case Study of Top Profited Contracts
We first show the top 10 most profitable phishing contracts in Table 7, ranked by their profits in USD. We have confirmed that they all belong to phishing contracts through verifying their transaction behaviors and money flow. As can be seen from the table, 9 contracts are deployed on the Ethereum mainnet, and only one contract (ranked at the 5th) is deployed on BSC. In addition, among the 10 contracts, 9 contracts employed the "storage-control" strategy, and only one (ranked at the 3rd) employed the "timestamp-control" strategy. The most profited phishing contract is deployed on the Ethereum mainnet, which solely profited more than $1.2 million USD from 164 victim transactions through the "storage-control" strategy. The second most profited contract also came from the
Phishing Contract Clusters
The phishing contracts detected in our work are not operated independently but rather have connections with each other, which can thus form clusters. In this section, we cluster the phishing contracts with the following criteria: (1) If two phishing contracts are deployed by the same blockchain address, we group them together; (2) If the initial funds of two phishing contracts are deposited from 10
Table 7: The top 10 most profited contracts ranked by USD. Rank 1 2 3 4 5 6 7 8 9 10
Contract Address 0x4805a2***108433 0x000008***700000 0xfef6b0***8270e5 0x00000c***d00000 0xcada58***5c3b78 0x00000c***200000 0x478e1c***6a6825 0x00000c***e00000 0x000007***f00000 0x000000***e00000
Phishing Type storage-control storage-control timestamp-control storage-control storage-control storage-control storage-control storage-control storage-control storage-control
# Victim Tx 164 1 13 13 14 22 8 14 12 8
Profit (USD) $1,206,057.38 $477,195.48 $305,707.27 $290,666.14 $151,644.47 $140,098.19 $127,076.65 $106,578.39 $104,530.76 $91,487.93
address funded the contract with 0.028 ETH as initial funds. Following deployment, the attacker issued multiple transactions to add addresses to the contract’s blacklist. Later that day, at block #21581912, the victim’s address was added to the blacklist. Three blocks later, the victim invoked the claim() function, transferring 143.4 ETH to the phishing contract. The transferred funds were immediately redirected to the attacker’s profit-collection address 0 x000037***Ce0000 via an internal call.
Blockchain Ethereum Ethereum Ethereum Ethereum BSC Ethereum Ethereum Ethereum Ethereum Ethereum
Ethereum mainnet and utilized the "storage-control" strategy. However, this contract profited more than $477K USD in a single victim transaction. The 3rd and 4th most profited contracts are also deployed on the Ethereum mainnet, which respectively profited more than $305K and $290K USD, and both contributed 13 victim transactions. The 5th most profited contract is deployed on BSC, which profited over $151K USD from 14 victim transactions. The last 5 phishing contracts (6th to 10th) are all deployed on the Ethereum mainnet and employ the "storage-control" strategy. Their profits range from $91K to $140K USD, with the number of victim transactions varying between 8 and 22. The profit collected by the 10 contracts reaches $3 million USD, accounting for more than 86% of the total profit uncovered in our work. Most profited phishing contract: The most profited phishing contract is deployed on the Ethereum mainnet at address 0x480 5a2***108433. The contract was created by address 0x220DC8* **C945C6 in transaction 0xb5cc9c9b***c72a0c83 on Aug. 27th, 2024, at block height 20,619,264. On the same day, right after the creation, the attacker sent two transactions to invoke the Add() function to add two targeted users to the blacklist. However, none of the targeted users were successfully deceived because there were no initial funds in the contract. Due to this, users cannot see the profitable opportunity in their transaction simulation results. The attacker quickly realized the problem and then sent four transactions to transfer a tiny amount of ETH (100K wei) to the contract on the same day. After that, another user was targeted and added to the blacklist by the attacker on block # 20,620,183. In the same block, the targeted user sent a transaction to invoke the Claim() function and transferred more than 0.009 ETH. The user’s funds were immediately moved to address 0x000037***Ce0000, making the user fall victim. After 41 blocks, another victim was added to the blacklist and then lost more than 0.007 ETH in the next block. Since then, the attacker kept adding targeted users to the blacklist. Occasionally, there were some users who fell victim. The largest financial loss to this phishing contract was from the victim address 0x116bd2***c546ad, which was added to the blacklist at block # 21323413. Then, the victim transferred more than 18.4 ETH to the phishing contract at block # 21323426. Victim with the largest loss: Among all victim addresses identified in our study, the largest single-transaction loss was from address 0x98Ddab***cD84C2, which transferred more than 143.4 ETH to a storage-control phishing contract. The phishing contract, deployed at address 0x000008***700000, ranks second in Table 7 despite profiting from only a single victim transaction. The contract was deployed by address 0x505506***77BBa9 on Jan. 8, 2025, at block #21579459. Shortly thereafter, at block #21579469, the same
Figure 6: The transaction simulation result displayed on MetaMask where the phishing contract returns 1 wei.
6
DISCUSSION
This section discusses design flaws in crypto wallets when presenting transaction simulation results and recommends potential countermeasures to mitigate this phishing threat. We then outline several limitations of our work.
6.1
Widespread Inaccurate Simulations
In our case study, we show that a victim lost more than 143 ETH to a storage-control phishing contract. However, based on our runtime verification, the reward amount returned by the contract is only 1 wei (10−18 ETH). In fact, the typical returned reward by the phishing contracts detected in our study ranges between 1 and 10,000 wei, a tiny and negligible amount. A natural question arises: why would victims approve transactions that transfer a large portion or even all of their assets in exchange for such a trivial reward? We hypothesize that misleading transaction simulation results presented by crypto wallets play a key role in deceiving users into approving these transactions. To verify this hypothesis, we analyze 11 leading crypto wallets that provide transaction simulation features, including MetaMask, Rabby, and Phantom. For each wallet, we initiate a transaction that transfers our entire account balance (e.g., 0.5 ETH) to a phishing contract that returns 1 wei, and then examine the transaction simulation preview displayed on the wallet’s UI. Surprisingly, we find that most wallets present misleading or inaccurate simulation results. For example, as shown in Fig. 6, MetaMask indicates that executing the transaction would increase our account balance by an amount smaller than 0.000001 ETH. Such a result can easily be misinterpreted by users as a net gain close to 0.000001 ETH. In reality, the returned amount (1 or even 10,000 wei) is far from sufficient to cover the transaction cost, meaning that the user’s actual post-transaction balance change should be negative rather than positive. Similar misleading and inaccurate simulation issues are also observed in other wallets (details are provided in Appendix C). Beyond misleading and inaccurate balance changes, 11
we identify another design issue: most wallets display only the predicted post-transaction balance change in the simulation preview, rather than explicitly showing the exact amount being transferred. As a result, users are not informed that the transaction will transfer their entire account balance to the contract. This lack of visibility into the transferred amount severely limits users’ ability to assess transaction risk. In summary, we believe that misleading and inaccurate simulation results, together with the lack of transparency regarding transferred amounts, jointly contribute to victims approving malicious transactions and suffering substantial financial losses.
6.2
Recommended Countermeasures
To effectively mitigate transaction simulation–based phishing threats, the key is to ensure that wallets present accurate and up-to-date simulation results. Based on our analysis, we recommend the following countermeasures for each type of phishing contract: • Storage-control/External-control: Since this type of phishing contract relies on manipulating contract state, the transaction simulation service should monitor whether the state of the interacted contract, as well as any internally invoked contracts, has changed since the last simulation. If any state change is detected, the transaction should be re-simulated, and the updated results should be presented to the user. • Gas-control: The transaction simulation service should avoid using a default gaslimit and instead simulate the transaction using the gaslimit specified in the transaction request. Furthermore, if the user modifies the gaslimit, the transaction should be re-simulated before signing. • Gasprice-control: Similarly, the transaction simulation service should simulate execution using the transaction’s specified gasprice, and re-simulate the transaction whenever the user modifies this parameter. • Blocknumber-control: As this phishing contract leverages block.number to alter control flow, the simulation service should execute the transaction under both the current block number and a future block number to detect any divergence in execution outcomes. • Timestamp-control: Likewise, the simulation service should simulate the transaction using both the current block timestamp and a future timestamp to identify discrepancies caused by timedependent control logic. Besides, we recommend that wallets also integrate an recipient verification service to protect users, as done in popular wallets such as Coinbase [8]. This service raises warnings when users transfer to smart contracts flagged on blockchain explorers.
6.3
Limitations
Despite detecting more than 4,000 phishing contracts on real-world blockchains, our work has several limitations. First, although we systematically analyzed dynamic variables in the blockchain execution environment to construct our phishing contract taxonomy, attackers may combine multiple variables or exploit alternative strategies that are not covered in this study. For example, phishing contracts could leverage other mutable on-chain states, such as token exchange rates, to control transfer logic. However, we believe 12
such strategies are complex to implement and difficult to deterministically control the execution outcome. Second, SimGuard has limited effectiveness against heavily obfuscated phishing contracts. While such cases are rare in our evaluation, advanced obfuscation techniques can hinder static analysis and symbolic execution. This limitation could potentially be mitigated by incorporating deobfuscation techniques [60] or relying more extensively on runtime verification, albeit at the cost of increased execution and analysis overhead. Third, although we carefully filtered out transactions initiated by attackers when quantifying financial losses, misclassification remains possible. Specifically, if attackers interacted with phishing contracts using addresses not directly associated with the phishing activity (e.g., for testing), these transactions may be mistakenly counted as victim losses. Consequently, our loss estimates should be interpreted as an upper bound rather than exact ground truth. Similarly, our clustering analysis relies solely on observable on-chain associations. Phishing contracts controlled by the same entity may remain unlinked if no such associations are visible, potentially resulting in an overestimation of the number of attacker clusters. Finally, the reported return-on-investment (ROI) accounts only for on-chain transaction costs, including contract deployment, initial funding, and blacklist updates. Other costs, such as domain registration, phishing website promotion, and fund laundering, are difficult to quantify due to limited visibility and are therefore excluded from our analysis.
7
RELATED WORK
Existing work has studied various cryptocurrency phishings and scams, including Ponzi Schemes [30–32, 35, 44, 57], fraudulent Initial Coin Offering [38, 48, 51, 61], fake exchange scams [58], phishing scams [29, 33], giveaway scams [46, 47, 55, 57], honeypot contract scams [34, 53], fake token scam [39, 56], arbitrage bot phishing [45], and blockchain address poisoning [36, 41, 54]. Some of the existing works also proposed new approaches to detect the involved phishing and scam activities. For instance, Li et al. [47] developed a free giveaway scam detection system to collect suspicious registered domains from Certificate Transparency Log (CTLog) and discovered more than 10K giveaway scam URLs. Xia et al. [57] developed a scam detection system for cryptocurrency scams using keywords such as "COVID-19" and "cryptocurrency" on social media platforms, including Twitter, Telegram, Etherscan, etc. Xia et al. [56] developed a scam token detection system based on machine learning models to systematically analyze all tokens listed on the popular DEX, Uniswap. Their work identified over 10K scam tokens that collected $16 million USD. Li et al. [45] developed a detection system to identify phishing arbitrage bot contracts that directly transfer funds from the victims’ addresses to the attackers’ addresses. Their work detected more than 20K phishing contracts on Ethereum mainnet and BSC, and quantified that more than 25K victims lost ≈$15 million USD. Most recently, several studies [36, 41, 54] have developed a detection system to detect phishing transfers involved in the address poisoning attack. These works quantified that the victim’s total financial loss was up to $100 million USD. He et al. [42] developed a detection system for transaction-based phishing attacks launched on fake websites that
directly transfer funds from the victim to the attacker. Their detection system works by monitoring Certificate Transparency Log [9] to identify suspicious domains and then visiting the suspicious website to trigger the transaction signing operations to detect phishing addresses.
8
[26] Transaction simulation spoofing: A new threat in web3. https://defihacklabs.substack.com/p/transaction-simulation-spoofing-a. [27] Trust wallet. https://trustwallet.com/. [28] Tamer Abdelaziz and Aquinas Hobor. Smart learning to find dumb contracts. In 32nd USENIX Security Symposium (USENIX Security 23), pages 1775–1792, 2023. [29] Emad Badawi, Guy-Vincent Jourdan, Gregor Bochmann, and Iosif-Viorel Onut. An automatic detection and analysis of the bitcoin generator scam. In 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), pages 407–416. IEEE, 2020. [30] Massimo Bartoletti, Salvatore Carta, Tiziana Cimoli, and Roberto Saia. Dissecting ponzi schemes on ethereum: identification, analysis, and impact. Future Generation Computer Systems, 102:259–277, 2020. [31] Massimo Bartoletti, Barbara Pes, and Sergio Serusi. Data mining for detecting bitcoin ponzi schemes. In 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), pages 75–84. IEEE, 2018. [32] Lingyu Bian, Linlin Zhang, Kai Zhao, Hao Wang, and Shengjia Gong. Imagebased scam detection method using an attention capsule network. IEEE Access, 9:33654–33665, 2021. [33] Weili Chen, Xiongfeng Guo, Zhiguang Chen, Zibin Zheng, and Yutong Lu. Phishing scam detection on ethereum: Towards financial security for blockchain ecosystem. In IJCAI, volume 7, pages 4456–4462, 2020. [34] Weili Chen, Xiongfeng Guo, Zhiguang Chen, Zibin Zheng, Yutong Lu, and Yin Li. Honeypot contract risk warning on ethereum smart contracts. In 2020 IEEE International Conference on Joint Cloud Computing, pages 1–8. IEEE, 2020. [35] Weili Chen, Zibin Zheng, Jiahui Cui, Edith Ngai, Peilin Zheng, and Yuren Zhou. Detecting ponzi schemes on ethereum: Towards healthier blockchain technology. In Proceedings of the 2018 world wide web conference, pages 1409–1418, 2018. [36] Zhuo Chen, Yufeng Hu, Bowen He, Dong Luo, Lei Wu, and Yajin Zhou. Dissecting payload-based transaction phishing on ethereum. In Network and Distributed Systems Security (NDSS) Symposium, 2025. [37] Zhen Cheng, Xinrui Hou, Runhuai Li, Yajin Zhou, Xiapu Luo, Jinku Li, and Kui Ren. Towards a first step to understand the cryptocurrency stealing attack on ethereum. In 22nd international symposium on research in attacks, intrusions and defenses (RAID 2019), pages 47–60, 2019. [38] Tiffany Chiu, Victoria Chiu, Tawei Wang, and Yunsen Wang. Using textual analysis to detect initial coin offering frauds. Journal of Forensic Accounting Research, 7(1):165–183, 2022. [39] Bingyu Gao, Haoyu Wang, Pengcheng Xia, Siwei Wu, Yajin Zhou, Xiapu Luo, and Gareth Tyson. Tracking counterfeit cryptocurrency end-to-end. Proceedings of the ACM on Measurement and Analysis of Computing Systems, 4(3):1–28, 2020. [40] Fabio Gritti, Nicola Ruaro, Robert McLaughlin, Priyanka Bose, Dipanjan Das, Ilya Grishchenko, Christopher Kruegel, and Giovanni Vigna. Confusum contractum: confused deputy vulnerabilities in ethereum smart contracts. In 32nd USENIX Security Symposium (USENIX Security 23), pages 1793–1810, 2023. [41] Shixuan Guan and Kai Li. Characterizing ethereum address poisoning attack. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 986–1000, 2024. [42] Bowen He, Yuan Chen, Zhuo Chen, Xiaohui Hu, Yufeng Hu, Lei Wu, Rui Chang, Haoyu Wang, and Yajin Zhou. Txphishscope: Towards detecting and understanding transaction-based phishing on ethereum. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, pages 120–134, 2023. [43] Bowen He, Xiaohui Hu, Yufeng Hu, Ting Yu, Rui Chang, Lei Wu, and Yajin Zhou. Phishing tactics are evolving: An empirical study of phishing contracts on ethereum. Proceedings of the ACM on Measurement and Analysis of Computing Systems, 9(2):1–24, 2025. [44] Tyler Kell, Haaroon Yousaf, Sarah Allen, Sarah Meiklejohn, and Ari Juels. Forsage: Anatomy of a smart-contract pyramid scheme. arXiv preprint arXiv:2105.04380, 2021. [45] Kai Li, Shixuan Guan, and Darren Lee. Towards understanding and characterizing the arbitrage bot scam in the wild. Proceedings of the ACM on Measurement and Analysis of Computing Systems, 7(3):1–29, 2023. [46] Kai Li, Darren Lee, and Shixuan Guan. Understanding the cryptocurrency free giveaway scam disseminated on twitter lists. In 2023 IEEE International Conference on Blockchain (Blockchain), pages 9–16. IEEE, 2023. [47] Xigao Li, Anurag Yepuri, and Nick Nikiforakis. Double and nothing: Understanding and detecting cryptocurrency giveaway scams. 2023. [48] Daniel Liebau and Patrick Schueffel. Crypto-currencies and icos: Are they scams? an empirical study. An Empirical Study (January 23, 2019), 2019. [49] Sajad Meisami, Hugo Dabadie, Song Li, Yuzhe Tang, and Yue Duan. Sigscope: Detecting and understanding off-chain message signing-related vulnerabilities in decentralized applications. In Proceedings of the ACM on Web Conference 2025, pages 4284–4299, 2025. [50] Daniel Perez and Benjamin Livshits. Smart contract vulnerabilities: Vulnerable does not imply exploited. In 30th USENIX Security Symposium (USENIX Security 21), pages 1325–1341, 2021. [51] Kenny Phua, Bo Sang, Chishen Wei, and Gloria Yang Yu. Don’t trust, verify: The economics of scams in initial coin offerings. Available at SSRN 4064453, 2022.
CONCLUSION
In this work, we investigate transaction simulation phishing and present the first comprehensive study of this emerging threat. We develop a taxonomy of phishing contracts and design SimGuard, a bytecode-level detection system that combines static and dynamic analysis to identify phishing contracts. Applying SimGuard to the Ethereum mainnet, Binance Smart Chain, Avalanche, and Polygon, we detect over 4,000 phishing contracts and uncover more than 5,700 victims who collectively lost approximately $3.48 million USD. These findings highlight the severity of transaction simulation phishing. We hope this work raises awareness of this previously underexplored attack vector and motivates the development of more robust transaction simulation mechanisms and effective countermeasures across the ecosystem.
9
GENERATIVE AI USAGE
This paper was edited for grammar using ChatGPT. In addition, due to the lack of a ground-truth dataset for phishing contracts, Gemini is used to produce the initial 30 phishing contracts, which are used to construct the ground-truth dataset. The authors have validated the contract code generated by Gemini by manual verification as well as experiment runs to ensure its quality, functionality, and accuracy.
REFERENCES [1] 2025 crypto crime mid-year update: Stolen funds surge as dprk sets new records. https://www.chainalysis.com/blog/2025-crypto-crime-mid-year-update. [2] Avalanche c-chain (avax) blockchain explorer. https://snowscan.xyz. [3] Avax network. https://www.avax.network/. [4] Block and transaction properties. https://docs.soliditylang.org/en/latest/ units-and-global-variables.html#block-and-transaction-properties. [5] Bnb chain. https://www.bnbchain.org/en/bnb-smart-chain. [6] Bscscan: Bnb smart chain explorer. https://bscscan.com/. [7] Code similarity: slither-simil. https://secure-contracts.com/program-analysis/ slither/docs/src/tools/Code-Similarity-Detector.html. [8] Coinbase. https://www.coinbase.com/. [9] Crt.sh. https://certificate.transparency.dev. [10] A dataset of malicious and benign smart contracts. https://huggingface.co/ datasets/forta/malicious-smart-contract-dataset. [11] Ethereum etl. https://github.com/blockchain-etl/ethereum-etl. [12] An ethereum virtual machine opcodes interactive reference. https://www.evm. codes. [13] Etherscan: Ethereum (eth) blockchain explorer. https://etherscan.io/. [14] Fordefi - simulate transactions. https://docs.fordefi.com/developers/ simulate-transactions#simulation-data. [15] foundry - ethereum development framework. https://getfoundry.sh. [16] Google gemini. https://gemini.google.com/. [17] How forta’s predictive ml models detect attacks before exploitation. https://forta.org/blog/ how-fortas-predictive-ml-models-detect-attacks-before-exploitation. [18] Known attacks - ethereum smart-contract best practices. https: //consensysdiligence.github.io/smart-contract-best-practices. [19] Metamask: The ultimate crypto wallet for defi, web3 apps. https://metamask.io/. [20] Polygon. https://www.polygon.com/. [21] Polygon pos chain explorer. https://polygonscan.com. [22] Reachibility of a call statement. https://ucsb-seclab.github.io/greed/examples/ #1-reachibility-of-a-call-statement. [23] Similar contracts search. https://etherscan.io/find-similar-contracts. [24] Solidity programming language. https://solidity.readthedocs.io/en/develop/. [25] Three-address code. https://en.wikipedia.org/wiki/Three-address_code. 13
Algorithm 1 The phishing contract matching algorithm.
[52] Nicola Ruaro, Fabio Gritti, Robert McLaughlin, Ilya Grishchenko, Christopher Kruegel, and Giovanni Vigna. Not your type! detecting storage collision vulnerabilities in ethereum smart contracts. In Network and Distributed Systems Security (NDSS) Symposium 2024, 2024. [53] Christof Ferreira Torres, Mathis Steichen, et al. The art of the scam: Demystifying honeypots in ethereum smart contracts. In 28th USENIX Security Symposium (USENIX Security 19), pages 1591–1607, 2019. [54] Taro Tsuchiya, Jin-Dong Dong, Kyle Soska, and Nicolas Christin. Blockchain address poisoning, 2025. [55] Iman Vakilinia. Cryptocurrency giveaway scam with youtube live stream. In 2022 IEEE 13th Annual Ubiquitous Computing, Electronics & Mobile Communication Conference (UEMCON), pages 0195–0200. IEEE, 2022. [56] Pengcheng Xia, Haoyu Wang, Bingyu Gao, Weihang Su, Zhou Yu, Xiapu Luo, Chao Zhang, Xusheng Xiao, and Guoai Xu. Trade or trick? detecting and characterizing scam tokens on uniswap decentralized exchange. Proc. ACM Meas. Anal. Comput. Syst., 5(3), dec 2021. [57] Pengcheng Xia, Haoyu Wang, Xiapu Luo, Lei Wu, Yajin Zhou, Guangdong Bai, Guoai Xu, Gang Huang, and Xuanzhe Liu. Don’t fish in troubled waters! characterizing coronavirus-themed cryptocurrency scams. In 2020 APWG Symposium on Electronic Crime Research (eCrime), pages 1–14, 2020. [58] Pengcheng Xia, Haoyu Wang, Bowen Zhang, Ru Ji, Bingyu Gao, Lei Wu, Xiapu Luo, and Guoai Xu. Characterizing cryptocurrency exchange scams. Computers & Security, 98:101993, 2020. [59] Kailun Yan, Xiaokuan Zhang, and Wenrui Diao. Stealing trust: Unraveling blind message attacks in web3 authentication. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 555–569, 2024. [60] Sen Yang, Kaihua Qin, Aviv Yaish, and Fan Zhang. Insecurity through obscurity: Veiled vulnerabilities in closed-source contracts. arXiv preprint arXiv:2504.13398, 2025. [61] Dirk A Zetzsche, Ross P Buckley, Douglas W Arner, and Linus Föhr. The ico gold rush: It’s a scam, it’s a bubble, it’s a super challenge for regulators. University of Luxembourg Law Working Paper, (11):17–83, 2017.
A
1: input: the contract’s TAC 2: branch_conditions ← {CALLER, GAS, GASPRICE, TIMES-
TAMP, NUMBER} ← {("caller receives", "more than callvalue")} 4: condition_2 ← {("an external address receives", "callvalue")} 5: for all (function_id, tac_function) do 6: tac_function.build_use_def_graph() 7: for all basic_block in tac_function.blocks do 8: for all st in basic_block.statements do 9: if st is TAC_JUMPI and st.condition ∈ branch_conditions then start_block ← first block in tac_function.blocks 10: where block.id = st.block_id 11: if start_block ≠ NULL and number of successors of start_block = 2 then 12: succ ← successor blocks of start_block 13: if find(succ[0], condition_1) and find(succ[1], condition_2) then 14: print(st.condition, "True") else if find(succ[0], condition_2) and 15: find(succ[1], condition_1) then 16: print(st.condition, "True") 17: else 18: print(st.condition, "False") 19: end if 20: end if 21: end if 22: end for 23: end for 24: end for 3: condition_1
ETHICAL CONSIDERATION
For those phishing contracts and contract deployer addresses remain unlabelled on the four blockchains explorers, we have contacted the corresponding explorers to report the phishing addresses to protect cryptocurrency users. Meanwhile, we have also reported the transaction simulation phishing threat and the UI design flaws of presenting misleading and inaccurate simulation results to the crypto wallet developers. We also recommend the proposed countermeasures to them for mitigation consideration. In addition, we are currently deploying our detection system to continuously identify and report phishing addresses involved in this phishing activity. Finally, in this paper, we also tried our best to protect the anonymity of the victims and attackers by shortening their addresses presented in Sec. 5. Though the data we collected from the blockchains are already part of the public blockchain ledger, we also discarded them after accomplishing the paper’s analysis and writing.
B
C
ADDITIONAL WALLET TESTING SCREENSHOTS
Fig. 7 shows the screenshots of transaction simulation results displayed on 8 wallets when interacting with a phishing contract that returns 1 wei.
D
JUSTIFICATION OF EXPLOITABLE DYNAMIC VARIABLES
Table 8 summarizes the full list of various property variables in the EVM-compatible blockchains. For each variable, we provide a detailed reason on why it can or cannot be abused to implement a phishing contract to exploit the transaction simulation service.
SUSPICIOUS TRANSFER DETECTION ALGORITHM
Algorithm 1 is developed for detecting suspicious transfers from a contract’s TAC. In summary, the algorithm starts by searching all JUMPI instructions in the contract’s TAC and then analyzing their successor basic blocks to search suspcious transfer patterns, as well as the dependency of the control variable referenced in the JUMPI instruction. 14
(a) Transaction simulation result displayed on Backpack (e) Transaction simulation result displayed on Phantom
(f) Transaction simulation result displayed on Rabby
(b) Transaction simulation result displayed on Backpack Core
(g) Transaction simulation result displayed on TokenPocket
(c) Transaction simulation result displayed on Ctrl
(h) Transaction simulation result displayed on Nest (d) Transaction simulation result displayed on OneKey
Figure 7: Additional testing screenshots of the transaction simulation results displayed on different wallets’ UI when interacting with the phishing contract. Table 8: The list of property variables in solidity. Class
Block
Transaction
Smart Contract
Variable Name blockhash block.basefee block.blobbasefee block.chainid block.coinbase block.difficulty block.gaslimit block.number block.prevrandao block.timestamp gasleft msg.data msg.sender msg.sig msg.value blobhash tx.gasprice tx.origin storage
Dynamic? yes yes yes no yes no no yes yes yes yes no no no no no yes no yes
Can be Abused? no no no no no no no yes no yes yes no no no no no yes no yes
Reason unpredictable value, offering no deterministic control over the execution path unpredictable value, offering no deterministic control over the execution path unpredictable value, offering no deterministic control over the execution path a deterministic number for each chain (mainnet = 1) unpredictable value, offering no deterministic control over the execution path fixed at 0 in the mainnet after transitioning to PoS a deterministic number for each chain (mainnet = 60 million) monotonically increase, offering a deterministic control over the execution path unpredictable value, attacker has no deterministic control over the execution path monotonically increase, offering a deterministic control over the execution path adjustable to both transaction simulator or users, can be abused to alter execution path cannot be adjusted cannot be adjusted cannot be adjusted cannot be adjusted cannot be adjusted adjustable to both transaction simulator or users, can be abused to alter execution path cannot be adjusted can be manipulated through sending concurrent transactions to frontrun transaction simlator
15