On June 21, one of the most active MEV bots on the Ethereum network, Jaredfromsubway.eth, fell victim to a meticulously crafted honeypot attack, losing over $7.5 million in crypto assets. Below is the analysis and tracking of the stolen funds by the Beosin security team.
Attack flow analysis
Attack contract family
- Coordinator Contract (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): Responsible for recording whether the current block is in an armed state and iteratively calling child contracts to withdraw funds during the final stage. - Trigger Contract (0x4de8c729a064ff6087cc84a4152969349e4feb98): Responsible for setting up forged trading pair states within the same block to make arbitrage paths appear executable. - Child Contract / Fake Token Contract: Masquerades as a standard ERC-20 token to obtain genuine approvals. - Hub Contract: Responsible for paying small real profits to make MEV bots perceive the opportunity as profitable. - Ring V2 Pair: A forged Uniswap V2 trading pair. - Fake Intermediate Token Contract: Used to construct multi-hop arbitrage paths, such as fCAP and fUSDC.
The key to the attack: deceptive authorization
By analyzing on-chain transactions, the attacker constructed multiple sets of decoy transactions:
- Large USDC: The bot earned approximately 36.997120 USDC but left 20 USDC authorized. - Large USDT: The bot earned approximately 37.053440 USDT but left 20 USDT authorized. - Large WETH: The bot earned approximately 0.0179 WETH but left 16 WETH authorized. - Small trades performed normally, with authorizations consumed within the same transaction to reduce suspicion.
In small transactions, after the bot authorizes the real token amount, the child contract immediately transfers the real tokens, consuming the authorization, which appears completely normal.
In large transactions, the sub-contract does not call transferFrom to transfer actual tokens; instead, it forges transactions to mint fake tokens. The bot believes it has completed the normal swap prerequisites, but the actual token approval remains intact.
This is the core of the entire attack: small transactions normally consume authorization, while large transactions retain authorization.
Attack process
For example, with attack transactions targeting USDC:
(1) The attacker calls the coordinator to set the current block to armed. (2) The attacker calls the trigger to update the status of multiple forged Ring V2 pairs. (3) The MEV bot detects an arbitrage opportunity and executes the trade.
The general process of an MEV Bot transaction is as follows:
(1) The MEV Bot contract approved a large USDC allowance to a child contract. (2) The MEV Bot called the wrapTo/wrap function of the child contract. (3) Due to its current armed state, the child contract did not consume actual USDC but instead minted fake tokens to the pair, preserving the USDC approval. (4) The MEV Bot continued to swap on the forged pair. (5) The second-hop pair sent the tokens to the MEV Bot. (6) The hub contract paid the MEV Bot a small amount of real USDC as profit.
Approval example
tx hash: 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb
MEV Bot observed: a successful arbitrage trade that generated real USDC profits. However, the USDC approval was retained by the child contract. This process was repeated separately for USDC, USDT, and WETH, ultimately resulting in a large number of approvals.
Attack transaction hash:
0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65
The attacker invokes the coordinator contract’s drain loop, with the calldata containing 66 child contract addresses and the MEV Bot contract address. As long as the MEV Bot contract had previously granted spending authorization to the child contracts, the child contracts can directly transfer the corresponding real tokens to the attacker.
Final result:
- All 20 USDC large authorizations have been fully consumed. - All 16 WETH large authorizations have been fully consumed. - A partial authorization for USDT still exists, but the USDT balance is insufficient.
Fund Flow Analysis
After the attack, the attacker’s address (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) received $2.87M USDC, $2.04M USDT, and 1,474 WETH. The attacker then exchanged the stablecoins for ETH and transferred them to the following four addresses:
- 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (approximately 1,000 ETH) - 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1,001 ETH) - 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1,001 ETH) - 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1,423 ETH)
Of these, 0xe3Da3 has transferred 1,000 ETH to Tornado Cash, while the other three addresses have had no further transfers. The fund flow diagram is shown below:
Conclusion
This attack demonstrates a highly sophisticated method: rather than directly targeting the contract code, the attacker exploits the MEV bot’s business logic by constructing specific arbitrage scenarios that mislead the bot into granting seemingly legitimate approvals, ultimately transferring its assets. For arbitrage bots and MEV bots, relying solely on simulated returns to assess route safety is insufficient—especially when the arbitrage path involves unfamiliar contracts, forged tokens, or custom wrappers. Careful scrutiny is essential, and mandatory checks on post-transaction allowance changes should be considered.