Jaredfromsubway.eth Sandwich Bot Drained for $7.5M After Approval-Logic Exploit
An attacker used weeks of fake tokens and liquidity pools to bait lingering approvals, then pulled WETH, USDC and USDT and routed some funds to Tornado Cash.
An attacker drained more than $7.5 million from Ethereum’s notorious jaredfromsubway.eth MEV sandwich bot by manipulating its automated trading and approval logic rather than exploiting a conventional smart-contract bug. The setup relied on fake tokens and liquidity pools to induce standing approvals, which were later used to transfer WETH, USDC and USDT out of the bot’s contracts, with some proceeds sent to Tornado Cash.
Key Takeaways
- More than $7.5 million was drained from jaredfromsubway.eth by turning its automated trading and approval logic against it, not via a typical contract vulnerability or standard phishing.
- The attacker spent weeks deploying dozens of fake token contracts and fake liquidity pools that mimicked WETH, USDC and USDT to bait the bot into approving attacker-controlled helper contracts.
- The loss hinged on routes where token approvals stayed open, leaving standing permission that enabled transfers of WETH, USDC and USDT out of the bot’s contracts.
- Some of the stolen funds were later routed through Tornado Cash, complicating attribution and recovery.
Ethereum’s Biggest Sandwich Bot Loses $7.5M in an Approval-Logic Trap
Jaredfromsubway.eth, one of Ethereum’s most visible MEV sandwich bots, was drained for more than $7.5 million after an attacker manipulated the bot’s automated decision-making. The incident did not hinge on a classic smart-contract bug in the victim’s contracts, and it was not framed as a normal phishing event. The failure point was the bot’s own automation layer, where it generated permissions that later became usable against it.
The victim is notorious because sandwiching is not subtle. A sandwich bot watches the mempool, buys ahead of a pending swap, lets the victim execute at a worse price, then sells immediately after to capture the spread. At scale, that becomes a hidden execution cost that traders feel as worse fills and, often, higher gas competition.
What stands out here is the inversion. A system built to industrialize extraction from other traders got extracted by someone who understood its operational habits.
The Multi-Week Setup: Fake Tokens, Fake Pools, Real Approvals
The attacker’s edge was patience. Over several weeks, they deployed dozens of fake token contracts and fake liquidity pools designed to resemble legitimate venues and assets, including mimics of WETH, USDC, and USDT. The goal was not to break a contract. It was to manufacture “opportunities” that the bot’s pattern-recognition logic would treat as tradable routes.
Once the bait was in place, the bot did what it was built to do. It detected what looked like MEV opportunities and generated token-spend approvals for helper contracts. Those helper contracts were attacker-controlled.
Early on, the approvals were used immediately as part of the trade routes during tests. That detail matters because it shows the attacker was iterating on the bot’s behavior, not firing a single-shot exploit. Later, the attacker shifted to routes where approvals stayed open. That change turned a one-time permission into something closer to an ongoing capability.
This is the decision-layer failure that “industrialized MEV” tends to underprice. If your system can approve spend at machine speed based on profit signals, then the attacker’s job becomes shaping the signals, not cracking the code.
Why Lingering Token Approvals Became the Drain Valve
Token approvals are mundane until they are not. An approval is simply permission for a contract to spend tokens on behalf of a wallet or another contract. In normal DeFi flows, approvals are often granted to enable swaps or routing. The risk is operational: if approvals persist, they can outlive the context that made them safe.
In this case, the attacker engineered routes where approvals stayed open. That left standing permission in place for attacker-controlled helper contracts. With that permission, the attacker could transfer assets out of the bot’s contracts without needing to “re-win” the bot’s decision process each time.
The drained assets included WETH, USDC, and USDT, and the total loss was more than $7.5 million.
The pattern worth noting is that this was not a vulnerability hunt. It was a permissioning trap. Once approvals remained active, they effectively became a withdrawal right against whatever balances the bot’s contracts held in those tokens. That is a different class of risk than most traders think about when they hear “exploit.”
On-Chain Follow-Through Signals After the Drain
After the drain, some of the stolen funds were routed through Tornado Cash. The amount routed was not specified, but the direction is clear: mixing reduces the usefulness of straightforward on-chain tracing and raises the bar for clean attribution.
From a market-structure perspective, there are three practical signals to monitor next.
First, follow-on movements from the attacker-linked addresses, especially additional Tornado Cash deposits and any later withdrawals that could indicate consolidation or off-ramping attempts.
Second, whether any approvals or allowances tied to the bot’s helper-contract pathways remain active. The exploit depended on approvals staying open. If any similar permissions persist, the risk is not theoretical.
Third, changes in sandwich-attack frequency and the share attributed to jaredfromsubway.eth. The bot has been associated with roughly 70% of Ethereum sandwich attacks, and sandwiching was estimated to cost traders about $60 million a year, with 60,000 to 90,000 attacks per month between November 2024 and October 2025. If this bot’s activity drops materially after the drain, traders should be watching whether the “gap” is filled by other actors or whether overall sandwiching pressure eases.
A public postmortem from security teams, including details on how the approval-routing logic was induced and how similar MEV systems can harden against it, would be the cleanest confirmation of whether this was a one-off operational miss or a repeatable playbook.
This Wasn’t a Contract Bug—It Was MEV Automation Getting Social-Engineered
I’m treating this as a case study in how MEV operations actually fail. The attacker didn’t need a conventional vulnerability if they could reliably induce approvals to attacker-controlled helper contracts. That is the core lesson, and it’s grounded in the mechanics here: fake tokens and pools were used to manufacture routes, the bot generated approvals, and the attacker later leaned on approvals that stayed open to pull WETH, USDC, and USDT.
There are two scenarios that matter for traders watching execution quality on Ethereum.
Scenario one is containment and degradation. If the drain forces jaredfromsubway.eth to revoke approvals, isolate contracts, or otherwise slow down automation, you would expect its sandwich footprint to shrink at least temporarily. The confirmation point is simple: a measurable drop in sandwich frequency or share attributed to this actor versus the historical baseline of 60,000 to 90,000 monthly attacks and the bot’s roughly 70% association. The invalidation point is equally clear: activity snaps back quickly with no visible change in on-chain behavior, implying the operational hit did not meaningfully impair the machine.
Scenario two is substitution. Even if this bot’s activity declines, sandwiching does not disappear just because one dominant actor takes a hit. The market structure incentive remains. The confirmation point here would be a stable overall sandwich rate even as attribution shifts away from jaredfromsubway.eth. The invalidation point would be a broad decline in sandwiching pressure that persists beyond a short disruption window.
The second-order effect I care about is what this does to “industrialized MEV” design choices. This exploit path is about approvals that persist. If MEV systems respond by tightening approval scope, shortening allowance lifetimes, or adding stricter route validation, that can reduce this specific failure mode but may also slow execution or reduce hit rate. That trade-off is not abstract. It is the business model.
Tornado Cash routing pushes expectations toward containment rather than quick recovery. Once mixing enters the flow, the practical question becomes whether any remaining approvals can still be used as a drain valve, not whether funds can be neatly clawed back.
The thesis is straightforward: this incident shows that the weakest link in machine-speed MEV is often the decision layer, and it will be confirmed if on-chain data shows lingering approvals were the durable capability that enabled repeated transfers out of the bot’s contracts.
