On June 21, the well-known Ethereum sandwich bot Jaredfromsubway.eth was attacked, resulting in the loss of WETH, USDC and other assets totaling over $7.5 million. Notably, the attack did not involve a private key compromise or a conventional smart contract exploit. Instead, it was a meticulously crafted trap.
Attackers deployed a series of fake tokens, liquidity pools and auxiliary contracts, packaging them as profitable trade routes to trick the bot into granting ERC-20 approvals to malicious contracts during automated execution. Since the approval was a legitimate on-chain operation, the attackers could "legally" drain the bot's assets. At press time, Jaredfromsubway.eth sent an on-chain message to the attacker, offering a 50% white-hat bounty if 2,150 ETH were returned within 48 hours, and threatening legal action otherwise.
Attack Mechanism: Long-term Hunt Targeting Automated Logic
Jaredfromsubway.eth has long been one of the most recognizable sandwich bots on Ethereum. The sandwich strategy involves detecting a pending transaction, buying ahead to push the price up, then selling immediately after the user trades at a worse price to capture the spread. This requires the bot to continuously scan the mempool and quickly compose multi-step trade paths. Attackers exploited this weakness by spending weeks constructing a seemingly profitable trading environment—matching the bot's preferred token pairs, liquidity depth, and gas settings—ultimately luring it into granting approvals in milliseconds.
Fundamentally, the attack targeted the fact that the bot focuses on spread calculations and gas costs but neglects thorough contract identity verification. A bot that knows how to calculate profits may not verify every new contract it interacts with. This reveals a common risk for both automated systems and ordinary users: the former executes without confirmation, while the latter clicks confirm without understanding.
The Approval Mechanism: DeFi Foundation and Hidden Dangers
In Ethereum and EVM-compatible chains, the ERC-20 Approve function is a low-level design. Simple transfers use transfer and don't involve approval. But in DEX, lending, staking and other smart contract scenarios, users must authorize the contract to spend tokens on their behalf. For example, swapping USDT for ETH on Uniswap requires an initial approval telling the system "I allow Uniswap to move X USDT from my wallet." Only after approval can the contract call transferFrom to execute the swap. Approval itself is not a vulnerability—it's essential for DeFi—but it introduces several risks:
First, infinite allowance. Many DApps default to requesting a very large cap (often called "unlimited approval"). A user may intend to trade just 100 USDC but authorize the contract to spend all their USDC now and in the future. As long as that approval remains, even if the wallet holds only a small amount at the time, future deposits could also be at risk. Second, approvals don't disappear when you leave a DApp. "Disconnecting" the wallet merely prevents the web page from reading the wallet; it does not revoke the on-chain approval. Closing the page, deleting the app, or clearing the browser cache won't invalidate it. Third, even a legitimate contract can become dangerous later—if the contract is exploited, the admin key is compromised, or the upgradeable logic is swapped, all past approvals to that contract can be abused.
User Security Practices: Least Privilege and Regular Checks
To mitigate approval risk, the first recommendation is to avoid infinite allowances. When a wallet prompts for approval, set a limit close to the actual amount needed for the current interaction. It's also wise to separate storage wallets from interaction wallets: use an address with large long-term holdings for storage only, and create separate wallets for airdrops, mints, new projects, and high-risk DeFi interactions to limit potential losses. Additionally, regularly review and revoke unused approvals. Tools like Revoke.cash, or the token page inside imToken (via "Token Function" → "Approval Management"), allow users to see which contracts have access to which tokens and revoke unnecessary ones.
Wallets, as the first line of defense for Web3 users, must provide active protection. For example, imToken flags or blocks identified risk tokens, addresses, and DApps. It also provides targeted risk warnings when users grant token permissions to external accounts or transfer tokens directly to contracts. imToken further parses and humanizes signing content during key steps—DApp login, transfers, swaps, and approvals—helping users understand what they are agreeing to before confirming, ensuring "What You See Is What You Sign." As standards like ERC-7730 (Clear Signing) advance, this readable presentation could become an industry-wide norm across wallets, DApps, and smart contracts.
In summary, the private key determines who owns the account; approval determines who can move assets from that account. Both are equally important. Wallet security cannot focus solely on private key protection; ongoing authorization management is essential. Users should check the recipient and allowance before approving, and clean up unused permissions after interactions. Wallets should make hidden permissions more visible, understandable, and easy to limit or revoke. The real danger may not be a recent transaction but an old, forgotten approval that remains valid forever.