Author: imToken
A long-running MEV bot that hunted ordinary traders on Ethereum finally fell into a 'custom-made' trap worth $7.5 million.
On June 21, the well-known Ethereum sandwich arbitrage bot Jaredfromsubway.eth was attacked, with assets including WETH and USDC transferred from its address. Preliminary statistics show losses exceeding $7.5 million (though public reports on the exact loss figure still vary).
Interestingly, this attack was neither due to private key leakage nor the exploitation of traditional smart contract vulnerabilities. Instead, the attacker deployed a large number of fake tokens, liquidity pools, and auxiliary contracts in advance, packaging them as trading paths with potential arbitrage opportunities. This lured the bot into automatically granting ERC-20 Approvals to malicious contracts during execution, ultimately allowing the assets to be 'legally' transferred away.
As of publication, Jaredfromsubway.eth has publicly messaged the attacker on-chain, stating, 'If 2150 ETH is returned within 48 hours, we are willing to offer a 50% white hat bounty. Otherwise, we will pursue all available legal and law enforcement actions.'
However, if even a highly specialized, code-driven MEV bot can stumble over an Approval, it forces us to re-examine how dangerous the 'Approval' action we use every day truly is.
I. A Reverse Hunt Designed Specifically for an MEV Bot
A careful review of this attack reveals it was not an accidentally triggered flaw but a long-term hunt 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 an impending on-chain transaction, buying ahead of the user to push the price up, waiting for the user to complete their transaction at a worse price, and then immediately selling to pocket the difference.
Consequently, this strategy requires the bot to continuously scan the mempool, identify arbitrage opportunities at extreme speed, and construct transaction paths calling various tokens and contracts. This also means the faster the speed and the broader the asset and protocol coverage, the more opportunities the bot can capture.
Yet, this very aspect became the entry point for this incident.
Based on post-mortem analysis, the attacker did not directly attack the bot's fund contract. Instead, they spent weeks constructing a trading environment that appeared profitable:
- Step One: Deploy numerous 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 identification system into believing it had discovered normal trading paths.
- Step Two: Gradually gain the bot's trust. In early tests, the approvals granted by the bot were consumed normally during transactions. Once the bot's system began repeatedly executing similar paths, the attacker adjusted the contract logic. This left some of the approvals generated by the bot unconsumed and not reset to zero after transactions, causing them to persist.
- Finally, the attacker centrally invoked the still-valid approval limits to transfer the real WETH, USDC, and USDT from the bot's contract.
In essence, the entire attack precisely targeted the operational characteristics of MEV bots: first, create an environment that matches their profit-judgment rules; then, exploit their mechanism of pursuing automated execution of trading paths, making the system proactively hand over asset-calling permissions.
This also explains why even a highly specialized MEV bot could be tricked.
It knows how to calculate price differences, Gas costs, and transaction ordering, but may not conduct thorough identity verification for every newly appearing contract. From this perspective, the problem for ordinary users is 'confirming without understanding,' while the problem for automated bots is 'executing automatically without confirmation.'
Superficially, the two are entirely different, but the underlying risk is quite similar: both treat approval as just an ordinary step before completing a transaction, without clearly recognizing how high its hidden risk can be.
II. Why is Approval Always Underestimated?
As is well known, in the ERC-20 standard of Ethereum and EVM-compatible chains, Approve (authorization) is a fairly low-level design.
However, when users directly transfer tokens via their wallet, they typically call `transfer`, which generally doesn't involve Approve. Only in smart contract scenarios like DEXes, lending, staking, or adding liquidity—where users need a smart contract to call tokens on their behalf—does Approval come into play.
For example, when we want to swap USDT for ETH on Uniswap, Uniswap's smart contract cannot directly take USDT from your wallet. It must first execute an Approve to tell the system, 'I allow Uniswap to withdraw X amount of USDT from my wallet.'
Only after the approval is granted can the authorized contract, via `transferFrom`, 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 fundamental basis for DeFi's normal operation. The problem, however, is that it's somewhat like automatic debit permissions on Alipay/WeChat Pay:
The user hasn't given their account password to the merchant, but they have allowed the merchant to initiate debits within an agreed range. As long as the authorization remains valid, subsequent debits don't require the user to re-enter a password or confirm each transaction individually. This inherently creates issues.
First, there's the issue of infinite approval—turning a one-time transaction into long-term permission. Mainly to reduce operational and Gas costs from repeated approvals, many DApps default to requesting an extremely large approval limit, commonly known as 'infinite approval.'
A user might have only intended to use 100 USDC for a single transaction but ended up allowing the contract to potentially use all USDC in their address in the future. As long as this approval isn't revoked, even if the user's wallet only held a small amount of assets at the time, future deposits of USDC could continue to be affected.
Second, approvals don't disappear by default when you leave a DApp. Many users confuse 'disconnecting a wallet' with 'revoking approval.' In reality, disconnecting only temporarily prevents the webpage from reading or requesting the current wallet; it doesn't change the Approval already written to the blockchain.
Closing the webpage, deleting the DApp, clearing browser cache, or even changing wallet applications won't automatically invalidate it.
Finally, even legitimate contracts can become dangerous in the future. Many approval risks don't only come from phishing sites that were malicious from the start, as seen in this hunt. A user might grant permission to a protocol that was normal at the time, but later, the protocol's contract could be hacked, admin keys leaked, upgradeable logic replaced, or issues could arise with its called router contracts.
For the user, the assets remain in their address, but from a permissions perspective, another contract always retains the ability to call those assets. Therefore, Approval risk isn't just about 'did I authorize a bad actor,' but also includes 'could the entity I authorized have problems later?'
III. So, How Can We Manage Approval Risk?
Faced with Approval risk, the simplest advice is 'don't grant infinite approval.'
However, in real-world DeFi usage, completely refusing approval is impractical. As mentioned, approval itself is not a flaw; it's the basic method for on-chain applications to call assets.
What truly needs to change is transforming Approval from a one-time confirmation action into an ongoing permission management mechanism.
For ordinary users, first, it's essential to establish a few basic habits:
- First, follow the 'principle of least privilege.' When a wallet pops up an approval prompt, try to set the limit based on the actual needs of the current interaction. For example, if you only plan to use 100 USDT, try to approve only an amount close to 100 USDT, rather than directly granting unlimited permission.
- Second, separate storage wallets from interaction wallets. Avoid frequently connecting addresses holding large long-term assets to unfamiliar DApps. For activities like airdrops, minting, new projects, and high-risk DeFi interactions, use a separate address to limit potential losses to a smaller scope.
- Third, regularly check and revoke approvals no longer needed. Users can utilize tools like Revoke.cash or, within imToken, navigate to the corresponding token page, click 'Token Function' in the bottom left, then select 'Authorization Management' to view approval targets, tokens, and amounts for that address. Revoke permissions that are no longer used or of unknown origin (further reading: Step-by-Step Guide to Using Revoke.cash for Authorization Management).
Of course, at the end of the day, facing unpredictable approval attacks, relying solely on user security awareness and regular checks isn't enough. After all, most users find it difficult to distinguish who a string of contract addresses belongs to or judge whether a particular approval amount is reasonable.
Therefore, as the first line of defense for users entering Web3, wallets must provide active defense in their product capabilities.
Taking imToken as an example, it marks or blocks identified risky tokens, addresses, and DApps. When users grant token permissions to ordinary external accounts or make direct transfers to contract addresses, targeted risk warnings are also provided. These warnings cannot replace user judgment but at least add a necessary safety buffer before actual signing.
Additionally, imToken performs structured parsing and human-readable presentation of signature content during key processes like DApp login, transfers, token swaps, and approvals. This aims to help users understand what they are agreeing to before confirmation, ensuring that the content users sign must be consistent with the behavior they see, rather than being compressed into an indistinguishable hash string.
With the further advancement of standards like ERC-7730 (Clear Signing), this 'What You See Is What You Sign' readable presentation is expected to gradually evolve from a single wallet's product capability into an industry standard shared among wallets, DApps, and smart contracts.
Overall, private keys determine who owns an account, while Approvals determine who else can call the assets within that account. They are not the same thing but are equally important.
This also means that wallet security cannot stop at 'has the private key been leaked.' This requires joint effort from users to wallets: For users, it's about seeing the object and amount before approving, and promptly cleaning up unnecessary permissions after interactions end. For wallets, it's about making these permissions—originally 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 transfer that just happened, but an approval long forgotten yet never invalidated.
