JaredFromSubway MEV Bot Drained for $7.5M in a Counter-MEV Honeypot

TL;DR

Over the weekend of June 20-21, 2026, the most prolific sandwich bot on Ethereum, jaredfromsubway.eth, was drained of roughly $7.5 million. The attacker did not break a smart contract or steal a private key. They built a counter-MEV honeypot: 66 fake token contracts mimicking WETH, USDC, and USDT, wired into fabricated arbitrage routes that the bot's own automated logic classified as profitable. Over 97 blocks the bot took the bait, approving attacker-controlled child contracts to spend its real tokens, and the attacker structured later routes so those ERC-20 allowances were never consumed or revoked. A single coordinator transaction then called all 66 child contracts at once, sweeping the bot's balances up to each open allowance. The loss broke down to about 1,475 WETH, 2.9 million USDC, and 2 million USDT. The operator posted an on-chain message demanding 2,150 ETH back, roughly half, within 48 hours. The funds had already moved through Tornado Cash.

Who Is JaredFromSubway?

If you have traded a low-liquidity token on Ethereum in the last three years, there is a decent chance jaredfromsubway.eth ate part of your trade.

The name is a pun stacked on a pun. The bot does sandwich attacks; Subway sells sandwiches; and "Jared from Subway" is the cultural shorthand for Jared Fogle, the chain's former pitchman. Etherscan tags the contract as "jaredfromsubway: MEV Bot 2." The operator is pseudonymous and has never made a verified public statement, so treat any origin anecdote attributed to "the team" as unconfirmed.

The bot is a sandwich searcher. Sandwiching is a form of Maximal Extractable Value (MEV), the profit a party can extract by controlling the ordering of transactions in a block. A sandwich works in three steps:

1. The bot spots a victim's pending swap in the mempool, one large enough to move the price in a pool.
2. It front-runs the victim with its own buy, pushing the price up.
3. The victim's trade executes at the worse price, and the bot back-runs with a sell, pocketing the difference.

The victim eats the slippage. The bot keeps the spread, minus gas.

Jared was extraordinarily good at it, and extraordinarily expensive to run. According to an EigenPhi performance appraisal covering roughly February 27 to May 8, 2023, the bot pulled in $40.65 million in gross revenue while burning $34.35 million in gas, for a net profit of about $6.3 million across 238,000 sandwich attacks against more than 106,000 victims. During the week of April 17, 2023, it landed transactions in over 60% of all Ethereum blocks and was, for a stretch, the single largest gas consumer on the network.

It kept evolving. A revamped "Jared 2.0" with more complex routing surfaced in August 2024. By one estimate, the bot was responsible for around 70% of all sandwich attacks on Ethereum between November 2024 and October 2025. In May 2026 it even front-ran a token swap by Vitalik Buterin, deploying over $1.14 million in WETH volume around a trade by Ethereum's co-founder.

So when Jared got drained, it was not a small fish. It was the apex predator of the mempool getting caught in a trap built specifically for it. And it is still running: the bot's primary address kept sending transactions within seconds of this writing.

What Is a Counter-MEV Honeypot?

A sandwich bot is, by design, indiscriminate. It does not care what token it trades or who deployed the pool. It cares about one thing: does this route look profitable? If the simulated math says yes, it acts, in milliseconds, with no human in the loop. That speed is the edge. It is also the attack surface.

A counter-MEV honeypot weaponizes exactly that reflex. Instead of trying to outbid the bot for block space, the attacker feeds it fake opportunities engineered so that taking the bait quietly hands over access to real funds.

Per the forensic breakdown published by the pseudonymous Yearn developer banteg, and corroborated by thirdweb's technical writeup, the attacker spent weeks on setup before pulling the trigger. The attacker's wallet first transacted about two weeks before the drain, consistent with a honeypot that took that long to build. The attack ran in three phases.

Phase 1: Deploy the decoys. The attacker deployed 66 counterfeit token contracts crafted to imitate WETH, USDC, and USDT, then paired them with fabricated liquidity pools. To a human these are obviously fake. To the bot's route scanner, they presented as ordinary "fake-DEX arbitrage" opportunities with small but real token profits attached.

Phase 2: Earn the bot's trust. Over 97 blocks, the bot was repeatedly offered small, genuine profits on these routes. Each time it engaged, it did what its sandwich workflow always does: it called ERC-20 approve() to let attacker-controlled helper contracts move its WETH, USDC, and USDT. On the early bait transactions, those allowances were consumed normally, so the bot booked a tiny profit and the routes looked legitimate. The honeypot was paying the bot to lower its guard.

Phase 3: Spring it. On later routes, the attacker structured the calls so the approvals were granted but never consumed. The allowances stayed open. Once enough dangling approvals had accumulated, a single coordinator contract called a withdraw function on all 66 child contracts in one transaction. Each child pulled the bot's balance, up to its open allowance, via transferFrom() and forwarded it to the attacker. The final move was not a trade at all. It was a direct sweep.

banteg described the design as a "block-armed switch." The same child contracts behaved two different ways depending on batch size. In small "unarmed" test batches, they acted like a normal, principal-consuming wrapper that handed the bot a small real profit. In large "armed" batches, they behaved like a fake mint that left the bot's approvals untouched. The bot could not tell the two modes apart, because on-chain both looked like the profitable routes it was built to chase. banteg's report identified 16 live WETH allowances of roughly 92.16 WETH each, which together account for the 1,474.58 WETH taken in the final drain. Add the stablecoin balances and the total comes to about $7.5 million, a figure independently put forward by both Blockaid and PeckShield.

The Root Cause: Dangling ERC-20 Approvals

The vulnerability here is not exotic. It is the same primitive behind years of wallet-draining phishing: the ERC-20 approval.

Under the EIP-20 standard, spending another address's tokens is a two-step dance. First the token owner calls approve(spender, amount), authorizing a spender up to some allowance. Then the spender calls transferFrom(owner, recipient, amount) to actually move the tokens, drawing down the allowance. The critical property: an approval persists on-chain until it is spent down to zero or explicitly overwritten. Granting an allowance and then walking away does not revoke it. It leaves a standing authorization that anyone holding the spender key can draw against at any later time.

Jared's bot granted approvals to external, attacker-controlled contracts as a routine step in its sandwich routine, and crucially:

• It did not verify that the counterparty contracts were legitimate before approving them.
• It approved more than the immediate transaction needed, or approved on routes where the allowance went unused.
• It did not revoke unused allowances afterward.

That is the entire bug. A standing, unconsumed allowance to a contract the attacker controls is a loaded gun pointed at the bot's treasury. The bot fired it itself, one fake arbitrage at a time.

This is the automated, industrial-scale version of the approval-phishing scams that drain retail wallets every day. A user who signs an unlimited approve() to a malicious dapp can be drained weeks later via transferFrom(), long after they have forgotten the interaction. Jared's bot did the same thing to itself, 66 times, at machine speed, because its profit-seeking logic had no concept of approval hygiene.

Security firm Blockaid summarized the class plainly after the incident: attacker-controlled contracts tricked an automated execution system into granting token approvals that were later used to drain funds. No reentrancy, no oracle manipulation, no signature forgery. Just trust extended to an unverified counterparty and never withdrawn.

How the Attack Worked, Step by Step

The drain was widely reported by June 22, 2026, with banteg's forensic report circulating that Sunday.

How Much Was Stolen: $7.5 Million, Not $15 Million

One discrepancy is worth flagging directly, because numbers matter.

On-chain forensics put the loss at about $7.5 million: roughly 1,475 WETH, $2.9 million in USDC, and $2 million in USDT. That figure was put forward independently by security firms Blockaid and PeckShield, matches banteg's transaction-level accounting, and is consistent across Protos, Gizmodo, Decrypt, and The Block.

The $15 million figure comes from the operator's own framing and was repeated by several outlets, including a Yahoo Finance piece built around the operator "speaking out" and one Cryptobriefing article. No on-chain analysis corroborates it. It is also undercut by the operator's own recovery demand: a request to return 2,150 ETH as "half." At the ETH price implied by the WETH leg of the drain (around $1,750), 2,150 ETH is roughly $3.7 million, which is half of $7.5 million, not half of $15 million. The lower figure is the one the on-chain record supports. Treat $15 million as the operator's unverified self-report.

The On-Chain Bounty: Jared Offers the Attacker 50%

After the drain, the bot operator did what drained protocols increasingly do: negotiated on-chain. The message, sent on June 22, was almost cheerful about it:

"Well played. We are willing to offer a 50% white hat bounty if you return 2150 ETH to this address in the next 48 hours, otherwise we will pursue all available legal and law-enforcement remedies."

The message was not a press release. It was an on-chain transaction, sent on June 22, 2026 at 02:15 UTC (block 25,370,085) from jaredfromsubway.eth directly to the attacker's address, carrying the text in its Input Data Message field. Anyone can read it on the block explorer.

2,150 ETH was roughly half the take, about $3.7 million at the time. At the ETH price on the explorer the day after the drain (about $1,729), the arithmetic lines up with a $7.5 million loss, not the $15 million the operator floated elsewhere.

There are two problems with that posture.

First, the funds had already entered Tornado Cash. A note on terminology, since it gets misreported constantly: Tornado Cash is a smart-contract mixer, and OFAC removed it from the SDN list in March 2025, so it is not a "sanctioned" protocol as of this writing. It is, however, still an effective way to break the on-chain link between deposit and withdrawal. Once funds are mixed, a "return half or we sue" message is aimed at someone who is, by construction, hard to identify.

Second, the moral high ground is thin. This is a bot that extracted tens of millions of dollars by degrading the execution price of more than 100,000 strangers' trades, with no consent and no bounty. The legal theory under which involuntary slippage extraction is legitimate business but counter-MEV is theft is, to put it gently, untested. As of this writing, there is no public indication the attacker returned anything.

Why This Matters for Every Autonomous On-Chain Bot

It is tempting to read this as karma and move on. The more useful reading is technical, because the failure generalizes to a fast-growing class of software: autonomous, capital-handling agents that act on-chain without a human in the loop.

MEV searchers, arbitrage bots, automated treasury managers, and the new wave of AI-driven trading agents all share Jared's core property. They observe the chain, decide in milliseconds, and sign transactions that move real money, optimizing for a single objective: profit. An adversary who understands that objective can craft an environment where the optimal-looking action is the self-destructive one. The bot is not hacked so much as persuaded, by a world built to deceive it.

That is the deeper lesson of a honeypot. Input validation for a smart contract is about rejecting malformed calldata. Input validation for an autonomous agent is about rejecting a malicious reality: fake pools, fake tokens, fake profits, all individually valid on-chain. The bot's logic was working exactly as designed. The design simply had no concept of "this counterparty might be lying to me at scale."

Lessons for Builders of On-Chain Agents

1. Approve the exact amount, then revoke. Never grant an open-ended or larger-than-needed allowance to a contract you do not control. Approve the precise amount a transaction requires and set the allowance back to zero afterward. A dangling approval is a standing liability, not a convenience.

2. Verify the counterparty before you trust it with approve(). An autonomous system that approves any contract its route scanner points it at has no authorization model at all. Maintain allowlists of known-good routers and tokens, and treat newly deployed tokens and pools as hostile until proven otherwise. The same failure class drained 86 Gnosis Safes in the SquidRouterModule exploit: trust extended to a contract that should never have had it.

3. Simulate adversarially, not just for profit. The bot simulated whether a route was profitable. It did not simulate whether a route was a trap. Pre-execution simulation should model the worst case (what can this counterparty do with the access I am about to grant?), not only the expected payoff. Tooling like transaction-simulation and risk-detection services exists for exactly this.

4. Cap the blast radius. No single approval, and no single coordinator call, should be able to reach the entire treasury. Segregate operating capital from reserves, use per-strategy hot wallets with bounded balances, and rate-limit outflows. Jared lost everything in one transaction because everything was reachable in one transaction.

5. An optimizer with no constraints is a target. Any agent that maximizes a metric without hard safety constraints can be steered by whoever controls its inputs. For on-chain agents, the inputs are public and cheaply forgeable. Constraints (allowlists, caps, revocation, kill switches) are not overhead. They are the only thing standing between your bot and a purpose-built environment designed to feed it poison that looks like profit.

The most efficient predator in the mempool was undone not by a faster bot or a higher gas bid, but by a patient attacker who understood that the bot would believe whatever the chain told it. That is a problem every builder of autonomous on-chain software now has to solve.

Frequently Asked Questions

What is jaredfromsubway.eth? jaredfromsubway.eth is Ethereum's most prolific MEV sandwich bot, active since early 2023. It front-runs and back-runs traders' swaps to extract value, and by some estimates was behind roughly 70% of all sandwich attacks on Ethereum between late 2024 and 2025.

How was the JaredFromSubway bot drained? An attacker built a counter-MEV honeypot: 66 fake token contracts mimicking WETH, USDC, and USDT with fabricated liquidity pools. The bot's logic read them as profitable arbitrage and granted ERC-20 approvals to attacker-controlled contracts. The attacker left those approvals unconsumed, then a single coordinator transaction called transferFrom across all 66 contracts to sweep the bot's balances.

How much did JaredFromSubway lose? About $7.5 million: roughly 1,474.58 WETH, $2.9 million in USDC, and $2 million in USDT. Blockaid and PeckShield put the figure there independently. A higher $15 million number came only from the operator's own framing and is not corroborated on-chain.

What are dangling token approvals? Under ERC-20, a spender can move your tokens only after you call approve(), and that allowance persists on-chain until it is spent to zero or revoked. A dangling approval is an allowance granted to a contract that was never consumed or revoked, leaving a standing authorization an attacker can draw against later via transferFrom().

Was the stolen money recovered? No. The operator sent an on-chain message offering a 50% white-hat bounty for the return of 2,150 ETH within 48 hours and threatening legal action, but the funds had already been swapped to ETH and partly routed through Tornado Cash, with no public sign of a return.

Sources / References

• Notorious 'jaredfromsubway' MEV bot drained for roughly $7.5 million in counter-MEV honeypot — The Block
• MEV bot JaredFromSubway.eth loses $7.5M to approvals honeypot — Protos
• Infamous Front-Running Crypto Bot 'Jaredfromsubway' Gets Tricked and Drained for $7.5M — Gizmodo
• Jaredfromsubway.eth MEV Bot Exploited for $7.5M — What Builders Need to Know — thirdweb
• JaredFromSubway MEV bot exploited for over $15M (figure unverified) — Cryptobriefing
• Performance Appraisal of Jaredfromsubway.eth — EigenPhi
• Jaredfromsubway.eth is back with a new MEV bot and new sandwich attacks — The Block
• Jaredfromsubway bot front-runs Vitalik Buterin's token swap — CoinDesk
• Ethereum MEV Bot JaredFromSubway Threatens Legal Action After $7.5 Million Loss — Decrypt
• Ethereum's Most Notorious MEV Bot Loses $7.5 Million in On-Chain Honeypot Trap — BeInCrypto
• Ethereum's Jaredfromsubway MEV bot drained after approving its own $7.5M theft — CryptoSlate
• Tornado Cash Delisting — U.S. Department of the Treasury (March 21, 2025)
• EIP-20: Token Standard — Ethereum Improvement Proposals