The top-tier MEV robot lost $7.5 million: Is Approval the most overlooked lethal risk on-chain?

A long-time MEV bot preying on ordinary traders on Ethereum has ultimately fallen into a "custom-tailored" trap worth $7.5 million.

On June 21, the well-known Ethereum sandwich arbitrage bot Jaredfromsubway.eth was attacked. Assets including WETH and USDC in its address were transferred out, with preliminary losses estimated at over $7.5 million (though publicly disclosed loss figures still vary).

Interestingly, this attack did not involve a private key leak or exploit a traditional smart contract vulnerability. Instead, **the attacker pre-deployed a large number of fake tokens, liquidity pools, and auxiliary contracts, packaging them into transaction paths that appeared to offer arbitrage opportunities. This induced the bot to grant ERC-20 Approvals to malicious contracts during automated execution,** ultimately "legally" transferring the MEV bot's assets.

As of writing, Jaredfromsubway.eth has publicly appealed to the attacker via on-chain messages, stating it is willing to pay a 50% white-hat bounty if 2,150 ETH are returned within 48 hours. Otherwise, it will pursue all available legal and enforcement measures.

However, the fact that even a highly specialized, code-driven MEV bot can stumble over Approvals forces us to re-evaluate the dangers hidden within this "Approval" action we use daily.

1. A Reverse Hunt Specifically Designed for MEV Bots

A careful post-mortem of this attack reveals it was not a chance exploit but a long-term hunt designed around the trading logic of Jaredfromsubway.eth.

Jaredfromsubway.eth has long been one of the most famous sandwich arbitrage bots on Ethereum. Simply put, in a sandwich attack, the bot detects an upcoming on-chain transaction, buys before the user to drive the price up, waits for the user to trade at a worse price, and then immediately sells to profit from the spread.

Consequently, this strategy requires the bot to continuously scan on-chain transactions, quickly identify arbitrage opportunities, and construct transaction paths that call upon different tokens and contracts. The faster it is and the more assets and protocols it covers, the more opportunities it can capture.

But precisely this characteristic became the entry point for the attack.

According to post-event analysis, the attacker did not directly target the bot's fund contract. Instead, they spent weeks constructing a trading environment that appeared profitable:

• First, deploying a large number of fake tokens and liquidity pools. These tokens mimicked common assets like WETH, USDC, and USDT in name, interface, and transaction behavior, tricking the bot's automated identification system into thinking it had found legitimate trading paths.
• Second, gradually gaining the bot's trust. In early testing, the approvals granted by the bot were consumed during normal transactions. As the bot's system began repeatedly executing similar paths, the attacker adjusted the contract logic. Some approvals generated by the bot were no longer consumed and were not reset to zero after the trades ended, leaving these approvals active.
• Finally, the attacker centrally invoked the still-valid approval limits, draining the real WETH, USDC, and USDT from the bot's contract.

In essence, the entire attack targeted the operational characteristics of MEV bots: first create an environment that matches their profit-seeking rules, then exploit the mechanism for automated transaction execution to make the system voluntarily grant asset control rights.

This also explains why even highly sophisticated MEV bots fell victim.

They know how to calculate spreads, gas costs, and transaction ordering, but they may not thoroughly verify the identity of every new contract they interact with. From this perspective, **the problem for ordinary users is "confirming without understanding," while the problem for automated bots is "executing automatically without confirming."**

On the surface, they seem different, but the underlying risk is very similar: both treat Approval as a routine step before completing a transaction without clearly realizing the high potential danger.

2. Why is Approval Always Underestimated?

As is well known, the Approve function is a fundamental design in the ERC-20 standard for Ethereum and EVM-compatible chains.

However, when users make direct transfers in a wallet, they usually call the `transfer` function, which generally doesn't involve Approve. Approval is only needed when users interact with smart contracts, such as on DEXs, lending platforms, staking, or adding liquidity, where the contract needs to call tokens on their behalf.

For example, when swapping USDT for ETH on Uniswap, the Uniswap smart contract cannot directly take USDT from your wallet. You must first execute an Approve to tell the system, "I allow Uniswap to transfer X USDT from my wallet."

Once the approval is complete, the authorized contract can use `transferFrom` to call the user's USDT within the set limit, allowing the subsequent swap to proceed smoothly.

In other words, Approval itself is not a vulnerability; it's a crucial foundation for DeFi to function. However, the problem is somewhat similar to an auto-debit authorization: the user doesn't give their account password to the merchant, but they allow the merchant to deduct funds autonomously within an agreed range. As long as the authorization is valid, subsequent deductions don't require the user to enter their password or confirm each transaction. This naturally introduces certain risks.

First is the issue of infinite approval, where a single transaction becomes a long-term permission. To reduce the operations and gas costs of repeated approvals, many DApps request an extremely large approval limit by default, often called "unlimited approval."

A user might only intend to use 100 USDC for one transaction but authorize the contract to use all their USDC in the future. As long as this approval is not revoked, even if the user's wallet only held a small amount initially, any USDC deposited later could still be affected.

Second, approvals do not automatically disappear when you leave a DApp. Many users confuse "disconnecting the wallet" with "revoking approval." In reality, disconnecting only prevents the webpage from reading or requesting the current wallet; it does not change the Approval already written to the blockchain.

Closing the webpage, deleting the DApp, clearing browser cache, or even changing the wallet app will not automatically invalidate it.

Finally, even legitimate contracts can become dangerous in the future. Many approval risks don't just come from initially malicious phishing sites. As in this hunt, a user might grant permissions to a protocol that is legitimate at the time, but later the protocol's contract gets exploited, admin keys leaked, upgradeable logic replaced, or its integrated router contract develops issues.

For the user, the assets remain in their own address, but from a permissions perspective, another contract has the ability to call these assets. Therefore, Approval risk is not just "did I authorize a bad actor?" but also "could the entity I authorized later have a problem?"

3. How to Manage Approval Risk

The simplest advice for dealing with Approval risk is: "Don't use infinite approval."

However, in the real-world DeFi environment, completely refusing approvals is impractical. As mentioned, Approval itself isn't a vulnerability; it's a fundamental way for on-chain applications to access assets.

What truly needs to change is viewing Approval not as a one-time confirmation, but as an ongoing permission management mechanism.

For everyday users, here are some essential habits to adopt:

• First, follow the principle of least privilege. When a wallet prompts for approval, set the limit according to your actual needs for that interaction. If you plan to use only 100 USDT, try to approve an amount close to 100 USDT instead of granting unlimited permission.
• Second, separate storage and interaction wallets. Avoid frequently connecting addresses holding large amounts of assets for long-term storage to unfamiliar DApps. Use a separate address for airdrops, mints, new projects, and high-risk DeFi interactions to limit potential losses.
• Third, regularly check and revoke unnecessary approvals. Users can use tools like Revoke.cash, or in imToken, navigate to the corresponding token page, click "Token Function" at the bottom, and select "Approval Management." This allows you to view the approved spender, token, and limit, and revoke permissions for unused or unknown sources (see extended reading: "A Step-by-Step Guide to Managing Approvals with Revoke.cash").

Of course, despite all the advice, relying solely on user awareness and periodic checks is insufficient against unpredictable approval attacks. Most users struggle to identify the owner of a contract address or judge whether an approval limit is reasonable.

Therefore, as the first line of defense for users entering Web3, wallets must provide active defense through product capabilities.

Take imToken as an example. It marks or blocks identified risky tokens, addresses, and DApps. **When a user grants token permissions to a regular external account or transfers tokens directly to a contract address, it also provides targeted risk warnings.** These warnings cannot replace user judgment, but they add a necessary safety buffer before the actual signing.

Additionally, imToken offers structured parsing and readable presentation of signature content during key steps like DApp login, token transfer, token swap, and authorization. This helps users understand what they are agreeing to before confirming, **ensuring that the content the user signs aligns with the behavior they see, rather than being compressed into an indecipherable hash.**

As standards like ERC-7730 (Clear Signing) advance, this "What You See Is What You Sign" readable presentation is poised to evolve from a single wallet's product feature into a shared industry standard among wallets, DApps, and smart contracts.

In summary, the private key determines who *owns* the account, while Approval determines who can *use* the assets within it. They are not the same thing, but they are equally important.

This means that **wallet security cannot stop at "Is my private key leaked?" and requires a collective effort from users to wallets:** Users need to scrutinize the spender and limit before approving and clean up unused permissions after interacting. Wallets need to make these permissions, often hidden within contracts, more visible, understandable, and easier to restrict and revoke.

After all, the truly dangerous transaction might not be the one just executed, but an approval long forgotten that has never been revoked.