The Fake Positive: How 4,224 Contracts Turned Wallet Previews Into Withdrawal Slips

Check the preview. Confirm the green checkmark. See the small "+0.02 ETH," decide it is profitable, and sign. Signed, sealed, drained. That is the operational pattern behind 5,742 victim addresses and approximately $3.48 million in historical losses. It is not a vulnerability in the Ethereum Virtual Machine. It is a class of malicious smart contracts purpose-built to lie to transaction simulation tools — the safety layer embedded in modern crypto wallets. A July 30 arXiv preprint, still awaiting peer review, catalogs 4,224 such simulation-phishing contracts across Ethereum, BNB Smart Chain, Avalanche, and Polygon. The authors ran SimGuard, a contract-bytecode detector, and tied those contracts to 6,223 victim transactions. Ethereum absorbed 91.5% of the losses. The largest inferred cluster alone accounts for roughly 83% of the cross-chain damage. Code does not lie. People do. But a contract with conditional branches is just human intent compiled into machine code, and this particular intent was theft dressed as a faucet. I have spent years dissecting token flows, and my first rule of wallet security remains the same: the interface is the attacker's front door. Every green "success" indicator is a promise the code did not necessarily make. The preprint's real contribution is forensic: it demonstrates how that promise is mechanically broken, and quantifies the damage. Transaction simulation was supposed to end the age of blind signing. Before simulation, users approved transactions the way a person signs a contract in a dark room — no lights, no copy, just fear and a prayer. The wallet vendors promised clarity: execute the proposed bytes against a local snapshot of chain state, display the expected result, label it safe. It was a beautiful idea. It was also a static analysis of a dynamic adversary. Here is the assumption at the heart of every simulator, from MetaMask to Rabby to Phantom: the state you simulate against is the state the transaction will actually land on. That assumption was never guaranteed. In a multi-block MEV world, state changes between simulation and inclusion are the rule, not the exception. Legitimate protocols deal with this because their logic is public and audited. Malicious actors deal with it by writing code specifically to exploit the assumption. It took the wallet industry years to understand that blocklists are not a firewall. The first generation of drainers cloned dApps and begged users to approve arbitrary token allowances. The second generation moved to permit signatures, collapsing two transactions into one and eliminating the approval step that triggered hesitation. This third generation does not impersonate a dApp at all. The malicious contract presents itself as a profitable interaction, and the wallet's own simulation engine vouches for it. The phishing contract is simultaneously the bait, the validator, and the withdrawer. That is efficiency. The paper breaks the attack into three structural variants, and understanding them is understanding why the simulation race is unwinnable. Storage-control contracts are the simplest and the most devious. The contract has two execution paths. During simulation, the code runs the path that returns the user's deposit plus a small, innocuous reward. The preview paints a positive picture: your balance increases, the interaction is profitable, sign here. The attack happens between the preview and the final inclusion. The attacker mutates the contract's state — often by blacklisting the user's address, which flips a storage slot governing which branch executes. When the transaction finally lands, the high-level call is marked successful, but the deposit is routed to an attacker-controlled address. The user signed a withdrawal slip disguised as yield. Timestamp-based contracts exploit the same gap with time instead of storage. Simulators typically execute against the current block timestamp. An attacker can set a threshold: if block.timestamp is earlier than T, return the deposit plus a reward; if later, transfer the deposit to the attacker. The user previews the transaction before T and signs. The transaction lands after T. The conditional branch flips. No pre-signed state mutation is required, which makes it harder for a detector to catch by monitoring storage changes. Gas-control contracts target a more subtle mechanic. Simulation backends and real wallet transactions often run under different gas limits. A contract can branch on gasleft(), showing one face to the simulator and another to the executor. If the user approves a transaction using an elevated gas limit, the executed branch can be the malicious one. In this variant, the user is not even the victim of a state race; the victim unknowingly carries the wrong gas parameters into a trap. I have seen this pattern in my own audits. The first sign of a malicious contract is rarely an obvious external call to an EOA. It is a strange success path. It is a function that returns the deposit in a simulation but reverts or redirects in a live call. The difference is in the branches, and the branches are where honesty ends. The evidence is substantial, even if the report's own limits are honest. SimGuard identified 4,224 contracts across four chains. The paper links them to 6,223 victim transactions and 5,742 victim addresses. The $3.48 million figure is called an upper bound by the authors because some attacker test activity could have been misclassified as victim transactions. More than nine in ten lost dollars were on Ethereum, and the largest inferred cluster accounts for 83% of the cross-chain total. This is not distributed amateurism; this is industrialized phishing with smart contract infrastructure. The most damning finding is the controlled test. The researchers sent an account's entire balance to a contract that returned as little as 1 wei — the smallest unit of ETH. Several of the wallets' transaction previews displayed a positive estimated balance change. Most did not clearly show the full outgoing amount. A user, watching that preview, would see a tiny, almost symbolic profit. That is the signature move: anchor the user's attention to the negligible reward so they never look at the principal leaving their wallet. Check the supply schedule. Always. The reward is one wei of bait; the principal is the entire balance. Yield, even a single wei of yield, is a tax on ignorance, and the tax rate here was the deposit. There is a reason the researchers chose one wei as the refund. In behavioral experiments I have run with portfolio managers, small positive deltas are disproportionately effective at driving action. A gain of a few cents reads as a reward; a loss of hundreds reads as a risk. The anchoring mechanism fixates on the incentive and compresses the exposure into background noise. The wallet preview compounds this bias when it presents a single net figure, because that figure is exactly what the attacker wants the user to see. The gross outflow is not hidden technically; it is hidden perceptually. Still, intellectual discipline requires identifying what the paper does not prove. It is not peer reviewed. It reports inconsistent figures for the Avalanche contract count and conflicting endpoints for the observation period. The paper could not identify which wallet versions, settings, or simulation backends the victims used. Its detector evaluation covered only 44 contracts, 30 of which were generated with Gemini. The linked code-and-data repository returned an HTTP 401 when checked, meaning no outside researcher can yet independently reproduce the measurements. Independent verification matters. I have burned enough hours on exotic exploit claims to know that the largest numbers in security research often come with asterisks. The aggregate figures here remain the authors' findings, not an independently confirmed reality. What is confirmable on-chain is narrower: a January 8, 2025 Etherscan transaction records a Claim() call moving roughly 143.45 ETH through a contract that Etherscan accurately labels phishing. The transfer happened. The question the paper cannot answer is what the user's wallet displayed before the signature. The wallet industry's current countermeasure is a real-time intelligence network. MetaMask and Phantom have been sharing phishing-block feeds to identify drainers and stop them before users sign. That helps with known addresses and established clusters. It does nothing here. A fresh simulation-phishing contract has no reputation score, no manual report, and no prior victims to flag it. The user cannot report what they never understood, and the simulator has already vouched for the contract. Address reputation treats the symptom; the preprint describes a disease of interface trust. This is where analysis shifts from forensic to structural. The authors' recommendations are sensible: re-run simulations when relevant state or gas fields change, use the actual request's gas limit and price, and test current and future block-number and timestamp inputs. But re-running a simulation is a race you ultimately lose. The attacker needs one window between your last check and the transaction's inclusion. If the contract is storage-controlled, your second clean simulation can be invalidated by a state change three seconds later. Simulation is always playing catch-up to an adversary who moves the goalposts asynchronously. The more honest fix is what the researchers hint at in their UI findings. Show the gross amount leaving the wallet, not just the net balance change. When a contract returning 1 wei displays as a positive interaction, the problem is not the attacker's cleverness. It is a user interface that presents net deltas as the primary signal. The negligible refund is mistaken for profit because the gross outflow is hidden in a dropdown. That is a design risk, not a cryptographic one. The contrarian read is uncomfortable: the most effective defense is not better detection or better simulation. It is a more adversarial user interface. Every simulation result should be presented as provisional. Every interaction with an unverified, state-modifying contract should demand a gross-outflow acknowledgment. We have built an entire industry of detectors — SimGuard is only the latest — but detectors are reactive by nature. By the time a detector identifies a cluster, the cluster has already harvested. The asymmetry is the real market structure of crypto crime. The paper describes historical activity, not a live attack wave. That is a relief, but it is a small one. The same pattern will resurface in the next token launch, the next fake airdrop, the next refund notification. The user will never sign a document that says "I agree to lose my entire balance." The user will sign a contract that previews a positive return. So the forward-looking question is not whether wallet vendors add SimGuard-like detection to their pipelines. It is whether they rebuild the preview model from first principles: gross outflow first, net balance second, and the word "prediction" visible every time a user signs. The supply schedule of trust in this industry is dangerously low, and the next bull run will only make the 1-wei promise more credible. When your wallet tells you that you are about to make money, ask the only question that matters: what exactly is leaving your wallet so that the estimate looks positive? If the interface cannot answer that in plain sight, do not sign. The green checkmark is not a proof. It is a guess, compiled by an adversary.