Fake "MEV/Slippage Bot" Contracts: How the Drain Code Actually Works

How the Scam Is Set Up

The victim is shown a tutorial — usually a slick YouTube video with thousands of fake views and a seeded comment section — that walks them through a sequence that looks entirely plausible to someone who has heard of MEV without understanding how it actually works at an infrastructure level.

None of steps 1–4 are real. Step 5 is where every wei disappears.

What the Contract Actually Does

Stripped of fake comments, obfuscated helpers, and decorative imports, the malicious logic in start() reduces to exactly one operation:

function start() public payable {
    payable(owner).transfer(address(this).balance);
    // That's it. Every wei you sent goes to `owner`.
    // The hundred lines above this are theatre.
}

Every wei you deposited gets forwarded to a hardcoded address the scammer controls. The function accepts no arguments, performs no mempool analysis, executes no trades, and interacts with no DEX. The Uniswap interface imports, the checkLiquidity function, the fetchMempoolData helper — none of them are invoked during start(). They exist entirely to make the file look like it does something real.

How They Hide the Drain Address

Writing the scammer's address as a plain constant is the one thing that would make the scam obvious to any reviewer. So the address is never written plainly — it is split across multiple string variables and reassembled at runtime, typically using abi.encodePacked or inline assembly:

// Looks like innocent configuration variables...
string memory a = "0x7f";
string memory b = "3B9";
string memory c = "1a0";
// ... 5 more fragments scattered across helper functions

// Assembled at runtime — no static analysis tool catches this
address payable owner = parseAddr(concat(a, b, c, ...));

function start() public payable {
    payable(owner).transfer(address(this).balance);
}

This approach defeats three layers of casual review:

• Casual readers skimming the code see string variables with short hex values and assume they are configuration parameters, not a wallet address.
• Simple static analysis tools that flag hardcoded addresses do not catch an address assembled at runtime from concatenated fragments.
• People who "checked the source" on Etherscan but did not execute the assembly path or trace the full call graph of start() miss it entirely.

Additional Obfuscation Techniques Used in the Wild

The address splitting is the core trick, but production variants layer several additional techniques to make the code appear credible:

The "Defused" Variant Problem

Some versions of this template circulating in 2025–2026 have had the active drain replaced with a no-op — start() sets a variable and emits a log event but does not transfer funds. These exist for several reasons: the scammer may use them as a demonstration copy, as a base for affiliates to re-arm themselves, or simply because the template was forked and modified by someone who removed the drain but left all the scaffolding intact.

The key point is that a "defused" copy is not safe. The eight fragment functions are still present. The address assembly logic still works. Anyone who forks the contract and restores two lines of code re-arms the drain. If you find one of these contracts online and it "passes" a quick check because start() looks harmless, the underlying template is still a scam vehicle. Do not deploy it; do not fork it.

Red Flags Checklist

How to Check a Contract Before Funding It

1. Paste it into a local editor and trace every .transfer( and .call{value:. Find every place ETH can leave the contract. Trace exactly what address it goes to. If any transfer target is assembled at runtime from strings, that is your answer.
2. Check the owner variable. Open the constructor. If owner is not assigned to msg.sender — if it is hardcoded, computed, or assembled from fragments — you do not own this contract and you cannot recover funds sent to it.
3. Deploy to a testnet first. Deploy to Sepolia, fund it with test ETH, call start(), then open the Sepolia block explorer and check where the balance went. If it goes to an address you don't recognise, the mainnet version will do the same thing with real ETH.
4. Run a static analyser. Slither (slither contract.sol) will flag unprotected transfer calls, arbitrary send targets, and other high-severity issues immediately. It takes 30 seconds and is free.
5. Search the function names. Paste getMempoolShort or fetchMempoolData into a code search engine. You will find every known copy of this scam template within seconds. If your contract's source matches, walk away.

If You Have Already Been Drained

The ETH itself is almost certainly unrecoverable once transferred — the blockchain does not have a reversal mechanism, and by the time most victims discover what happened the funds have already been layered through DEX swaps or bridges. That said, the following actions are still worth taking:

AML and Compliance Implications

For compliance teams at exchanges, this scam class produces a recognisable on-chain footprint. Drain proceeds arrive at the scammer's address from multiple newly-deployed contracts over days to weeks — a pattern distinct from normal retail accumulation. The subsequent DEX swap and bridge activity follows the same post-exploit layering pattern documented in larger DeFi attack cases.

The QLabs Crypto AML platform applies behavioral detection rules for this pattern: full-balance transfers from newly-deployed contracts to unknown EOAs, flagged independently of whether the specific address has an existing blacklist entry. Because each fork of this scam template generates a fresh drain address, blacklist-only screening consistently misses the first wave of deposits. Behavioral typology detection does not.