A top-tier MEV bot that had long preyed on ordinary Ethereum traders eventually fell into a custom-made $7.5 million trap. On June 21, Jaredfromsubway.eth, a well-known sandwich arbitrage bot on Ethereum, was attacked, with assets including WETH and USDC drained from its address. Initial estimates put losses at over $7.5 million (though disclosed loss figures still vary).
Notably, the attack did not involve private key leaks or traditional smart contract vulnerabilities. Instead, the attacker deployed a large number of fake tokens, liquidity pools, and auxiliary contracts in advance, packaging them as potentially profitable trading paths. The bot, during automated execution, was tricked into granting an ERC-20 Approval to a malicious contract, which then "legally" transferred the MEV bot's assets. As of writing, Jaredfromsubway.eth has publicly appealed to the attacker on-chain, offering a 50% white-hat bounty if 2,150 ETH are returned within 48 hours, and threatening all available legal and law enforcement measures otherwise.
Attack Method: A Long-Term Hunt Targeting Trading Logic
A close review reveals this was not a random vulnerability but a long-term hunt tailored to Jaredfromsubway.eth's trading logic. The bot operates on sandwich attacks: detecting a pending on-chain transaction, buying before the user to drive up the price, then selling immediately after the user executes at a worse price, pocketing the spread. This strategy requires the bot to continuously scan on-chain transactions, quickly judge arbitrage opportunities, and organize trading paths involving various tokens and contracts. Speed and coverage directly amplify profit opportunities — and that became the breakthrough point.
Post-incident analysis shows the attacker did not directly attack the bot's fund contract but spent weeks constructing a seemingly profitable trading environment. The entire attack targeted the bot's operational characteristics: first creating an environment that matched its profit criteria, then leveraging its automated execution mechanism to make the system voluntarily hand over asset-calling rights. This explains why even highly specialized MEV bots can fall prey — they know how to calculate spreads, gas costs, and transaction ordering, but may not fully verify every new contract. From this perspective, ordinary users "confirm without understanding," while automated bots "execute without confirming." Both share the same underlying risk: treating approval as a routine step without realizing its hidden danger.
Approval Mechanism: DeFi's Foundation and Hidden Risk
In Ethereum and EVM-compatible chains, the ERC-20 Approve function is a fundamental design. Direct transfers usually use transfer, not Approve. Approval is only needed when interacting with smart contracts like DEXes, lending protocols, staking, or adding liquidity. For example, swapping USDT for ETH on Uniswap requires first approving Uniswap's contract to spend a specified amount of USDT from the user's wallet. Only after approval can the contract use transferFrom to call the tokens, enabling the swap. Approval itself is not a vulnerability; it's essential for DeFi to function. However, it resembles auto-payment permissions: the user doesn't hand over passwords but allows the merchant to deduct within agreed limits. As long as the approval remains valid, subsequent deductions require no further confirmation.
This creates several issues:
- Unlimited Approvals: Many DApps request a very large allowance (the so-called "unlimited approval"). A user intending to spend 100 USDC might approve the contract to spend their entire USDC balance. If that approval is not revoked, even if the wallet currently holds few assets, future USDC deposits can still be affected.
- Approvals Do Not Auto-Expire: Users often confuse "disconnecting wallet" with "revoking approvals." Disconnecting only prevents the webpage from reading the wallet's state; it does not alter the on-chain Approval. Closing the webpage, deleting the DApp, clearing browser cache, or even switching wallet apps does not invalidate existing approvals.
- Even Legitimate Contracts Can Become Dangerous: A user might approve a protocol that is safe at the time, but later the contract could be exploited, admin keys leaked, upgrade logic replaced, or associated router contracts compromised. The user's assets remain in their address, but another contract has ongoing permission to call them. Approval risk is not just "did I authorize a bad actor?" but also "will the authorized entity cause problems later?"
Mitigating Approval Risks: Joint Efforts from Users and Wallets
The simplest advice is "avoid unlimited approvals." But in real DeFi usage, completely rejecting approvals is impractical, since they are the basic way to interact with contracts. What needs to change is treating Approval as a one-time confirmation — it should be part of ongoing permission management. For ordinary users, several habits are essential:
- Principle of Least Privilege: When a wallet prompts for approval, set the allowance close to the actual amount needed for the interaction. If you intend to use 100 USDT, approve approximately 100 USDT, not an unlimited amount.
- Separate Storage and Interaction Wallets: Avoid frequently connecting wallets holding large long-term assets to unfamiliar DApps. Use a separate wallet for airdrops, mints, new projects, and high-risk DeFi interactions, limiting potential losses to a smaller pool.
- Regularly Check and Revoke Unused Approvals: Tools like Revoke.cash, or wallet functions like imToken's "Token Function" → "Approval Management," allow users to view all approvals for an address (token, spender, allowance) and revoke those no longer needed or from unknown sources.
Relying solely on user awareness and periodic checks is insufficient, as most users cannot distinguish a contract address's owner or judge whether an allowance is reasonable. As the first line of defense into Web3, wallets must provide proactive protection. For instance, imToken marks or blocks identified risk tokens, addresses, and DApps. It also provides specific risk warnings when users approve tokens to plain external accounts or transfer directly to contract addresses. These warnings cannot replace user judgment but add a necessary safety buffer before signing. Additionally, imToken performs structured parsing and readable presentation of signing content in critical steps like DApp login, transfers, token swaps, and approvals, helping users understand what they are consenting to before confirmation. As standards like ERC-7730 Clear Signing advance, this "What You See Is What You Sign" readability is expected to evolve from a single wallet's feature into an industry standard shared among wallets, DApps, and smart contracts.
In summary, private keys determine who owns an account; Approvals determine who can also move assets within it — both are equally critical. Wallet security cannot stop at "private key leaks"; it requires joint efforts from users and wallets. Users must scrutinize recipients and allowances before approving, and clean up unused permissions after interactions. Wallets must make hidden contract-level permissions more visible, understandable, and easier to limit and revoke. After all, the real danger may not be a transfer that just happened, but an approval long forgotten yet still active.