{"id":"3c60f86e-9445-489a-84b0-ebc670a97cbe","arxiv_id":"2607.28747","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Attackers craft smart contracts that fool wallet transaction previews into showing a profit, then steal the deposited funds on-chain; the paper detects 4,224 such contracts and $3.48M in losses.","lead":"Crypto wallet transaction previews can be tricked: phishers write contracts that look profitable during simulation but redirect funds to attackers on the real blockchain. A new detector, SimGuard, found over 4,000 such contracts on four chains, with more than 5,700 victims and about $3.48M lost.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Gas-control, the dominant detected variant (99.2%), is not shown to fool any real wallet: the paper never tests simulators with a high-gas-limit transaction, so the core mechanism for the largest claim is unverified.","rationale":"The reader's weakest assumption focused on victim transaction identification, which affects the quantitative loss/victim counts but not the existence of the attack. My concern is more load-bearing: the most prevalent phishing variant (Gas-control) relies on an unverified behavioral assumption about wallet simulators. If this assumption fails, the thousands of detected Gas-control contracts are not demonstrated to be transaction simulation phishing; they may be ordinary honeypots that any accurate simulator would expose. The paper's own wallet tests do not cover this case, and Section 3.2 explicitly hedges with 'may.' This does not invalidate the storage-control case study (143.4 ETH loss) or the misleading-simulation UI findings, so the core claim remains plausible, but the scale and generality of the attack hinge on the gas-limit assumption. The verdict should remain CONDITIONAL, but for a different, more fundamental reason than the reader's victim-identification concern.","tokens_in":21035,"tokens_out":5576,"duration_ms":59871,"concrete_test":"Deploy a Gas-control phishing contract (e.g., with branch condition tx.gaslimit > 5M) on a testnet. In each of the 11 wallets tested in the paper (MetaMask, Rabby, Phantom, etc.), construct a transaction with gas limit 6M and observe the simulation preview. If the preview shows funds returned (profit), the simulator used a lower default gas limit — confirming the attack. If the preview shows funds sent to the attacker address (drain), the Gas-control variant does not bypass that wallet's simulation. Repeat for Gasprice-control and, if feasible, block.number/timestamp-control by comparing simulator parameters against the transaction's specified fields.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The paper's central claim is that transaction simulation phishing bypasses wallet defenses. The most common detected type is Gas-control (4,192 of 4,224 contracts, 99.2%; Table 2). Section 3.2 states that 'the transaction simulator may use a smaller default Gas limit to simulate the transaction, producing a profitable outcome.' This 'may' is the entire basis for classifying these thousands of contracts as simulation-phishing. The wallet UI evaluation in Section 6.1 only tests a transaction to a contract that returns 1 wei — it does not test any gas- or gasprice-dependent contract. If a simulator uses the transaction's own gas limit (as a faithful simulation should), the simulated outcome would match the on-chain draining branch: the user would see funds leaving, not a profit, and the attack would not be effective. No evidence is provided that any of the 11 tested wallets uses a different gas limit or gas price than that specified in the transaction. Without this, the dominant variant may simply be a set of honeypot contracts that fail against transaction simulation, undermining the scale and novelty of the reported attack. The victim-quantification issue (Section 5.3, Section 6.3) is a real but secondary concern; it only affects the upper-bound loss estimates, whereas the Gas-control assumption is load-bearing for the very existence of the majority of the claimed attack instances.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":21354,"tokens_out":7232,"duration_ms":81305,"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":[{"comment":"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","section":"Section 3.2, Table 2, Section 6.1"},{"comment":"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.","section":"Section 4.2, Table 1"},{"comment":"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.","section":"Section 5.3, Section 6.3"}],"minor_comments":[{"comment":"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.","section":"Section 2.3"},{"comment":"In the External-control paragraph, 'stotage-control' is a typo for 'storage-control.'","section":"Section 3.2"},{"comment":"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.","section":"Table 2"},{"comment":"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.","section":"Section 6.1 / Appendix C"},{"comment":"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.","section":"Section 5.3"}],"recommendation":"major_revision","confidential_remarks":"The core idea is interesting and the case study for storage-control phishing is compelling, but the scale claims hinge on Gas-control, whose efficacy against real wallet simulators is not demonstrated. If the authors can show with actual wallet simulators (or at least the simulators' documented behavior) that the gas limit used in simulation differs from the transaction's gas limit, the paper would be much stronger. Otherwise, narrowing the claims to the empirically supported storage-control and timestamp-control variants would make the contribution honest but much smaller. The circular ground-truth and the victim-heuristic issues are fixable with additional analysis and reporting. I would welcome a revised version that addresses these points."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The headline is: the storage-control attack is real and well-documented, but the paper's large numbers rest on a gas-control variant that no one has actually seen defeat a wallet simulation. That's the main thing to know before citing the 4,000+ contracts or $3.48M.\n\nWhat's genuinely new: this is the first systematic treatment of transaction simulation phishing. The taxonomy is sensible (six classes based on which dynamic variable controls the branch), and the concrete case study—143.4 ETH lost in a single transaction, attacker front-runs with a blacklist—is convincing. The wallet UI tests show a real problem: most wallets display a misleading balance change when the contract returns 1 wei, and they don't show the exact amount being transferred. That finding alone is worth something. The detection tool SimGuard is a reasonable engineering contribution, and they've open-sourced it.\n\nNow the soft spots. The stress-test concern is legitimate. Gas-control contracts make up 99.2% of detections (4,192 of 4,224). The attack logic depends on the wallet's simulator using a smaller default gas limit than the transaction specifies. The paper never tests this. None of the 11 wallet tests involve a gas-dependent contract; they only used a storage-control contract that returns 1 wei. So we have no evidence that any real wallet would show a profitable outcome for gas-control. If simulators actually respect the transaction's gas limit, then those 4,192 contracts are just honeypots that fail against simulation, and the \"largest variant\" of the claimed attack doesn't exist. The paper itself says \"may use a smaller default Gas limit\"—that's a hypothesis, not a result. This needs a dedicated experiment before the scale claim is credible.\n\nThe secondary issues are real but softer. The ground truth includes 30 Gemini-generated contracts built from the same taxonomy the detector is designed to recognize—this inflates recall. The victim/loss quantification uses the heuristic that \"funds immediately moved to another address\" equals a loss; the authors properly flag this as an upper bound in Section 6.3, but it still makes the exact victim and dollar figures fragile.\n\nWhere this lands: the storage-control and timestamp-control attacks are demonstrated, and together they account for the majority of the dollar losses (storage alone is 85%). So the core \"transaction simulation can be turned into phishing\" message likely survives. But the paper needs to (1) test wallets against gas- and gasprice-dependent contracts, and (2) provide independent ground truth for the detector, before the 4,000+ contract scale is accepted.\n\nWho should read this: people working on wallet security, blockchain defenses, or deception-resistant UI design. It deserves peer review—the topic is important and the storage-control result is real—but it needs significant revision to justify the sweeping claims.\n\nMy recommendation: send it to a serious venue, but with an explicit request to verify the gas-control mechanism or drop the unverified majority from the headline numbers.","headline":"Real storage-control attack, but the dominant gas-control variant is unverified — the big scale numbers overreach.","tokens_in":21842,"tokens_out":3407,"would_cite":true,"duration_ms":35544,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Crypto wallets' transaction previews can be turned into a phishing tool that has already stolen $3.48 million.","keywords":["transaction simulation phishing","smart contract security","crypto wallet","EVM","TOCTOU","phishing detection","blockchain measurement","SimGuard"],"falsifier":"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.","tokens_in":20902,"feed_emoji":"🎣","tokens_out":6863,"duration_ms":68026,"temperature":0.7,"pith_summary":"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.","feed_headline":"Phishing contracts trick wallet simulators, steal $3.48M","feed_subtitle":"Over 4,000 malicious contracts fool wallet previews on four blockchains; losses total about $3.48M.","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["Wallet previews fooled by state-switching phishing contracts","Simulation phishing: wallets show profit, then drain funds","$3.48M stolen via wallet preview trickery","4,000 contracts exploit wallet simulators, hit 5,700 victims","New phishing uses wallet's safety feature against it"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Wallet previews fooled by state-switching phishing contracts","Simulation phishing: wallets show profit, then drain funds","$3.48M stolen via wallet preview trickery","4,000 contracts exploit wallet simulators, hit 5,700 victims","New phishing uses wallet's safety feature against it"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000227,"raw_usage":{"total_tokens":1331,"prompt_tokens":788,"completion_tokens":543,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":532,"completion_tokens_details":{"reasoning_tokens":461}},"tokens_in":532,"tokens_out":543,"duration_ms":6089,"temperature":1.0,"reasoning_tokens":461,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T00:30:07.953260+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}