Crypto wallets increasingly simulate transactions before users sign them. The idea is simple: execute the transaction virtually, show the expected balance changes, and warn the user if funds appear likely to move somewhere unexpected.
This feature is now common in wallets such as MetaMask, Coinbase Wallet, and Trust Wallet. It is a useful defense against conventional crypto phishing, in which a malicious transaction directly drains a victim’s assets. But simulation has also created a new problem: attackers can design smart contracts that look safe in a wallet preview and become malicious only after the transaction is confirmed on-chain.
What Researchers Found
A recent preprint, Blockchain Transaction Simulation Phishing by Xiaocan Wang and colleagues, names this technique transaction simulation phishing. The authors analyzed Ethereum, BNB Smart Chain, Avalanche, and Polygon and reported more than 4,200 associated contracts, about 5,700 victim addresses, and an estimated .48 million in losses.
The core lesson is uncomfortable: a successful simulation does not necessarily predict what a blockchain transaction will ultimately do.
How Transaction Simulation Phishing Works
A transaction simulation executes a proposed transaction without permanently changing the blockchain. The wallet uses the current network state and selected transaction parameters to estimate the result. In a normal phishing attempt, this preview may reveal that the user is about to lose tokens or send funds to an unfamiliar address.
Transaction simulation phishing turns that protection against the user. The malicious contract contains multiple execution paths. One path returns the user’s deposit and perhaps a tiny “profit.” Another transfers the same deposit to an attacker-controlled address. The selected path depends on information that can change between simulation and execution.
A typical attack follows this sequence:
- A victim visits a fraudulent airdrop, giveaway, or token-claim website.
- The website connects to the victim’s wallet and prepares a transaction that sends funds to a malicious contract.
- The wallet simulates the transaction and, under current conditions, the contract returns the deposit plus a negligible reward.
- The wallet presents the result as a balance increase or otherwise benign outcome.
- Before the victim’s transaction is executed, the attacker changes the relevant blockchain state.
- The confirmed transaction follows a different branch and redirects the victim’s funds to the attacker.
This is a blockchain version of a time-of-check-to-time-of-use, or TOCTOU, vulnerability. The simulation itself may be technically correct. The problem is that its assumptions no longer hold when execution occurs.
Six Ways to Manipulate the Result
The researchers identify six contract types that can produce different simulated and on-chain outcomes.
Storage-controlled contracts
These contracts store information — such as a blacklist — in their own persistent state. During simulation, the victim is not on the blacklist, so the contract appears to return the deposit with a small reward. The attacker then submits a separate transaction that adds the victim’s address. When the victim’s transaction executes, the funds go to the attacker. This approach gives relatively deterministic control once the state-changing transaction lands first.
External-state-controlled contracts
The logic is similar, but the blacklist or control value is kept in a different smart contract. The phishing contract queries that external contract to decide where the money should go. The state observed during simulation can still change before execution.
Gas-controlled contracts
A contract may branch based on the transaction’s gas limit or remaining gas. The simulator might use an estimated or default limit, while the phishing site prepares a different value. Under the simulator’s settings the contract returns the user’s money; under the submitted settings it sends funds to the attacker.
Gas-price-controlled contracts
The contract can also examine the gas price. A simulator and the real transaction may use different values, especially when a wallet automatically adjusts fees. The two executions can therefore follow different paths.
Block-number and timestamp contracts
A phishing site can include a reference block number or timestamp. During immediate simulation the condition is true and the result looks safe. By the time validators include the transaction, several blocks may have passed, the comparison changes, and the contract selects the malicious branch.
In the wild, the researchers observed storage-, gas-, and timestamp-controlled contracts. Gas-controlled contracts were by far the most common. Storage-controlled contracts generated most of the measured losses.
Detecting Malicious Contracts with SimGuard
Finding these contracts is difficult because malicious developers rarely publish verified source code. The paper introduces SimGuard, which combines static and dynamic analysis of EVM bytecode.
First it symbolically executes a contract and searches for a characteristic transfer pattern: one branch sends the caller’s deposit back with an extra amount, another sends the deposit to an external address, and the choice depends on mutable state or a dynamic transaction or block property. Suspicious contracts are then tested in a local environment to confirm that both the “profit” path and the drain path can be triggered.
On the researchers’ evaluation dataset, SimGuard detected 43 of 44 malicious samples and produced no false positives among 162,975 benign contracts. Those results should be read in context: some malicious samples were generated for testing because few labeled real-world examples existed for several attack categories. Heavy obfuscation can still defeat static analysis.
The Scale of the Campaign
Applied across four EVM-compatible networks, SimGuard reported 4,224 phishing contracts: 480 on Ethereum, 293 on BNB Smart Chain, 3,136 on Avalanche, and 315 on Polygon. About 99.2% were gas-controlled. Avalanche contained nearly three-quarters of all detected contracts, but contract count did not match financial impact.
Ethereum accounted for about .19 million — 91.5% — of the estimated .48 million in total losses. The study identified 6,223 victim transactions from 5,742 addresses. Storage-controlled contracts represented only a small share of deployments but generated about .97 million, or 85% of measured losses. One timestamp-controlled contract reportedly collected more than 5,000.
The largest Ethereum cluster included 268 contracts and accounted for about .88 million — around 83% of all losses measured across the four networks. One contract alone received more than .2 million through 164 victim transactions. The largest observed single-transaction loss was 143.4 ETH, worth about 7,000 at the time.
The authors treat their loss figures as an upper bound. An attacker testing a contract through an unlinked address could be counted as a victim. Return-on-investment estimates include on-chain costs but exclude domains, advertising, infrastructure, and money laundering.
Why Wallet Interfaces Make the Attack Worse
The contracts are only part of the problem. How wallets present simulations can make misleading results look trustworthy.
The researchers tested 11 wallets with a transaction that sent the account’s full balance to a contract and returned only one wei. Several wallets displayed the tiny return as a positive balance change without clearly communicating the much larger outgoing transfer. A user could interpret “+<0.000001 ETH” as a net gain, even though the returned amount does not cover network fees.
Two interface issues stand out:
- Wallets may emphasize incoming funds without clearly presenting the net result.
- Simulation screens may omit the exact native-currency amount being sent to the contract.
A green or positive-looking preview can therefore provide false confidence. For most users, a wallet simulation carries an implicit promise that the transaction has been evaluated comprehensively. In reality, it is only a prediction based on temporary state and specific execution parameters.
What Wallets — and Users — Can Do
The paper recommends making simulations sensitive to conditions that can change before execution. Simulation services should re-run a transaction if relevant contract state changes, use the exact gas limit and gas price from the request, and test block-number or timestamp-dependent logic under both current and plausible future values. Wallets should also display the exact amount sent, received, and paid in fees, and warn when execution depends on mutable environmental values.
For users, the practical rule is simpler. Be suspicious of transactions initiated by giveaways, airdrops, or “free crypto” campaigns — even when the wallet shows a positive result. Check the exact amount leaving the wallet, not only the highlighted incoming change. If a preview depends on timing, gas settings, or a contract that can be updated between simulation and confirmation, treat that as a warning rather than a green light.
If you are moving funds from self-custody toward an exchange or another counterparty, a simulation preview is not a substitute for understanding where the transaction sends value. Tools that screen wallet history and ownership still matter for compliance, but they do not replace careful reading of the signing screen itself.
The Broader Lesson
Transaction simulation remains a useful security feature. The mistake is treating it as a guarantee.
A preview answers a narrow question: What would this transaction do under the simulator’s current assumptions? It does not necessarily answer the more important one: What will happen when the network executes it?
In adversarial systems, previews can become part of the deception. The next generation of wallet security must verify not only what a transaction appears to do now, but also whether its outcome can change before it reaches the blockchain.
Based on the preprint “Blockchain Transaction Simulation Phishing” by Xiaocan Wang et al. Statistics and conclusions have not necessarily undergone peer review.
![Integrating Compliance Into Your Crypto Strategy [Step-by-Step]](/images/blog/integrating-compliance-into-your-crypto-strategy.jpg)
