An MEV bot that had long been exploiting ordinary traders on Ethereum eventually fell victim to a custom-built $7.5 million exploit.
On June 21, Jaredfromsubway.eth, a well-known Ethereum sandwich bot, was attacked. Assets including WETH and USDC were drained from its address, with preliminary estimates putting the loss at over $7.5 million, though publicly reported figures still vary.
What makes this incident notable is that it was neither caused by a private key leak nor by a traditional smart contract vulnerability. Instead, the attacker deployed large numbers of fake tokens, liquidity pools, and supporting contracts in advance, packaging them as trading paths that appeared to offer arbitrage opportunities. During automated execution, the bot was tricked into granting ERC-20 approvals to malicious contracts, which then “legitimately” drained its assets.
At the time of writing, Jaredfromsubway.eth had sent an on-chain message to the attacker, stating that if 2,150 ETH was returned within 48 hours, it would pay a 50% white hat bounty. Otherwise, it would pursue all available legal and enforcement measures.
But if even a highly specialized, code-driven MEV bot can stumble over approval, it is worth taking a closer look at this everyday on-chain action: how much risk is hidden behind “Approval”?
1. A Reverse Hunt Designed for a MEV Bot
A closer look at this attack shows that it was not an accidentally triggered vulnerability, but a long-running hunt designed around Jaredfromsubway.eth’s trading logic.
Jaredfromsubway.eth has long been one of the best-known sandwich bots on Ethereum. In simple terms, a sandwich attack means that after a bot detects a pending on-chain transaction, it buys before the user to push the price up. Once the user completes the trade at a worse price, the bot immediately sells and captures the spread.
Because of this, the strategy requires the bot to continuously scan on-chain transactions, identify arbitrage opportunities at extremely high speed, and build trading paths that interact with different tokens and contracts. The faster the bot is, and the more assets and protocols it covers, the more opportunities it can capture.
But that exact strength became the opening in this attack.
According to post-incident analyses, the attacker did not directly attack the bot’s asset-holding contract. Instead, they spent several weeks building a trading environment that appeared profitable.
First, they deployed large numbers of fake tokens and liquidity pools. These tokens mimicked common assets such as WETH, USDC, and USDT in name, interface, and trading behavior, leading the bot’s automated recognition system to believe it had found legitimate trading routes.
Second, they gradually made the bot trust these paths. In early tests, the allowances granted by the bot were used normally during trades. Once the bot’s system began repeatedly executing similar paths, the attacker adjusted the contract logic so that some allowances generated by the bot were no longer actually used and were not reset to zero after the trade ended. As a result, those allowances remained in place.
Finally, the attacker used the remaining valid allowances in one sweep, transferring the real WETH, USDC, and USDT out of the bot’s contract.
In plain terms, the entire attack targeted how MEV bots operate: first create an environment that matches the bot’s profit-detection rules, then exploit its automated execution mechanism to make the system grant asset-spending permissions on its own.
This also explains why even a highly specialized MEV bot could fall for it.
The bot could calculate spreads, gas costs, and transaction ordering, but it may not have performed sufficient identity checks on every new contract it encountered. From this perspective, ordinary users often make the mistake of “confirming without understanding,” while automated bots make the mistake of “executing without confirming.”
On the surface, these two cases look completely different. But the underlying risk is very similar: both treat approval as just another routine step before completing a transaction, without fully recognizing how much risk it may carry.
2. Why Is Approval So Often Underestimated?
In the ERC-20 standard on Ethereum and EVM-compatible chains, Approve is a fundamental design.
When users transfer tokens directly from a wallet, the function usually called is transfer, which typically does not involve Approve. Approval is typically required when interacting with smart contracts such as DEX trading, lending, staking, or adding liquidity, where users need to allow a smart contract to spend tokens on their behalf.
For example, when you want to swap USDT for ETH on Uniswap, Uniswap’s smart contract cannot directly take USDT from your wallet. You first need to approve it, telling the system: “I allow Uniswap to spend X USDT from my wallet.”
Only after approval is granted can the authorized contract use transferFrom to spend your USDT within the approved limit, allowing the swap to proceed.
In other words, approval itself is not a vulnerability. It is an important foundation that allows DeFi to function properly. The problem is that it works similar to a standing payment authorization in Apple Pay or Alipay.
Users do not give their account password to a merchant, but they do allow the merchant to charge funds within an agreed scope. As long as the authorization remains valid, future charges do not require users to enter a password or confirm each payment again. This naturally creates several problems.
The first problem is unlimited approval: users often turn a one-time transaction into a long-term permission. To reduce repeated steps and gas costs, many DApps request an extremely large allowance by default, commonly known as “unlimited approval.”
A user may only want to use 100 USDC for one transaction, but end up allowing the contract to spend all USDC in their address in the future. As long as this approval is not revoked, even if the wallet held only a small balance at the time, any USDC transferred in later may still be at risk.
The second issue is that approvals do not disappear when you leave a DApp. Many users confuse “disconnecting a wallet” with “revoking approval.” In reality, disconnecting only temporarily prevents the website from reading or requesting access to the current wallet. It does not change any approval already written on-chain.
Closing the webpage, deleting the DApp, clearing browser cache, or even switching to another wallet app will not revoke it.
Finally, even a legitimate contract may become dangerous in the future. Many approval risks do not come only from phishing sites that were malicious from the beginning. As this reverse hunt shows, a user may grant permission to a protocol that appears normal at the time. Later, however, the protocol contract may be attacked, an admin key may be leaked, upgradeable logic may be replaced, or a routing contract it calls may run into problems.
For users, the assets may still appear to be in their own address. But from an authorization perspective, another contract may still have the ability to spend those assets. This means approval risk is not only about “whether I authorized a bad actor,” but also about “whether the party I authorized may become risky in the future.”
3. How Should Approval Risk Be Managed?
The simplest advice for managing approval risk is: do not grant unlimited approval.
But in real DeFi usage, completely rejecting approvals is not realistic. As mentioned earlier, approval itself is not a vulnerability. It is the basic way on-chain applications access and use assets.
What needs to change is that approval should no longer be treated as a one-time confirmation. It should become part of an ongoing permission-management process.
For ordinary users, the first step is to develop a few simple habits.
First, follow the principle of least privilege. When your wallet shows an approval request, try to set the allowance based on what this interaction actually needs. If you only plan to use 100 USDT, authorize an amount close to 100 USDT whenever possible instead of granting unlimited permission.
Second, separate your long-term holding wallet from your interaction wallet. Addresses that hold large amounts of assets for the long term should avoid frequently connecting to unfamiliar DApps. When participating in airdrops, mints, new projects, or high-risk DeFi interactions, use a separate address to keep potential losses limited.
Third, regularly check and revoke approvals you no longer need. Users can use tools such as Revoke.cash, or open the relevant token page in imToken, tap “Token Function” in the lower-left corner, then select “Revoke” to view the authorized parties, tokens, and allowances for that address. Permissions that are no longer used or come from unknown sources should be revoked. Further reading: “How to Use Revoke.cash for Approval Management: A Step-by-Step Guide.”
Of course, when it comes to approval attacks that are difficult to fully prevent, relying only on user awareness and regular checks is still not enough. After all, most users cannot easily identify the owner of a contract address, nor can they always judge whether an allowance is reasonable.
As the first line of defense for users entering Web3, wallets must provide proactive protection at the product level.
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, imToken also provides targeted risk alerts. These alerts cannot replace user judgment, but they add a necessary safety buffer before signing.
In addition, imToken provides structured parsing and human-readable transaction details of signing content across key steps such as DApp login, transfers, token swaps, and approvals. This helps users understand what they are agreeing to before confirmation and ensures that what they sign matches what they see, rather than reducing the action to an unreadable hash.
As Clear Signing standards such as ERC-7730 continue to advance, this human-readable “What You See Is What You Sign” experience may gradually evolve from a feature of individual wallets into a shared industry standard across wallets, DApps, and smart contracts.
Overall, private keys determine who owns an account, while approval determines who else can spend the assets in that account. They are not the same thing, but both are equally important.
This means wallet security cannot stop at asking whether the private key has been leaked. It requires joint effort from both users and wallets. For users, this means checking the authorized party and allowance before granting approval, and clearing permissions that are no longer needed after an interaction is complete. For wallets, it means making permissions that were once hidden inside contracts more visible, easier to understand, and easier to limit or revoke.
After all, the real danger may not be the transfer that just occurred. It may be an approval granted long ago, forgotten, and never expired.