最顶级的 MEV 机器人，被盗 750 万美元：Approval 才是链上最易忽视的致命风险？

A long-time MEV bot that preyed on regular traders on Ethereum has finally fallen into a "custom-made" trap worth $7.5 million.

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

Interestingly, this attack did not involve a private key leak or 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 transaction paths that appeared to have arbitrage opportunities. This lured the bot into granting ERC-20 Approval to a malicious contract during its automated execution process, ultimately "legitimately" transferring the MEV bot's assets away.

As of press time, Jaredfromsubway.eth has publicly appealed to the attacker via an on-chain message, stating, "If 2,150 ETH are returned within 48 hours, a 50% white-hat bounty will be paid. Otherwise, all available legal and law enforcement measures will be taken to pursue accountability."

However, the fact that even a highly specialized, code-driven MEV bot could stumble over an Approval issue forces us to re-examine just how dangerous this "Approval" action, which we use daily, truly is.

1. A Reverse Hunt Specifically Designed for MEV Bots

A careful review of this attack reveals it was not 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 spotting a pending on-chain transaction, buying in ahead of the user to drive up the price, waiting for the user to execute their trade at a worse price, and then immediately selling to capture the price difference.

Consequently, this strategy requires the bot to continuously scan on-chain transactions, rapidly assess arbitrage opportunities, and organize transaction paths to interact with different tokens and contracts. This means the faster it is and the more assets and protocols it covers, the more opportunities it can capture.

Precisely this characteristic became the breakthrough point for the attack.

According to post-mortem analysis, instead of directly attacking the bot's fund contracts, the attacker spent weeks constructing a set of trading environments that appeared profitable:

• First, deploy a large number of fake tokens and liquidity pools. These tokens mimicked common assets like WETH, USDC, and USDT in name, interface, and trading behavior, tricking the bot's automated recognition system into thinking it had found legitimate trading paths.
• Second, gradually earn the bot's trust. During early tests, the approvals granted by the bot were used normally in transactions. As the bot's system began repeatedly executing similar paths, the attacker adjusted the contract logic. This caused some approvals generated by the bot to no longer be consumed or reset to zero after the transaction ended, leaving these approvals active.
• Finally, the attacker concentrated on calling the still-valid approval allowances, transferring out the real WETH, USDC, and USDT from the bot's contract.

In essence, the entire attack was laser-focused on the operational characteristics of MEV bots: first, create an environment that matches their profit-seeking rules; then, exploit the mechanism that drives them to automatically execute trading paths, forcing the system to voluntarily hand over asset control rights.

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

It understands how to calculate price spreads, gas costs, and transaction sequencing, but it might not thoroughly verify the identity of every newly encountered contract. From this perspective, the average user's problem is "clicking confirm without reading," while the automated bot's problem is "executing automatically without confirming."

On the surface, these are entirely different issues, but the underlying risk is very similar. Both treat Approval as a routine step before completing a transaction, without a clear awareness of the high potential danger it harbors.

2. Why Is Approval Always Underestimated?

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

However, when a user directly transfers tokens in a wallet, they typically call `transfer`, which generally doesn't involve `Approve`. Approval only comes into play when a user interacts with a smart contract on platforms like DEXs, lending protocols, staking, or adding liquidity, where the contract needs to move tokens on the user's behalf.

For example, when swapping USDT for ETH on Uniswap, the Uniswap smart contract cannot directly access the USDT in your wallet. First, an `Approve` transaction must be executed to inform the system, "I allow Uniswap to move X amount of USDT from my wallet."

Only after the approval is completed can the authorized contract use `transferFrom` to access the user's USDT up to the specified limit, allowing the subsequent swap to proceed successfully.

In other words, Approval itself is not a vulnerability; it's a crucial foundation for DeFi to function correctly. The problem, however, is that it's somewhat like setting up auto-debit permissions on Alipay or WeChat:

The user doesn't hand over their account password to the merchant but allows the merchant to initiate deductions within an agreed scope. As long as the approval remains valid, subsequent deductions don't require the user to re-enter their password or confirm each transaction. This inherently creates certain issues.

First is the problem of infinite approval, where users often turn a one-time transaction into a long-term permission. Primarily to reduce the frequency of repetitive approvals and associated gas costs, many DApps default to requesting an extremely high approval limit, commonly known as "infinite approval."

A user might only want to use 100 USDC for a single transaction but ends up allowing the contract to access their entire USDC balance indefinitely. If that approval isn't revoked, even if the wallet only held a small amount at the time, any USDC deposited later could still be affected.

Secondly, approvals do not automatically disappear when you stop using a DApp. Many users confuse "disconnecting the wallet" with "revoking an approval." In reality, disconnecting only prevents the website from reading or requesting the current wallet; it does not alter the `Approval` already written to the blockchain.

Closing the webpage, deleting the DApp, clearing the browser cache, or even changing wallet applications will not make it automatically invalid.

Finally, even a legitimate contract can become dangerous in the future. Many approval risks don't solely originate from malicious phishing sites from the start. As seen in this hunt, a user might grant permission to a protocol that is legitimate at the time. However, later on, the protocol's contract could be exploited, its admin key compromised, its upgradeable logic replaced, or a router contract it calls could have issues.

For the user, the assets remain in their own address, but from a permission standpoint, another contract continuously holds the ability 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 problematic later?"

3. How to Manage Approval Risk

Facing the risks of Approval, the simplest advice is "don't use infinite approval."

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

What truly needs to change is treating Approval not as a one-time confirmation action but as an ongoing permission management system.

For regular users, establishing a few basic habits is crucial:

• First, adhere to the "Principle of Least Privilege." When a wallet prompts for approval, adjust the limit based on the actual needs of the interaction. For example, if you only plan to use 100 USDT, try to approve an amount close to 100 USDT rather than granting unlimited permission.
• Second, separate storage wallets from interaction wallets. Addresses holding significant long-term assets should avoid frequently connecting to unfamiliar DApps. When interacting with airdrops, mints, new projects, or high-risk DeFi protocols, use a separate address to limit potential losses to a smaller scope.
• Third, regularly check and revoke unnecessary approvals. Users can use tools like Revoke.cash, or in imToken, navigate to the specific token page, click the "Token Function" button at the bottom left, and select "Approval Management." This allows you to view the authorized spender, token, and allowance for that address and initiate revocations for permissions that are no longer needed or of unknown origin (see also: 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 increasingly sophisticated approval attacks. After all, most users struggle to discern who a contract address belongs to or whether an approval limit is reasonable.

As the first line of defense for users entering Web3, wallets must provide proactive defense through product capabilities.

Take imToken for example. It flags or blocks identified risky tokens, addresses, and DApps. When users grant token permissions to regular external accounts or directly transfer tokens to a contract address, it also provides specific risk warnings. These warnings cannot replace user judgment, but they add a crucial safety buffer before the actual signature is made.

Furthermore, imToken offers structured parsing and readable presentation of signature content in key operations like DApp login, transfers, token swaps, and approvals. This helps users understand what they are agreeing to before confirming, ensuring that what a user signs is consistent with what they see, rather than being compressed into an unintelligible hash.

As Clear Signing standards like ERC-7730 progress, this "What You See Is What You Sign" (WYSIWYS) readable presentation is expected to evolve from a feature of individual wallets into a shared industry standard among wallets, DApps, and smart contracts.

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

This also means that wallet security cannot stop at "Has the private key been leaked?", and it requires a joint effort from users and wallets alike: For users, it means scrutinizing the spender and allowance before approving and promptly cleaning up unnecessary permissions after interactions. For wallets, it means making these permissions, which are often hidden within contracts, more visible, easier to understand, and more convenient to limit and revoke.

After all, what's truly dangerous might not be the transaction that just happened, but an approval granted long ago that has never been revoked and remains active.