MEV Bot "Jaredfromsubway.eth" Hit by Honeypot, Losing More Than $7.5M; Onchain Tracing Details

A leading Ethereum MEV bot, Jaredfromsubway.eth, was caught in a carefully engineered honeypot on June 21, resulting in losses exceeding $7.5 million in crypto assets. Below is Beosin's breakdown of how the exploit worked and where the funds moved. Attack structure: contracts used Investigators identified a coordinated contract set designed to manipulate the bot's execution flow: - Coordinator contract (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): flags whether the current block is "armed" and, at the end, iteratively calls child contracts to pull funds. - Trigger contract (0x4de8c729a064ff6087cc84a4152969349e4feb98): fabricates trading-pair states inside the same block so arbitrage routes appear executable. - Child contract / fake token contract: poses as a standard ERC-20 to obtain real token approvals. - Hub contract: pays small, real profits to make the opportunity look legitimate. - Ring V2 pair: a spoofed Uniswap V2-style trading pair. - Fake intermediate token contracts: used to build multihop routes (e.g., fCAP, fUSDC). Core mechanism: approvals that look normal but remain exploitable Onchain analysis shows the attacker baited the bot with repeated "decoy" arbitrage wins, engineered to leave meaningful allowances behind: - Large USDC: bot earned ~36.997120 USDC, but left 20 USDC approved. - Large USDT: bot earned ~37.053440 USDT, but left 20 USDT approved. - Large WETH: bot earned ~0.0179 WETH, but left 16 WETH approved. Small trades behaved as expected: once the bot approved the real token amount, the child contract immediately used transferFrom to pull tokens, consuming the allowance in the same transaction and reducing suspicion. Large trades were different. Instead of calling transferFrom to pull the real tokens, the child contract minted fake tokens and used those to satisfy the apparent swap preconditions. The bot proceeded as if the swap path was valid, while the real-token approval remained intact. The exploit hinges on this split behavior: approvals are consumed in small trades, but preserved in larger ones. How the USDC leg was executed A typical sequence targeting USDC was described as: 1) The attacker called the coordinator to set the current block to "armed". 2) The attacker called the trigger to update multiple forged Ring V2 pair states. 3) The MEV bot detected the "opportunity" and executed the transaction. Within the bot's execution flow: 1) The bot contract approved a large USDC allowance to a child contract. 2) The bot called the child contract's wrapTo/wrap function. 3) Because the block was armed, the child contract did not pull real USDC; it minted fake tokens to the pair and left the USDC allowance untouched. 4) The bot swapped through the forged pair. 5) The second-hop pair sent tokens back to the bot. 6) The hub contract paid a small amount of real USDC to the bot as profit. Approval example transaction hash: 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb From the bot's perspective, the trade succeeded and produced real profit, masking the fact that the approval remained available for later abuse. The same approach was repeated across USDC, USDT, and WETH to accumulate many retained approvals. Attack transaction hash: 0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65 Draining phase and outcome The attacker then triggered the coordinator's drain loop. The calldata included 66 child contract addresses plus the MEV bot contract address. Any child contract that had previously received an allowance could directly transfer the corresponding real tokens out to the attacker. Final authorization consumption status: - All 20 USDC "large" approvals were fully consumed. - All 16 WETH "large" approvals were fully consumed. - A partial USDT approval remained, but the bot's USDT balance was insufficient. Funds tracing After the exploit, the attacker address 0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0 received $2.87M in USDC, $2.04M in USDT, and 1,474 WETH. The stablecoins were swapped into ETH, then distributed to four addresses: - 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (~1,000 ETH) - 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1,001 ETH) - 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1,001 ETH) - 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1,423 ETH) Beosin noted that 0xe3Da3 subsequently sent 1,000 ETH to Tornado Cash, while the other three addresses had not moved funds further at the time of analysis. Takeaway The incident highlights a mature MEV-targeted strategy: rather than attacking contract code directly, the attacker exploited the bot's business logic by manufacturing arbitrage conditions that coaxed the bot into granting seemingly valid approvals. Simulated profitability alone is not a sufficient safety check for arbitrage routes, especially when unfamiliar contracts, forged tokens, or custom wrappers are involved. Beosin recommends tighter scrutiny of route components and incorporating mandatory checks for post-transaction allowance changes. View original text