Pith. sign in

REVIEW 3 major objections 5 minor 61 references

Blockchain Transaction Simulation Phishing

T0 review · 3 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

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

Pith's one-line read Crypto wallets' transaction previews can be turned into a phishing tool that has already stolen $3.48 million.

desk verdict Real storage-control attack, but the dominant gas-control variant is unverified — the big scale numbers overreach. read the letter →

arxiv 2607.28747 v1 pith:MH52F5BN submitted 2026-07-30 cs.CR

Xiaocan Wang , Shixuan Guan , Tong Yang , Xiapu Luo , Yue Duan , Kai Li This is my paper · ORCID
classification cs.CR
keywords transactionsimulationphishingsmartcontractsecuritycryptowalletEVMTOCTOUdetectionblockchainmeasurementSimGuard
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper establishes that transaction simulation—a security feature in crypto wallets that previews a transaction's balance changes before signing—is itself exploitable. Attackers deploy contracts whose execution depends on dynamic blockchain state (storage, gas limit, gas price, block number, or timestamp), so a simulation shows a small profit while the real on-chain execution sends the user's deposit to an attacker-controlled address. The authors name this 'transaction simulation phishing,' classify the contracts into six types, and build a bytecode-level detector, SimGuard, to find them. Across Ethereum, BSC, Avalanche, and Polygon, SimGuard detects 4,224 phishing contracts and traces over 5,700 victim addresses to roughly $3.48 million in losses, with storage-controlled contracts responsible for 85% of the take. This matters because the defense meant to protect users has a blind spot, and the paper's countermeasures—such as simulating with the actual gas parameters and re-simulating after state changes—are concrete and testable.

What carries the argument

The load-bearing construction is the two-branch contract with a state-dependent conditional (JUMPI) whose two successors make contrasting transfers: one sends the caller the deposit plus extra wei, the other sends the deposit to an external address. SimGuard detects this pattern by symbolically executing each contract's bytecode into three-address code, matching the two-branch structure, and then confirming the divergent behaviors by running test transactions in a controlled local environment. The detection criteria map the JUMPI's data-flow dependency to one of six control variables—SLOAD+CALLER, external CALL data+CALLER, tx.gas, tx.gasprice, block.number, block.timestamp—which yields the

What would settle it

Take a random sample of the 6,223 'victim transactions' and trace the immediate recipient addresses; if any substantial share of those recipients is controlled by the same deployer or later returns funds voluntarily, the claimed victim count and the $3.48M upper bound collapse.

Watch

Extended reading notes

Core claim

The central claim is that the very feature meant to protect users—a wallet's speculative execution of a pending transaction—creates a time-of-check-to-time-of-use race. A phishing contract has two branches: one returns the caller's deposit plus a token profit; the other redirects the deposit to an attacker-controlled address. Which branch runs depends on a mutable environment variable (contract storage, tx.gas, tx.gasprice, block.number, block.timestamp). At simulation time the benign branch is taken; by the time the transaction is mined, the attacker has changed the state (e.g., front-running a blacklist insertion, or simply letting time pass), so the malicious branch executes. The paper ar

Load-bearing premise

The quantitative scale (5,742 victims, $3.48M) rests on the assumption that every deposit to a detected phishing contract that is immediately forwarded to another address is a victim loss; if attackers used fresh or testing addresses that do not match the deployer/funding filter, or if some contracts have legitimate payout flows, these numbers are overestimates.

Editorial extensions

If this is right

  • If wallets simulate with the user's actual gas limit and gas price rather than defaults, gas-controlled phishing contracts would show the loss instead of a profit.
  • If wallets re-simulate after any state change in the target contract or in internally invoked contracts, storage-controlled attacks lose their race-window advantage.
  • Blockchain explorers have labeled only a fraction of the detected contracts (for example, 12 of 3,136 on Avalanche); better labeling would warn users and raise attackers' costs.
  • The clustering analysis suggests that a small number of coordinated groups run most of the campaign, so removing eight major clusters could disrupt the majority of the revenue.
  • The taxonomy is a natural basis for wallet-embedded detection: a matched two-branch transfer pattern is simple enough to check in a simulation module before a user signs.

Reading between the lines

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

  • The same divergence logic can be extended to any dynamic state that wallets do not snapshot, such as oracle prices or token exchange rates, so the six-category taxonomy is likely open-ended.
  • The attack exposes a general design lesson: any security feature that previews an action against a snapshot and then lets the real action proceed against a changed world is vulnerable unless the preview is re-validated or bound to the actual inputs.
  • The heavy concentration of losses on Ethereum suggests attackers optimize for token value; as other EVM chains accumulate value, they may migrate. A concrete extension would be to run the same detector on rollups like Arbitrum and Optimism.
  • The victim count and loss total are best read as upper bounds because attacker test transactions using fresh addresses could be miscounted; the existence of the attack, however, does not depend on these precise figures.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper introduces "transaction simulation phishing," an attack that exploits wallet transaction-simulation features. It proposes a taxonomy of six phishing contract types (storage-control, external-control, Gas-control, Gasprice-control, blocknumber-control, timestamp-control), presents SimGuard, a bytecode-level detector combining symbolic execution, suspicious-transfer pattern matching, and runtime verification, and applies it to Ethereum, BSC, Avalanche, and Polygon. The paper reports 4,224 detected phishing contracts, more than 5,742 victims, and approximately $3.48M in losses, with Gas-control contracts comprising 99.2% of detections. A real victim case involving a 143.4 ETH loss and wallet UI tests of simulation results are used as supporting evidence for the threat.

Significance. If substantiated, this is a timely and novel attack surface: it challenges the core assumption that transaction simulation protects users from fund-draining contracts. The paper offers a systematic taxonomy, an open-source detector, and large-scale measurements, and the 143.4 ETH case study plus the high rate of external explorer labels on Ethereum (416/480) are concrete strengths. However, the dominant detected variant's mechanism is not empirically validated, and the ground-truth and loss-quantification methodologies contain circular or heuristic elements. The contribution is potentially significant, but the headline scale and the claimed bypass of simulation defenses currently rest on assumptions that need direct evidence.

major comments (3)
  1. [Section 3.2, Table 2, Section 6.1] Gas-control contracts account for 4,192 of 4,224 detections (99.2%), but the paper provides no evidence that any wallet simulator uses a smaller default gas limit than the transaction's specified gas limit. The description in Sec. 3.2 says 'the transaction simulator may use a smaller default Gas limit,' yet the wallet evaluation in Sec. 6.1 only tests a contract returning 1 wei and never exercises gas-dependent control flow. Runtime verification (Sec. 4.1) confirms only that the contract has both a profit and a loss branch when executed under different gas limits in Foundry, not that a wallet's simulation will take the profit branch. If simulators honor the transaction's gas limit, these contracts would show the draining outcome during simulation and would be ordinary honeypots, not a bypass of transaction simulation. This is load-bearing for the headline claim of over 4,000 phishing con
  2. [Section 4.2, Table 1] The ground-truth for phishing contracts is partly circular. Of the 44 phishing contracts, 30 were synthesized by Gemini from the exact specifications in Sec. 3.2, and SimGuard's detection criteria were designed from that same taxonomy. The reported 97.72% recall therefore largely measures whether the detector recognizes contracts that were generated to match its own design, not independent detection capability. The 14 snowball-sampled, explorer-labeled storage-control contracts are real evidence, but the aggregate metric conflates them with self-satisfying synthetic examples. Please report recall separately for the 14 real contracts and either remove the synthetic contracts from the headline metric or clearly label them as robustness/sanity checks only.
  3. [Section 5.3, Section 6.3] The victim and loss quantification relies on a broad heuristic: any non-deployer/non-funding transaction that deposits funds to a detected phishing contract and whose funds are 'immediately moved to another address' is counted as a victim transaction. Attackers may use fresh or test addresses not captured by the deployer/funding filter, and some contracts may have bait or payout flows that look like immediate movement. The paper acknowledges in Sec. 6.3 that losses are upper bounds, but the abstract and Sec. 1 present 5,742 victims and $3.48M without that caveat. The quantitative claims should be tightened (e.g., cross-checking blacklist events for storage-control, requiring the destination to belong to a known attacker cluster, or excluding dust amounts) or consistently described in the abstract and introduction as upper-bound estimates.
minor comments (5)
  1. [Section 2.3] The text says 'As shown in Fig. 6' when referring to the MetaMask simulation illustration; the actual figure is Fig. 1. Cross-reference needs correction.
  2. [Section 3.2] In the External-control paragraph, 'stotage-control' is a typo for 'storage-control.'
  3. [Table 2] The 'Yes/No' columns under 'Phishing Contract Label Status' are not explained in the caption. Clarify that 'Yes' means flagged as phishing by the corresponding block explorer.
  4. [Section 6.1 / Appendix C] The paper says it analyzes 11 leading wallets, but Appendix C shows screenshots for only eight wallets. Clarify what was tested for the remaining wallets and whether they were omitted because no simulation feature was available.
  5. [Section 5.3] The definition of 'lucky transaction' relies on detecting that a transaction 'receives back more than the deposited amount.' Please state the on-chain signals used to identify this return (e.g., internal transactions) and how the comparison is performed when multiple internal transfers occur.

Circularity Check

1 steps flagged · score 4.0 of 10

Partially circular detector evaluation: 30 Gemini test contracts are generated from the same Sec. 3.2 specifications that define SimGuard's detection pattern; independent explorer labels keep the main result grounded.

  1. self definitional [Section 4.2 (ground-truth evaluation); see also Section 9 (Generative AI Usage)]
    "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."

    Sec. 3.2 defines each phishing variant as a two-branch contract: one branch returns the caller's deposit plus a small profit, the other sends it to an attacker-controlled address. SimGuard's Sec. 4.1 recognition criteria are exactly that pattern (JUMPI joining two CALL-bearing successors; one sends CALLVALUE plus extra to CALLER, the other sends CALLVALUE to an external address). The 30 Gemini contracts are constructed from those same specifications, so detecting 29/30 (the only miss being an obfuscated Gasprice contract) and reporting 97.72% recall mainly tests whether the analyzer survives added obfuscations, not whether the pattern identifies real phishing. The 14 Etherscan-labeled real contracts and 416/480 Ethereum explorer labels are independent, so circularity is partial.

full rationale

The only material circularity is in the ground-truth recall evaluation. SimGuard's detection criteria (Sec. 4.1) are the two-branch return-profit-vs-redirect-deposit pattern that constitutes the Sec. 3.2 taxonomy, and the 30 Gemini contracts are explicitly generated from those same specifications. Thus the reported 97.72% recall is partly a self-consistency check. However, the paper has independent grounding for its central claims: all 14 snowball-sampled Etherscan-labeled contracts are detected, and 416 of the 480 Ethereum detections (899 across all chains) carry explorer phishing labels. These external benchmarks mean the existence and scale of the attack do not reduce to the synthetic inputs. I found no load-bearing self-citation chain: [41] and [45] appear only in related-work context and are not used to justify the taxonomy, detector, or loss estimates. The Gas-control dominance (99.2% of detections) rests on an untested assumption that some real simulators use a smaller default gas limit, but that is an evidentiary gap rather than a definitional or statistical circularity, so it is not scored as circularity. Score 4 reflects partial circularity in the synthetic recall numbers with independent external grounding for the main result.

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

The paper introduces no new physical or theoretical entities. The free parameters are hand-chosen thresholds/definitions in the detection and loss pipeline. The axioms are standard tooling and modeling assumptions plus one ad-hoc classification rule for the runtime verification. These are the main assumptions that the quantitative claims rest on.

free parameters (2)
  • bytecode similarity threshold = 0.9
    Used in snowball sampling (Section 4.2) to decide which contracts are similar to the seed phishing contract; affects the composition of the ground-truth phishing dataset and hence the reported recall.
  • lucky/victim transaction criteria = receives back more than deposited; funds immediately moved to another address
    Hand-set operational definitions in Section 5.3 that determine victim counts and loss estimates. No independent validation; the paper itself notes these counts are upper bounds.
assumptions (4)
  • domain assumption The symbolic execution tool 'greed' correctly models all EVM opcode semantics and enumerates all relevant execution paths for the analyzed bytecode.
    Section 4.1 relies on greed to produce a three-address code and all branches; if the tool misses paths (e.g., due to heavy obfuscation), the detector's recall could be overestimated.
  • domain assumption Transaction simulation in wallets executes against a snapshot of the current state without detecting concurrent state changes (the TOCTOU assumption).
    Section 3.1 builds the attack on this assumption; the authors test 11 wallets for one contract in Section 6.1, but not all wallet behaviors and all contract types are exhaustively verified.
  • domain assumption Blockchain explorer 'phishing' labels (Etherscan, BscScan, SnowScan, PolygonScan) are accurate ground truth for validation.
    Used in Section 4.2 to retain only labeled contracts in the phishing ground truth and in Section 5.1 to validate detection results; explorer labels can lag or be incomplete.
  • ad hoc to paper A contract is confirmed as phishing if runtime testing shows both a profit scenario and a financial-loss scenario.
    The runtime verification in Section 4.1 equates the binary behavior pattern from the taxonomy with malicious intent; this pattern could in principle appear in benign contracts (e.g., loyalty programs or rebate schemes).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Blockchain Transaction Simulation Phishing." pith.science (2026). https://pith.science/paper/MH52F5BN

@misc{pith2026260728747,
  author       = {Pith},
  title        = {Pith review of: Blockchain Transaction Simulation Phishing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MH52F5BN}},
  note         = {Machine review of arXiv:2607.28747}
}
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.

Figures

Figures reproduced from arXiv: 2607.28747 by the authors.

Figure 1
Figure 1. The transaction simulation feature on MetaMask. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The workflow of the transaction simulation phishing: The victim first visits a cryptocurrency airdrop website that [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. The phishing contract detection pipeline of [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: The timeline trend of phishing contracts deployed [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: The timeline trend of victim transactions and the associated financial loss on the four blockchains. [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: The transaction simulation result displayed on [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]
Figure 7
Figure 7. Figure 7: Additional testing screenshots of the transaction simulation results displayed on different wallets’ UI when interacting [PITH_FULL_IMAGE:figures/full_fig_p015_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

61 extracted references · 2 linked inside Pith

  1. [1]

    https://www.chainalysis.com/blog/2025-crypto-crime-mid-year-update

    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

    2025

  2. [2]

    https://snowscan.xyz

    Avalanche c-chain (avax) blockchain explorer. https://snowscan.xyz

  3. [3]

    https://www.avax.network/

    Avax network. https://www.avax.network/

  4. [4]

    https://docs.soliditylang.org/en/latest/ units-and-global-variables.html#block-and-transaction-properties

    Block and transaction properties. https://docs.soliditylang.org/en/latest/ units-and-global-variables.html#block-and-transaction-properties

  5. [5]

    https://www.bnbchain.org/en/bnb-smart-chain

    Bnb chain. https://www.bnbchain.org/en/bnb-smart-chain

  6. [6]

    https://bscscan.com/

    Bscscan: Bnb smart chain explorer. https://bscscan.com/

  7. [7]

    https://secure-contracts.com/program-analysis/ slither/docs/src/tools/Code-Similarity-Detector.html

    Code similarity: slither-simil. https://secure-contracts.com/program-analysis/ slither/docs/src/tools/Code-Similarity-Detector.html

  8. [8]

    https://www.coinbase.com/

    Coinbase. https://www.coinbase.com/

Show all 61 references
  1. [9]

    https://certificate.transparency.dev

    Crt.sh. https://certificate.transparency.dev

  2. [10]

    https://huggingface.co/ datasets/forta/malicious-smart-contract-dataset

    A dataset of malicious and benign smart contracts. https://huggingface.co/ datasets/forta/malicious-smart-contract-dataset

  3. [11]

    https://github.com/blockchain-etl/ethereum-etl

    Ethereum etl. https://github.com/blockchain-etl/ethereum-etl

  4. [12]

    https://www.evm

    An ethereum virtual machine opcodes interactive reference. https://www.evm. codes

  5. [13]

    https://etherscan.io/

    Etherscan: Ethereum (eth) blockchain explorer. https://etherscan.io/

  6. [14]

    https://docs.fordefi.com/developers/ simulate-transactions#simulation-data

    Fordefi - simulate transactions. https://docs.fordefi.com/developers/ simulate-transactions#simulation-data

  7. [15]

    https://getfoundry.sh

    foundry - ethereum development framework. https://getfoundry.sh

  8. [16]

    https://gemini.google.com/

    Google gemini. https://gemini.google.com/

  9. [17]

    https://forta.org/blog/ how-fortas-predictive-ml-models-detect-attacks-before-exploitation

    How forta’s predictive ml models detect at- tacks before exploitation. https://forta.org/blog/ how-fortas-predictive-ml-models-detect-attacks-before-exploitation

  10. [18]

    https: //consensysdiligence.github.io/smart-contract-best-practices

    Known attacks - ethereum smart-contract best practices. https: //consensysdiligence.github.io/smart-contract-best-practices

  11. [19]

    https://metamask.io/

    Metamask: The ultimate crypto wallet for defi, web3 apps. https://metamask.io/

  12. [20]

    https://www.polygon.com/

    Polygon. https://www.polygon.com/

  13. [21]

    https://polygonscan.com

    Polygon pos chain explorer. https://polygonscan.com

  14. [22]

    https://ucsb-seclab.github.io/greed/examples/ #1-reachibility-of-a-call-statement

    Reachibility of a call statement. https://ucsb-seclab.github.io/greed/examples/ #1-reachibility-of-a-call-statement

  15. [23]

    https://etherscan.io/find-similar-contracts

    Similar contracts search. https://etherscan.io/find-similar-contracts

  16. [24]

    https://solidity.readthedocs.io/en/develop/

    Solidity programming language. https://solidity.readthedocs.io/en/develop/

  17. [25]

    https://en.wikipedia.org/wiki/Three-address_code

    Three-address code. https://en.wikipedia.org/wiki/Three-address_code

  18. [26]

    https://defihacklabs.substack.com/p/transaction-simulation-spoofing-a

    Transaction simulation spoofing: A new threat in web3. https://defihacklabs.substack.com/p/transaction-simulation-spoofing-a

  19. [27]

    https://trustwallet.com/

    Trust wallet. https://trustwallet.com/

  20. [28]

    Smart learning to find dumb contracts

    Tamer Abdelaziz and Aquinas Hobor. Smart learning to find dumb contracts. In 32nd USENIX Security Symposium (USENIX Security 23), pages 1775–1792, 2023

    2023

  21. [29]

    An automatic detection and analysis of the bitcoin generator scam

    Emad Badawi, Guy-Vincent Jourdan, Gregor Bochmann, and Iosif-Viorel Onut. An automatic detection and analysis of the bitcoin generator scam. In2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), pages 407–416. IEEE, 2020

    2020

  22. [30]

    Dissect- ing ponzi schemes on ethereum: identification, analysis, and impact.Future Generation Computer Systems, 102:259–277, 2020

    Massimo Bartoletti, Salvatore Carta, Tiziana Cimoli, and Roberto Saia. Dissect- ing ponzi schemes on ethereum: identification, analysis, and impact.Future Generation Computer Systems, 102:259–277, 2020

    2020

  23. [31]

    Data mining for detecting bitcoin ponzi schemes

    Massimo Bartoletti, Barbara Pes, and Sergio Serusi. Data mining for detecting bitcoin ponzi schemes. In2018 Crypto Valley Conference on Blockchain Technology (CVCBT), pages 75–84. IEEE, 2018

    2018

  24. [32]

    Image- based scam detection method using an attention capsule network.IEEE Access, 9:33654–33665, 2021

    Lingyu Bian, Linlin Zhang, Kai Zhao, Hao Wang, and Shengjia Gong. Image- based scam detection method using an attention capsule network.IEEE Access, 9:33654–33665, 2021

    2021

  25. [33]

    Phish- ing scam detection on ethereum: Towards financial security for blockchain ecosys- tem

    Weili Chen, Xiongfeng Guo, Zhiguang Chen, Zibin Zheng, and Yutong Lu. Phish- ing scam detection on ethereum: Towards financial security for blockchain ecosys- tem. InIJCAI, volume 7, pages 4456–4462, 2020

    2020

  26. [34]

    Honeypot contract risk warning on ethereum smart contracts

    Weili Chen, Xiongfeng Guo, Zhiguang Chen, Zibin Zheng, Yutong Lu, and Yin Li. Honeypot contract risk warning on ethereum smart contracts. In2020 IEEE International Conference on Joint Cloud Computing, pages 1–8. IEEE, 2020

    2020

  27. [35]

    Detecting ponzi schemes on ethereum: Towards healthier blockchain technology

    Weili Chen, Zibin Zheng, Jiahui Cui, Edith Ngai, Peilin Zheng, and Yuren Zhou. Detecting ponzi schemes on ethereum: Towards healthier blockchain technology. InProceedings of the 2018 world wide web conference, pages 1409–1418, 2018

    2018

  28. [36]

    Dissecting payload-based transaction phishing on ethereum

    Zhuo Chen, Yufeng Hu, Bowen He, Dong Luo, Lei Wu, and Yajin Zhou. Dissecting payload-based transaction phishing on ethereum. InNetwork and Distributed Systems Security (NDSS) Symposium, 2025

    2025

  29. [37]

    Towards a first step to understand the cryptocurrency stealing attack on ethereum

    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. In22nd international symposium on research in attacks, intrusions and defenses (RAID 2019), pages 47–60, 2019

    2019

  30. [38]

    Using textual analysis to detect initial coin offering frauds.Journal of Forensic Accounting Research, 7(1):165–183, 2022

    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

    2022

  31. [39]

    Tracking counterfeit cryptocurrency end-to-end.Proceedings of the ACM on Measurement and Analysis of Computing Systems, 4(3):1–28, 2020

    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

    2020

  32. [40]

    Confusum contractum: confused deputy vulnerabilities in ethereum smart contracts

    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. In32nd USENIX Security Symposium (USENIX Security 23), pages...

    2023

  33. [41]

    Characterizing ethereum address poisoning attack

    Shixuan Guan and Kai Li. Characterizing ethereum address poisoning attack. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communi- cations Security, pages 986–1000, 2024

    2024

  34. [42]

    Txphishscope: Towards detecting and understand- ing transaction-based phishing on ethereum

    Bowen He, Yuan Chen, Zhuo Chen, Xiaohui Hu, Yufeng Hu, Lei Wu, Rui Chang, Haoyu Wang, and Yajin Zhou. Txphishscope: Towards detecting and understand- ing transaction-based phishing on ethereum. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Secu...

    2023

  35. [43]

    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

    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

    2025

  36. [44]

    Forsage: Anatomy of a smart-contract pyramid scheme.arXiv preprint arXiv:2105.04380, 2021

    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

    2021 arXiv

  37. [45]

    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

    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

    2023

  38. [46]

    Understanding the cryptocurrency free giveaway scam disseminated on twitter lists

    Kai Li, Darren Lee, and Shixuan Guan. Understanding the cryptocurrency free giveaway scam disseminated on twitter lists. In2023 IEEE International Conference on Blockchain (Blockchain), pages 9–16. IEEE, 2023

    2023

  39. [47]

    Double and nothing: Understand- ing and detecting cryptocurrency giveaway scams

    Xigao Li, Anurag Yepuri, and Nick Nikiforakis. Double and nothing: Understand- ing and detecting cryptocurrency giveaway scams. 2023

    2023

  40. [48]

    Crypto-currencies and icos: Are they scams? an empirical study.An Empirical Study (January 23, 2019), 2019

    Daniel Liebau and Patrick Schueffel. Crypto-currencies and icos: Are they scams? an empirical study.An Empirical Study (January 23, 2019), 2019

    2019

  41. [49]

    Sigscope: Detecting and understanding off-chain message signing-related vulnerabilities in decentralized applications

    Sajad Meisami, Hugo Dabadie, Song Li, Yuzhe Tang, and Yue Duan. Sigscope: Detecting and understanding off-chain message signing-related vulnerabilities in decentralized applications. InProceedings of the ACM on Web Conference 2025, pages 4284–4299, 2025

    2025

  42. [50]

    Smart contract vulnerabilities: Vulnerable does not imply exploited

    Daniel Perez and Benjamin Livshits. Smart contract vulnerabilities: Vulnerable does not imply exploited. In30th USENIX Security Symposium (USENIX Security 21), pages 1325–1341, 2021

    2021

  43. [51]

    Don’t trust, verify: The economics of scams in initial coin offerings.A vailable at SSRN 4064453, 2022

    Kenny Phua, Bo Sang, Chishen Wei, and Gloria Yang Yu. Don’t trust, verify: The economics of scams in initial coin offerings.A vailable at SSRN 4064453, 2022. 13

    2022

  44. [52]

    Not your type! detecting storage collision vulnera- bilities in ethereum smart contracts

    Nicola Ruaro, Fabio Gritti, Robert McLaughlin, Ilya Grishchenko, Christopher Kruegel, and Giovanni Vigna. Not your type! detecting storage collision vulnera- bilities in ethereum smart contracts. InNetwork and Distributed Systems Security (NDSS) Symposium 2024, 2024

    2024

  45. [53]

    The art of the scam: Demystifying honeypots in ethereum smart contracts

    Christof Ferreira Torres, Mathis Steichen, et al. The art of the scam: Demystifying honeypots in ethereum smart contracts. In28th USENIX Security Symposium (USENIX Security 19), pages 1591–1607, 2019

    2019

  46. [54]

    Blockchain address poisoning, 2025

    Taro Tsuchiya, Jin-Dong Dong, Kyle Soska, and Nicolas Christin. Blockchain address poisoning, 2025

    2025

  47. [55]

    Cryptocurrency giveaway scam with youtube live stream

    Iman Vakilinia. Cryptocurrency giveaway scam with youtube live stream. In2022 IEEE 13th Annual Ubiquitous Computing, Electronics & Mobile Communication Conference (UEMCON), pages 0195–0200. IEEE, 2022

    2022

  48. [56]

    Trade or trick? detecting and charac- terizing scam tokens on uniswap decentralized exchange.Proc

    Pengcheng Xia, Haoyu Wang, Bingyu Gao, Weihang Su, Zhou Yu, Xiapu Luo, Chao Zhang, Xusheng Xiao, and Guoai Xu. Trade or trick? detecting and charac- terizing scam tokens on uniswap decentralized exchange.Proc. ACM Meas. Anal. Comput. Syst., 5(3), dec 2021

    2021

  49. [57]

    Don’t fish in troubled waters! charac- terizing coronavirus-themed cryptocurrency scams

    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! charac- terizing coronavirus-themed cryptocurrency scams. In2020 APWG Symposium on Electronic Crime Research (eCrime), pages 1–14, 2020

    2020

  50. [58]

    Characterizing cryptocurrency exchange scams.Computers & Security, 98:101993, 2020

    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

    2020

  51. [59]

    Stealing trust: Unraveling blind message attacks in web3 authentication

    Kailun Yan, Xiaokuan Zhang, and Wenrui Diao. Stealing trust: Unraveling blind message attacks in web3 authentication. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 555–569, 2024

    2024

  52. [60]

    Insecurity through obscurity: Veiled vulnerabilities in closed-source contracts.arXiv preprint arXiv:2504.13398, 2025

    Sen Yang, Kaihua Qin, Aviv Yaish, and Fan Zhang. Insecurity through obscurity: Veiled vulnerabilities in closed-source contracts.arXiv preprint arXiv:2504.13398, 2025

    2025 arXiv

  53. [61]

    caller receives

    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 ETHICAL CONSIDERATION For those phishing contracts and contrac...

    2017

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.