JaredFromSubway's bot lost $7.5M to fake tokens. We had already flagged them.

One of the most profitable MEV bots on Ethereum - the one trading as jaredfromsubway.eth - just lost around $7.5M. And the interesting part is how.

It wasn't a contract exploit. No reentrancy, no bug in a DeFi protocol. It wasn't phishing either - no human signed anything. The bot approved its own robbery, because its automation was tricked into thinking it was about to feast on a juicy MEV opportunity.

We traced the whole thing on-chain. And then we noticed something: our own scanner had already flagged the bait tokens as fakes - up to a full day before the money moved.

How the trap works

ERC-20 has a two-step spend model. To let a contract move your tokens you first call approve(spender, amount), which creates an allowance. The spender can then call transferFrom(you, dest, amount) up to that allowance - and the allowance persists until it is used up or revoked. To save gas, bots and routers often approve type(uint256).max: an infinite, standing blank cheque.

That is the whole attack surface. The sequence:

1. The attacker deploys fake wrapper tokens (fWETH, fUSDC, fUSDT) and fake pools engineered to look like a juicy arbitrage.
2. To trade that "opportunity", the bot's own logic approves attacker-controlled helper contracts as spenders of its real WETH, USDC and USDT.
3. On the early transactions the attacker consumes those approvals immediately - everything looks profitable, nothing trips an alarm.
4. On later transactions the bot grants approvals that are never consumed or revoked - they sit there, dormant, as standing spend power.
5. Once enough allowances are stacked, the attacker calls transferFrom and pulls the real assets straight out of the bot.

The bot did exactly what it was built to do. Its strength - aggressive, automated profit-chasing that approves whatever a trade needs - became the hole.

What the chain shows

We pulled the transfers with our own RPC nodes and Etherscan. The receiving wallet is 0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0.

A funded, purpose-built account. It was first funded on Jun 7 with ~19.9 ETH from a throwaway wallet (0xe8b7e6...478703, two transactions of lifetime). It is also an EIP-7702 delegated account: its code points to a smart-account implementation at 0x63c0...ae32b, so a single signed action can run a batched, contract-like routine - convenient when you need to harvest many approvals and fire the drain cleanly.

The drain. Moving directly from the bot contract (0x1f2f10...df387) to the attacker, on Jun 20 between 18:49 and 18:56 UTC, we count:

Asset	Pulled directly from the bot
USDT	2,035,760
USDC	2,870,573
WETH	1,474.58

Routed through real infrastructure - the Uniswap V4 PoolManager and CoW Protocol's settlement contract - to swap the fakes for the real reserves.

The bait. The attacker's fake tokens are exactly what the reports described, plus a few extras:

fWETH  0x6bea01ec24cd029b1ed0898ab30c8f620c8e8c4e   "Wrapped Ether"
fUSDC  0xd370f4e528d83f9941ff2803685552660af7c238   "USD Coin"
fUSDT  0x86070300d54c335717f87dcb11c6515c9a27688e   "Tether USD"
fCAP   0xf2ae7acf310812fb33451610a97020ef961f0521

(homoglyph spoofs of ETH described in the original post.)

The part we did not expect

Impersonation tokens are our bread and butter. We score every new ERC-20 that hits mainnet on 100+ on-chain signals. So we checked the bait against our own API - and the bot was interacting with tokens we had already scored as high-risk fakes, before the drain:

Bait token	RektRadar verdict	Scored at	vs. the drain
fWETH	70/100 - impersonates_major_token	Jun 19, 17:38	~25h earlier
fUSDC	70/100 - impersonates_major_token	Jun 20, 00:38	~18h earlier
fUSDT	70/100 - impersonates_major_token	Jun 20, 00:48	~18h earlier

The flags that fired are exactly the ones you'd want: name_mimics_known_token, impersonates_major_token, deploys_scam_bytecode, mass_deployer, multi_flag_rug_setup. A token literally named "Wrapped Ether" with symbol fWETH, unverified, from a mass deployer pushing known scam bytecode, is not a subtle case.

To be clear: a risk score doesn't reach into a bot and stop it from signing. The bot's flaw was its own approval logic. But the bait was not invisible - it was an off-the-shelf impersonation pattern that an independent scanner had already caught and labelled. The information needed to refuse the interaction existed, on-chain, in advance.

The takeaways

• Revoke approvals, and never approve infinity. A standing type(uint256).max allowance to an unknown spender is a blank cheque that survives until someone cashes it. Approve exact amounts, or use scoped/expiring approvals (Permit2-style).
• "Is this the real WETH?" is a question, not an assumption. Most of the loss rode on the bot treating fWETH/fUSDC/fUSDT as the assets they impersonate. Impersonation is one of the oldest scam-token patterns on Ethereum, and it is machine-checkable.
• Automation needs the same guardrails as humans. A bot making millions still has to ask whether the token in front of it is a fake. That check is a single API call.

We run that check on every new token on Ethereum. You can run it on any contract at rektradar.io, or wire it into your own bot via the API.

All addresses and amounts above are verifiable on-chain. The ~$7.5M net figure is from public reporting; the per-asset amounts are the transfers we traced directly from the bot contract to the attacker.