On June 21, Jaredfromsubway.eth—one of the most active MEV bots on the Ethereum network—fell victim to a meticulously crafted “honeypot attack,” losing over $7.5 million in crypto assets. Below is Beosin’s security team analysis of the attack and the trace of stolen funds.
Attack Flow Analysis
The attack contract family includes:
– Coordinator contract (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): Records whether the current block is in the “armed” state and, in the final stage, iteratively calls child contracts to drain funds.
– Trigger contract (0x4de8c729a064ff6087cc84a4152969349e4feb98): Sets fake trading pair states within the same block, making the arbitrage path appear executable.
– Child contract / Fake token contract: Masquerades as a legitimate ERC-20 token to obtain genuine approvals.
– Hub contract: Pays a small amount of real yield to make the MEV bot believe the opportunity is profitable.
– Ring V2 pair: A forged Uniswap v2 trading pair.
– Fake intermediary token contract: Used to construct multi-hop arbitrage paths—for example, fCAP and fUSDC.
The Core of the Attack: Approval Deception
By analyzing on-chain transactions, the attacker constructed multiple sets of bait transactions:
– Large USDC transaction: The bot earned ~36.997120 USDC but left behind a 20-USDC approval.
– Large USDT transaction: The bot earned ~37.053440 USDT but left behind a 20-USDT approval.
– Large WETH transaction: The bot earned ~0.0179 WETH but left behind a 16-WETH approval.
Small-value transactions behaved normally—the approvals were consumed within the same transaction, reducing suspicion. In those small transactions, after the bot granted real-token allowances, the child contract immediately transferred the real tokens, consuming the allowance and appearing completely legitimate. In contrast, during large-value transactions, the child contract did not call transferFrom to move real tokens; instead, it minted fake tokens directly via the forged trading pair. The bot believed it had completed normal pre-swap steps—but its real-token approvals remained intact. This is the crux of the entire attack: small transactions consume approvals normally; large transactions preserve them.
Detailed Attack Flow
Taking the USDC-targeted attack transaction as an example:
(1) The attacker called the coordinator to set the current block to “armed”;
(2) The attacker called the trigger to update the state of multiple forged Ring V2 pairs;
(3) The MEV bot detected the arbitrage opportunity and executed the transaction.
The internal flow of the MEV bot’s transaction is roughly as follows:
(1) The MEV bot contract granted a large USDC allowance to a child contract;
(2) The MEV bot called the child contract’s wrapTo/wrap function;
(3) Because the current state was “armed,” the child contract did not consume real USDC; instead, it minted fake tokens into the pair—leaving the USDC allowance intact;
(4) The MEV bot proceeded to call swap on the forged pair;
(5) The second-hop pair sent tokens to the MEV bot;
(6) The hub contract paid the MEV bot a small amount of real USDC profit.
The MEV bot observed what appeared to be a successful arbitrage trade yielding real USDC profit—but its USDC allowance remained held by the child contract. This exact flow was repeated for USDC, USDT, and WETH, ultimately accumulating massive allowances. Finally, the attacker invoked the coordinator’s drain loop: as long as the MEV bot had previously granted allowances to the child contracts, those contracts could directly transfer the corresponding real tokens to the attacker.
Fund Flow Analysis
After the attack succeeded, the attacker’s address (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) received $2.87M USDC, $2.04M USDT, and 1,474 WETH. The attacker then swapped the stablecoins for ETH and transferred the ETH to the following four addresses:
– 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (~1,000 ETH)
– 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1,001 ETH)
– 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1,001 ETH)
– 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1,423 ETH)
Of these, 0xe3Da3 has already transferred 1,000 ETH to Tornado Cash; no further transfers have occurred from the other three addresses.
Conclusion
This attack demonstrates a highly sophisticated methodology: rather than directly exploiting contract code vulnerabilities, the attacker engineered specific arbitrage scenarios aligned precisely with the MEV bot’s operational logic—thereby tricking the bot into granting seemingly harmless approvals, which were later exploited to drain its assets. For arbitrage bots and MEV bots alike, relying solely on simulated profit estimates to assess route safety is insufficient. Especially when the arbitrage path involves unfamiliar contracts, forged tokens, or custom wrappers, caution is essential—and post-transaction allowance changes should be explicitly verified.
[Beosin]
Sophisticated Approval Hijacking: The New Standard in MEV Bot Exploitation—And Why It’s Worse Than Code Bugs
The $7.5M heist on June 21 targeting Jaredfromsubway.eth—one of Ethereum’s most prominent public MEV bots—marks a pivotal inflection point: the attack isn’t against smart contract vulnerabilities, but against the implicit trust in MEV bot behavior models. This is not a revertible flash loan exploit. It’s a behavioral trap baked into the very logic bots use to assess arbitrage profitability. Beosin’s breakdown reveals an attack of chilling elegance: small transactions consume approval allowances (to appear legitimate), large transactions preserve them (to enable later drain). This is a new class of exploit, and its implications extend far beyond a single bot.
The Core Innovation: Approval State Poisoning
The attacker’s masterstroke was deliberately engineering two distinct transaction paths within the same block—one for small arbitrage opportunities that behave as expected (grant → transferFrom → approval exhausted), and one for large ones where the transfer never occurs (grant → mint fake tokens → approval remains). This exploits a critical blind spot: most MEV bots simulate the token balance trajectory of the simulation transaction, not the lifecycle of the allowance itself.
This is not about token approval being “insecure”—ERC-20 approvals work as designed. The flaw is in the bot logic’s assumption that a successful pre-swap step implies safe withdrawal. In reality, the child contract—masquerading as a legitimate token wrapper—minted fake tokens post-approval, making the swap appear successful while preserving the attacker’s hold on the real allowance. The MEV bot got paid a tiny real yield (e.g., 20 USDC profit) to reinforce legitimacy, while granting 20,000 USDC in approval.
Fund Tracking: Controlled Liquidation, Not Panic
The $7.5M drained wasn’t immediately flushed. The attacker split it into $2.87M USDC, $2.04M USDT, and 1,474 WETH—then swapped stablecoins for 5.426 ETH across 4 addresses, each receiving ~1,000–1,400 ETH. Of these, only one (0xe3Da3) has already moved 1,000 ETH to Tornado Cash, suggesting phased laundering, not impulsive exit. The remaining three addresses sit idle—a sign of coordination or exchange onboarding准备. Tether and USDC were converted to ETH for liquidity reasons: ETH is more fungible across chains and DeFi protocols, while large stablecoin movements trigger stricter monitoring.
Why This Changes the Game for Market Participants
- For MEV Bot Operators (Retail & Institutional):
- Simulation ≠ Safety: Simulating the arbitrage path is no longer sufficient. Attackers can now control the state of any pool the bot interacts with (via the “trigger” contract), making forged paths appear arbitrageable.
- Approvals Must Be Verified Post-Execution: Bots should track whether
transferFromwas called on real tokens after granting approval—not just assume the pre-swap steps were safe. -
White-listing Isn’t Enough: Even “verified” addresses can be mimicked (e.g., the fake RING V2 pair). Bots need dynamic blackboxing of untrusted wrappers.
-
For Token Projects & DeFi Protocols:
- Wrapper Contracts Are High-Risk: Contracts that wrap real assets (e.g., “fUSDC”) are now prime attack surfaces unless their minting logic is strictly verified against underlying vaults.
-
Uniswap V2 Forks Are Especially Vulnerable: Forged pairs can be deployed instantly and mimic legitimate liquidity pools with minor naming deviations (e.g.,
fUSDC–fWETHvsUSDC–WETH). -
For Traders & Retail Users:
While the direct impact is on bots, the behavioral trust model isnow compromised everywhere. If an MEV bot can be fooled into granting massive approvals, what prevents the same trap on swaps? The answer: it’sOnly a matter of time.
Market Implications & Strategic Outlook
- Short-Term (1–4 Weeks): Expect a wave of MEV bot rewrites—likely resulting in reduced arbitrage speed, higher gas costs, and wider slippage for liquid MEV strategies. This could temporarily widen spreads on DEXs like Uniswap and Curve.
- Medium-Term (1–3 Months): Demand will surge for tools that do real-time approval auditing—either as part of bot wallets (e.g., Gnosis Safe modules) or as backend MEV filtering layers (e.g., Flashbots Protect v3 enhancements).
- Long-Term (6+ Months): This exploit accelerates adoption of:
- Approval decay mechanisms (e.g., time-bound or single-transaction allowances, similar to EIP-5173 proposals)
- Zero-knowledge verification of arb routes (e.g., proof that the swap path doesn’t include unverified wrappers)
- MEV insurance pools—though adoption remains nascent due to pricing complexity.
Final Verdict
This attack is not a bug. It’s a feature of the next进化 stage of Ethereum attacks: behavioral engineering over code exploitation. For the first time, attackers weaponized the bot’s own logic against it—not by reversing its code, but by mimicking its expectations.
The $7.5M loss is significant, but the real price is the erosion of a foundational assumption: that if a trade simulates profitably, it executes safely. In a world where attackers can arbitrarily set pool states and mint fake liquidity, that assumption is dead.
For experienced traders and operators: approval hygiene is now your primary attack surface—not code audits. Monitor allowance patterns across interactions, not just balances. And never trust a wrapper unless you’ve traced its minting permissions back to a verifiable vault.
This isn’t scare tactics—it’s the new baseline.