An Ethereum trading bot lost $7.5M. Its own permissions did the draining.
JaredFromSubway.eth was built to hunt weak trades, then got caught by the same approval shortcut that made it fast.
CryptoVibe Desk · ethereum · mev · defi
- →JaredFromSubway.eth lost $7.5M after an attacker set up fake sandwich trades over 97 Ethereum blocks.
- →The loss matters because the bot approved attacker contracts to spend real WETH, USDC, and USDT.
- →Watch the next 48 hours for a return deal, because the operator offered 2,150 ETH for half the funds back.
- MEV → MEV is money made by ordering blockchain transactions in a way that benefits the trader doing the ordering.
- Sandwich bot → A sandwich bot buys before another user's trade and sells after it, taking value from the price move.
- Token approval → A token approval lets another contract spend your tokens until you revoke or limit that permission.
As of June 22, $7.5M left JaredFromSubway.eth. The mechanism was not a mystery exploit. It was approval hygiene failing at machine speed.
The attacker ran a honeypot across 97 consecutive blocks, according to Protos and Yearn developer Banteg's technical breakdown. The fake setup showed small profitable sandwich trades on attacker-made token pairs. JaredFromSubway.eth took the bait, then approved attacker-controlled child contracts to spend real assets.
At the contract level, this is simple. The bot thought it was granting temporary access for a profitable route. The approvals stayed live. Once enough permissions existed, the attacker used one final drain transaction.
Protos reports the drain included about 1,475 WETH, worth $2.6M as of June 22, plus $2.9M USDC and $2M USDT. The verified total is $7.5M, not the $15M figure that moved around X before Cointelegraph deleted its repost.
If you've ever approved a random contract and forgotten about it, this is your bag in a cleaner suit. The only difference is scale. JaredFromSubway.eth had 6.4 million lifetime transactions across two bots, per Protos. That history made it efficient, but also gave attackers a large behavior pattern to study.
This is a permissions problem, not a consensus problem. The bot's edge depends on moving fast through routes that look profitable. Checking every spender like a paranoid wallet slows the machine down. Skipping that check turns approvals into stored risk.
The predator got drained by a better predator. A sandwich bot still has an attack surface, and the profitable path can be the malicious one.
The operator later sent an on-chain message offering 2,150 ETH for roughly 50% of the stolen funds back within 48 hours, per Protos. That turns the exploit into a live negotiation, for now. It does not change the lesson.
Read the approvals, not the thread. The code did what the bot allowed it to do. The attacker just waited until the permission graph was fat enough to harvest.
JaredFromSubway.eth's operator treating approvals as disposable throughput was reckless because the bot's profit loop gave attacker contracts persistent spend rights over WETH, USDC, and USDT.
Within the 48-hour offer window, watch whether the attacker returns about 2,150 ETH or instead moves the drained WETH, USDC, and USDT through fresh addresses.
Primary links and supporting reads used by the desk for this story.
Forward this.
