最頂級的 MEV 機器人，被盜 750 萬美元：Approval 才是鏈上最易忽視的致命風險？

A MEV bot that had long been hunting ordinary traders on Ethereum eventually fell into a "custom-tailored" trap worth $7.5 million.

On June 21st, Jaredfromsubway.eth, a well-known sandwich arbitrage bot on Ethereum, was attacked. Assets like WETH and USDC within its address were transferred out, with initial estimates placing losses at over $7.5 million (though publicly disclosed loss figures currently vary).

Interestingly, this attack was neither a private key leak nor did it exploit traditional smart contract vulnerabilities. Instead, the attacker deployed a large number of fake tokens, liquidity pools, and auxiliary contracts in advance, packaging them into seemingly profitable trading paths. This tricked the bot, during its automated execution, into granting ERC-20 Approvals to a malicious contract, ultimately allowing the "legitimate" transfer of the MEV bot's assets.

As of writing, Jaredfromsubway.eth has publicly appealed to the attacker via an on-chain message, stating, "If the 2150 ETH are returned within 48 hours, we will pay a 50% white hat bounty; otherwise, we will pursue all available legal and enforcement actions."

However, the fact that even a highly specialized, code-driven MEV bot can be tripped up by Approvals forces a re-examination: just how dangerous is this "Approval" action we use every day?

1. A Reverse Hunt Specifically Designed for MEV Bots

A careful review of this attack reveals it wasn't an accidental exploit, but a long-term hunt meticulously designed around Jaredfromsubway.eth's trading logic.

Jaredfromsubway.eth has long been one of the most famous sandwich arbitrage bots on Ethereum. Simply put, a sandwich attack involves the bot detecting a pending on-chain transaction, buying before the user to drive up the price, letting the user complete the trade at a worse price, and then immediately selling to capture the profit spread.

Consequently, this strategy requires the bot to constantly scan on-chain transactions, identify arbitrage opportunities at lightning speed, and construct trading paths involving various tokens and contracts. This means the faster it is and the more assets and protocols it covers, the more opportunities it can capture.

And this was precisely the point of entry for this incident.

According to post-mortem analyses, the attacker didn't directly target the bot's fund contracts. Instead, they spent weeks constructing a set of seemingly profitable trading environments:

• Step one was deploying a large number of fake tokens and liquidity pools. These tokens mimicked common assets like WETH, USDC, and USDT in name, interface, and behavior, tricking the bot's automated recognition system into interpreting them as legitimate trading paths.
• Step two was gradually gaining the bot's trust. During early testing, the bot granted Approvals that were used normally for trades. After the bot's system began repeatedly executing similar paths, the attacker tweaked the contract logic so that some Approvals generated by the bot were no longer actually consumed or reset to zero after trading, leaving these Approvals active.
• Finally, the attacker collectively called the still-valid Approval limits to drain real WETH, USDC, and USDT from the bot's contracts.

In essence, the entire attack targeted the operational characteristics of MEV bots: first creating an environment that fits their profit-seeking rules, then leveraging their automated execution mechanism to make the system willingly hand over asset control rights.

This explains why even a highly specialized MEV bot could fall victim.

It understands how to calculate spreads, gas costs, and transaction order, but it may not thoroughly verify the identity of every new contract it encounters. From this perspective, the problem for regular users is "approving without understanding," while the problem for automated bots is "executing without confirming."

Superficially, these seem different, but the underlying risk is very similar: both treat Approval as a routine step before completing a trade, without a clear awareness of its hidden dangers.

2. Why is Approval Always Underestimated?

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

However, when users directly transfer tokens in their wallets, they usually call `transfer`, which generally doesn't involve Approve. Approvals are necessary only when interacting with smart contracts on DEXs, lending protocols, staking platforms, or adding liquidity—scenarios where the contract needs to move tokens on behalf of the user.

For example, when swapping USDT for ETH on Uniswap, the Uniswap smart contract cannot directly take USDT from your wallet. It requires a prior Approve transaction to tell the system: "I allow Uniswap to move X number of USDT from my wallet."

Only after this approval is granted can the authorized contract use `transferFrom` to move the user's USDT within the allowed limit, enabling the subsequent Swap to proceed successfully.

This means Approvals themselves are not vulnerabilities; they are a crucial foundation for DeFi's normal operation. The problem is analogous to giving a merchant automatic payment permission on apps like Alipay or WeChat.

The user doesn't hand over their account password to the merchant, but allows the merchant to automatically deduct funds within an agreed scope. As long as the authorization is valid, subsequent deductions don't require the user to re-enter passwords or confirm each transaction, which inherently creates some issues.

Firstly, there's the issue of unlimited approvals, where users turn a one-time transaction into a permanent permission. Mainly to avoid the hassle and gas costs of repeated approvals, many dApps default to requesting a very large allowance, commonly known as an "unlimited approval."

A user might originally intend to use only 100 USDC for a single transaction but ends up allowing the contract to access all their USDC in the future. As long as this approval isn't revoked, even if the user's wallet currently holds only a small balance, any USDC transferred in later could potentially be affected.

Secondly, approvals don't automatically disappear when you leave a dApp. Many users confuse "disconnecting a wallet" with "revoking an approval." In reality, disconnecting only prevents the website from reading or requesting the current wallet temporarily; it doesn't change the Approval already recorded on the blockchain.

Closing the webpage, deleting the dApp, clearing browser cache, or even switching wallet apps won't make it automatically invalid.

Finally, even a legitimate contract can become dangerous in the future. Many approval risks don't stem solely from initially malicious phishing sites. As seen in this hunt, a user might grant permission to a protocol that is legitimate at the time, but later the protocol's contract could be exploited, admin keys could be leaked, upgradeable logic could be swapped, or the router contracts it calls could have issues.

From the user's perspective, assets remain in their address. But from a permissions perspective, another contract has the authority to move those assets. Therefore, the risk of Approval isn't just "Did I authorize a bad actor?" but also "Could the entity I authorized become a problem later?"

3. How to Manage Approval Risk

When facing Approval risk, the simplest advice is "avoid unlimited approvals."

However, in the real DeFi environment, completely refusing approvals isn't practical. As mentioned earlier, approvals themselves aren't flaws; they are the foundational method for on-chain applications to interact with assets.

What truly needs to change is treating Approvals not as a one-time confirmation action, but as a continuous permission management mechanism.

For regular users, several basic habits need to be established:

• First, adhere to the "principle of least privilege." When a wallet prompts for an approval, try to set the allowance based on the actual needs of the current interaction. For example, if you only plan to use 100 USDT, approve an amount close to 100 USDT rather than granting unlimited permission.
• Second, separate storage wallets from interaction wallets. Addresses holding significant assets for the long term should not frequently connect to unknown dApps. Use a separate address for airdrops, mints, new projects, and high-risk DeFi interactions to limit potential losses to a smaller range.
• Third, periodically check and revoke unnecessary approvals. Users can use tools like Revoke.cash, or within imToken, navigate to the specific token page, click "Token Function" in the bottom left, then select "Approval Management" to view the approved addresses, tokens, and limits for that address, and revoke permissions for stale or unknown sources (Further reading: [Original Link: Step-by-step guide on using Revoke.cash for approval management]).

Of course, no matter how much is said, relying solely on user awareness and periodic checks isn't enough against sophisticated approval attacks. Most users struggle to determine who owns a specific contract address or whether an approval limit is reasonable.

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

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 (EOA) or transfers tokens directly to a contract address, it also provides targeted risk warnings. These warnings cannot replace user judgment, but they can at least add a necessary safety buffer before a signature is made.

Furthermore, imToken offers structured parsing and readable presentation of signature content during critical steps like dApp login, token transfers, swaps, and approvals. This helps users understand what they are agreeing to before confirming, ensuring that the content users sign aligns with the action they see, rather than being compressed into an unreadable hash.

As Clear Signing standards like ERC-7730 advance, this "What You See Is What You Sign" readable display has the potential to evolve from a feature of individual wallets to a shared industry standard among wallets, dApps, and smart contracts.

In summary, private keys determine who owns an account, while Approvals determine who can access the assets within it. They are not the same thing, but both are equally important.

This means wallet security cannot stop at "Has my private key been leaked?" It requires a joint effort from both users and wallets: For users, it means carefully checking the target and limit before approving, and promptly cleaning up unnecessary permissions after interaction. For wallets, it means making these hidden permissions more visible, understandable, and easier to restrict and revoke.

After all, the real danger may not be the transaction that just happened, but an Approval that was granted long ago, forgotten, and yet remains active.