On June 21, Jaredfromsubway.eth, a famous sandwich arbitrage bot on Ethereum, was attacked, resulting in the loss of WETH, USDC, and other assets totaling over $7.5 million. Notably, the attack did not involve private key leakage nor traditional smart contract vulnerabilities. Instead, the attacker executed a meticulously crafted trap: deploying numerous fake tokens, liquidity pools, and auxiliary contracts to create seemingly profitable trading paths. The bot was tricked into granting ERC-20 approval to a malicious contract during automated execution, allowing the attacker to legitimately transfer assets.
Premeditated Trap: Exploiting Bot Trading Logic
Jaredfromsubway.eth is one of the most active sandwich attack bots on Ethereum. Its strategy involves scanning pending transactions, buying ahead of users to drive up prices, then selling after the user trades at a worse price. To maximize profit, the bot constantly evaluates arbitrage opportunities and constructs transaction paths involving various tokens and contracts. The attacker spent weeks building a deceptive environment: first creating conditions that appeared profitable to the bot, then leveraging its automated execution mechanism to make the bot actively grant asset approval to the malicious contract.
Post-mortem analysis shows the attacker did not directly attack the bot's fund contract. Instead, they designed a highly customized trap. This explains why even a professional MEV bot fell for it—it excels at calculating spreads, gas costs, and ordering, but may not verify the identity of newly encountered contracts. Regular users often approve without fully understanding, while automated bots execute without confirming. Both share the same underlying risk: treating approval as a routine step while underestimating its danger.
Approval Mechanism: DeFi's Foundation and Hidden Bomb
In the ERC-20 standard on Ethereum and EVM-compatible chains, Approve is a fundamental design. When users interact with DEXs, lending platforms, or staking contracts, they must first approve a contract to spend a specified amount of tokens. After approval, the contract can transfer tokens via transferFrom. Approval itself is not a bug; it is essential for DeFi operations. However, it resembles an auto-debit permission—once granted, subsequent deductions require no further confirmation—leading to several core issues.
First, unlimited approval: to reduce gas costs and operational friction, many DApps request extremely high allowances (often "infinite approval"). A user intending to trade 100 USDC might unknowingly allow the contract to spend their entire USDC balance. Second, approval does not automatically expire when disconnecting from a DApp: many confuse "disconnecting wallet" with "revoking approval," but disconnection only prevents the website from reading the wallet; the on-chain approval remains active. Third, even legitimate contracts can become dangerous later: they might be attacked, have their admin keys leaked, or have their upgrade logic swapped. Although assets remain in the user's address, the contract still has permission to transfer them.
How to Mitigate Approval Risks? From User Habits to Wallet Products
The simplest advice is "avoid unlimited approvals." But completely refusing approval is impractical in DeFi. The real solution is to transform approval from a one-time action into continuous permission management. Users should adopt several habits: first, apply the principle of least privilege—set the approval amount close to the actual need instead of unlimited; second, separate storage wallets from interaction wallets—avoid connecting high-value addresses to unfamiliar DApps and use separate addresses for airdrops, mints, and high-risk contracts; third, regularly review and revoke unnecessary approvals using tools like Revoke.cash or imToken's approval management feature.
However, user awareness alone is insufficient. Wallets, as the first line of defense, must provide active protection. For example, imToken marks or blocks identified risky tokens, addresses, and DApps, and issues targeted warnings when users grant token permissions to external accounts or send assets directly to contract addresses. Additionally, imToken parses and displays signed data in a human-readable format during critical operations like DApp login, transfers, token swaps, and approvals. With the advancement of Clear Signing standards such as ERC-7730, "What You See Is What You Sign" readability may become an industry standard shared by wallets, DApps, and smart contracts.
Aftermath and Reflection
As of press time, Jaredfromsubway.eth has publicly messaged the attacker on-chain, offering to pay a 50% white-hat bounty if 2,150 ETH is returned within 48 hours, otherwise threatening legal and law enforcement actions. This incident underscores: private keys determine who owns an account, while approvals determine who can control assets within it. The real danger may not be the most recent transfer, but an approval granted long ago that remains valid. Both users and wallets need to work together—users must carefully check approval targets and amounts and clean up permissions promptly; wallets must make permissions more visible, understandable, and easily revocable.