A sophisticated MEV bot that routinely front-runs ordinary traders on Ethereum has itself fallen victim to a $7.5 million exploit, highlighting how token approvals remain one of the most overlooked risks on-chain. On June 21, the well-known sandwich bot Jaredfromsubway.eth was drained of WETH, USDC and other assets after the attacker tricked it into granting ERC-20 approvals to a malicious contract. The loss is estimated at over $7.5 million, though public figures vary.
How the attack worked
The attacker did not steal private keys or exploit a traditional smart contract bug. Instead, they spent weeks constructing a fake trading environment designed to bait the bot's automated logic. First, they deployed a series of fake tokens and liquidity pools that mimicked real assets like WETH, USDC and USDT. The bot's scanning system mistook these for legitimate trading paths.
Over time, the attacker gradually earned the bot's trust. During early test trades, the bot granted approvals that were used normally. But the attacker then adjusted the contract logic so that some approvals were never consumed or reset after trades. Those lingering approvals remained active. Finally, the attacker called the still-valid approval limits to transfer real WETH, USDC and USDT out of the bot's contract.
The entire scheme exploited the bot's core design: it was optimized for speed and coverage, not for verifying every new contract it interacted with. The bot could calculate price spreads and gas costs, but it could not distinguish a genuine opportunity from a carefully crafted honeypot.
Why approvals are a blind spot
In Ethereum and EVM-compatible chains, the ERC-20 `approve` function is fundamental to DeFi. When a user swaps tokens on Uniswap, for example, the exchange contract cannot directly take tokens from the user's wallet. The user must first call `approve` to authorize the contract to spend a specific amount. Once approved, the contract can use `transferFrom` to move the tokens.
Approval itself is not a vulnerability — it is essential for DeFi to function. But it creates risks similar to giving a merchant a recurring payment authorization. Many users grant unlimited approvals to save on gas fees, effectively allowing a contract to spend all of their tokens indefinitely. Disconnecting a wallet from a DApp does not revoke those on-chain approvals; only a separate transaction can do that. Even a legitimate contract can become dangerous if it is later compromised or upgraded maliciously.
Managing approval risk
The simplest advice is to avoid unlimited approvals. Users should follow the principle of least privilege, approving only the amount needed for a single transaction. Separating storage wallets from interaction wallets is also wise: keep large holdings in an address that rarely connects to unfamiliar DApps, and use a separate address for airdrops, mints and high-risk DeFi.
Regularly checking and revoking unused approvals is critical. Tools like Revoke.cash or the approval management feature in wallets such as imToken allow users to see which contracts have permission to spend their tokens and to revoke those permissions. Wallets are also improving security by flagging risky tokens and contracts, and by presenting approval requests in a readable format so users know exactly what they are signing.
Ultimately, private keys control who owns an account, but approvals control who can move the assets inside it. Both are equally important. The real danger is not always the transaction happening right now — it is the approval granted long ago that was never revoked.