The Predator Becomes the Prey: How a Counter-MEV Honeypot Drained $7.5M from JaredFromSubway

Executive Summary

On June 20, 2026, one of the most active onchain MEV bots on Ethereum, known as JaredFromSubway, was drained of roughly $7.5M in WETH, USDC, and USDT. The attack was a counter-MEV honeypot, an attack that turns an automated bot's own profit-seeking logic into the mechanism that drains it. The attacker built a fake market of impostor tokens and rigged liquidity pools designed to look like legitimate trading opportunities. When the bot took what appeared to be profitable trades, it granted token approvals to the attacker-controlled contracts behind those fake assets. Those approvals stayed open, and the attacker later used them to sweep the bot's holdings in a single transaction.

Blockaid had flagged the attacker's wallets and contracts as malicious before the final drain. Because these entities were marked malicious across Blockaid's network, all Blockaid-enabled wallets and exchanges would have been warned away from interacting with them. Blockaid also posted a public alert flagging the attacker addresses and the exploit transaction as the incident unfolded.

This report explains how the counter-MEV honeypot worked and where Blockaid's coverage applied. It also carries a lesson for a far broader audience than MEV operators. The mechanism that drained this bot was automated execution granting standing approvals to unvetted counterparty contracts. That is a risk shared directly by market makers, trading firms, and institutions running automated strategies onchain.

MEV Bots, Automated Execution, and Token Approvals

An MEV (maximal extractable value) bot is an automated program that scans a blockchain for profitable trading opportunities and executes them without a human approving each one. Many operate at the expense of ordinary users, extracting value from their trades. Speed is the entire edge, so the bot's logic identifies an opportunity and the bot's own wallet signs and submits the trade in the same automated loop. JaredFromSubway is one of the best-known examples, a sandwich and arbitrage bot that has run this strategy at scale for years.

The sandwich strategy is what earned the bot its name. When the bot spots a pending trade large enough to move a token's price, it places its own order just ahead of it, lets the victim's trade execute at the now-worse price, and sells immediately after to capture the difference. Repeated across tens of thousands of transactions, this functions as a kind of invisible tax on ordinary DeFi users. JaredFromSubway accounted for an estimated 70% of all sandwich attacks on Ethereum.

That automation rests on a specific trust assumption. Whoever controls what the bot perceives as a profitable opportunity controls what the bot does. To execute almost any onchain trade, a system has to grant a token approval, a permission that authorizes a specific contract to move a specific amount of a token out of the wallet. Approvals are routine and required for normal DeFi activity, but they are also standing permissions. Once granted, an approval remains open until it is used or explicitly revoked. An automated system that trades assets it has not vetted, and grants approvals to the contracts behind those assets, is extending trust to counterparties it never independently verified. That assumption is what the attacker targeted, and it is not unique to sandwich bots.

The Exploit: How it Unfolded

1. The Setup

The attacker, operating from wallet 0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0, constructed an entire fake market for the bot to trade in. This included 66 attacker-deployed token contracts that impersonated real assets, returning names such as "Wrapped Ether" so the bot would treat them as legitimate WETH, USDC, and USDT, along with fake counter tokens and UniswapV2-style liquidity pools to give the impostor assets a tradeable market. All 66 contracts were deployed by the same attacker-controlled factory and shared identical code, an indicator that they were a single coordinated family rather than independent assets.

Each impostor token carried a hidden backdoor. Buried in the contract was an owner-only withdraw function (selector 0x51cff8d9), callable only by the attacker, that executed a transferFrom pulling the victim's tokens to the attacker up to the standing approval amount. To the bot, these looked like ordinary tokens and pools. In reality, every one of them was an instrument designed to be approved and later drained.

2. The Bait

The attacker arranged the prices in the fake pools so that trading the impostor tokens looked profitable to the bot's opportunity engine. The bot's automated logic, scanning for arbitrage, saw what appeared to be a small, clean profit and acted on it.

In an early bait leg, the bot approved real WETH to attacker helper contracts at roughly 0.6 WETH per leg, routed through the attacker's fake pools, and received back marginally more than it put in, about 0.603 WETH for 0.602 WETH, a real onchain profit of roughly 0.00112 WETH. The trade settled successfully and looked like a normal win. From the bot's perspective it had found an opportunity, executed it, and profited. What it had actually done was grant a standing approval to an attacker-controlled contract and prove to the attacker that the bait worked.

3. Accumulating the Approvals

The attacker repeated the pattern, letting the bot win each time and scaling the size up with each round. The standing approvals the bot granted to the helper contracts grew across many trades, climbing from roughly 0.007 WETH to 0.6, then 8.6, then 10.1, and ultimately about 92.16 WETH per contract. In total, the bot issued 423 approval events to the attacker's helper contracts across 42 transactions.

The final and largest bait leg ran roughly six blocks before the drain, with the bot granting six separate approvals of about 92.16 WETH each to attacker helper contracts, each leg again returning a fractional profit to keep the logic satisfied. By this point, large standing approvals sat open across the full family of 66 impostor contracts, every one of them armed and waiting.

4. The Drain

With the approvals in place, the attacker pulled the lever. In one transaction, 0x2be8704f...bcf3e65 (block 25360696, June 20, 2026, 18:49:11 UTC), sent from 0x5aF38735B215b00aa7C9f93fEd7ee415CeCB36e1, a sweep contract at 0xb84db016324e8F2BFdD8DD9c260338AEE0A8DF52 called the hidden backdoor across all 66 impostor contracts at once. Each backdoor used its standing approval to transferFrom the bot's real assets into the attacker's wallet.

The sweep moved 1,474.58 WETH, 2,870,573 USDC, and 2,035,760 USDT to 0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0, roughly $7.5M in total. The bot never made a decision at the moment of the drain. It had already authorized every transfer, trade by trade, while believing it was profiting.

5. Laundering the Funds

After the sweep, the attacker routed the stolen stablecoins through the CoW Protocol Settlement contract and converted them back into WETH. No funds were recovered.

The Response: Real-Time Flagging and Public Disclosure

As the attack was unfolding, Blockaid flagged the attacker's wallets and the 66 malicious contracts as malicious. That flag is shared across Blockaid's network in real time, so any Blockaid-enabled wallet, exchange, or protocol that encountered the attacker's infrastructure was warned or blocked from interacting with it. The same protection extends to anyone moving funds onchain who might otherwise interact with these contracts without knowing what they were, including the trading firms and institutions who leverage automated systems in their strategies.

Blockaid also moved to protect the wider ecosystem, posting a public alert that named the affected bot contract, the exploit transaction, and the attacker-controlled wallets so others could steer clear of the attacker's infrastructure.

Flagging the attacker's infrastructure and its related contracts in real time is what prevents an incident like this from cascading across the ecosystem, where other participants unknowingly interact with the same malicious contracts and extend the damage. Raz Niv, Blockaid's Cofounder and CTO, characterized the attack itself in Cointelegraph: "This was a counter-MEV honeypot attack, as it specifically targeted the automated, trust-minimized decision-making logic that MEV bots utilize."

Why Blockaid’s Cosigner Matters for Automated Onchain Trading

The mechanism that drained this bot was an automated execution system granting standing approvals to attacker-controlled contracts, and then those approvals being used to pull funds. Strip away the fact that the victim was a sandwich bot, and what remains describes a large share of institutional onchain activity. Market makers, quantitative and high-frequency trading desks, DeFi-native prop firms, and treasury automation systems all run automated execution that discovers opportunities and signs to capture them, and all of them grant token approvals to do it. Any automated system that interacts with an asset it has not vetted can be lured into approving an attacker-deployed contract that looks legitimate, and because approvals are standing permissions, every open approval is a permanent attack surface that can be drained up to its limit with no further action from the victim.

This is the layer Blockaid’s Cosigner is built to protect. Cosigner sits at the transaction signing layer and validates every transaction against a defined policy before it is signed and broadcast. A firm running automated execution can configure a Cosigner policy that treats an approval to any contract flagged as malicious, or to any non-allowlisted counterparty, as a policy violation and blocks it at the point of signing. In this incident, the attacker's helper contracts were flagged as malicious across Blockaid's network, so a system running Cosigner that attempted to approve those malicious contracts would have been stopped before the first standing approval was ever armed, which is the step that made the eventual sweep possible.

A disciplined firm with a curated allowlist of tokens and venues, tight approval caps, and a risk system gating new counterparties is harder to bait than an open-season bot that trades anything the instant it looks profitable. That discipline matters, but consistently enforcing it on every transaction is a control most desks aspire to more than they reliably hold, and the failure mode is total when it slips. Cosigner enforces that discipline at the signing layer, automatically and on every transaction, so a single lapse in vetting does not turn into a loss.

How Blockaid’s Onchain Monitoring Surfaces Threats Across the Ecosystem

Every team operating onchain is exposed to far more than the contracts it controls. The tokens an automated system trades, the pools it routes through, and the counterparties it interacts with are largely outside any single firm's control, and that external surface is exactly where this attack lived. The 66 impostor tokens and their pools were attacker-owned infrastructure that appeared, to an automated trader, indistinguishable from a legitimate opportunity.

A signing-layer control protects the approvals a firm grants. Onchain Monitoring covers the surrounding surface: the malicious tokens, pools, and spender contracts circulating in the venues and routes that automated systems touch. Because Blockaid analyzes behavior and maintains ecosystem-wide labeling, a malicious token or spender family identified in one context propagates as a signal to every integrated party, so the next firm whose automated logic encounters that family inherits the warning rather than discovering the trap on its own. A token approval is "valid" at the contract level even when the counterparty behind it is a backdoor, which is why permission-based and contract-level checks miss this category. Continuous behavioral monitoring catches it because it evaluates what a contract actually does and how an actor behaves, not only whether a given transaction was permitted.

This same capability has in the past surfaced attacks before they even initiate the fund drain. In a separate incident on the deprecated Aztec Connect rollup, Blockaid's Onchain Monitoring flagged the attacker's preparation roughly six minutes before the draining transaction executed, catching the attack while it was still forming rather than after the funds had moved. The counter-MEV honeypot and the Aztec drain are different exploits, but they share a root where  the threat assembled on infrastructure outside the victim's control, in a place permission models and contract-level checks never looked. Continuous monitoring of that external surface is what turns a developing attack into something a team can see coming.

Securing the Future of Automated Onchain Trading

The counter-MEV honeypot is a preview of where onchain trading risk is heading. As institutional capital increasingly runs through automated execution, the most important question shifts from "is my contract secure" to "can my automated logic be manipulated by the market data and counterparties it is built to trust." The attacker here did not break any cryptography or compromise any key. They understood how an automated system makes decisions and constructed an environment that made the system drain itself, patiently, through transactions that each looked like a win.

Defending automated trading therefore requires controls at the two layers this incident exposed. Prevention at the signing layer stops a system from granting approvals to counterparties it should never trust, and monitoring of the external surface surfaces the malicious tokens, pools, and spenders that automated logic will otherwise treat as ordinary. The firms that operate automated strategies onchain at scale, and the institutions allocating capital into them, will be the ones that layer both before an incident rather than after. As automated execution grows and the tooling attackers use to bait it improves, that combination is what keeps a manufactured opportunity from becoming a manufactured loss.

Conclusion

The JaredFromSubway drain shows a category of attack that does not fit the usual exploit playbook. The attacker understood how an automated system makes decisions, built a market that system was designed to find profitable, and let the bot authorize its own draining one trade at a time. The result was roughly $7.5M swept in a single transaction, and the same logic that made the bot profitable for years is what made it drainable.

The lesson reaches every team running automated execution onchain. Standing token approvals are an accumulating attack surface, and automated logic can be turned against its owner by the counterparties it is built to trust. The defenses that hold are the two layers this incident exposed. A signing-layer control blocks approvals to malicious and non-allowlisted contracts before they are ever granted, and continuous monitoring of the external surface covers what automated systems cannot vet on their own. As more capital moves to automated onchain trading, those are the controls that keep a fabricated opportunity from becoming a real loss.

About Blockaid

Blockaid is the onchain security platform trusted by the largest companies operating in Web3. Built by veterans of elite intelligence and cybersecurity units, Blockaid provides end-to-end protection for financial institutions, protocols, and end users, combining direct wallet and dApp integrations with real-time monitoring, detection, and response across smart contracts, infrastructure, and externally owned accounts. Since 2025, Blockaid scanned over 6.3 billion transactions and blocked 585 million attacks. Blockaid is the security infrastructure behind Coinbase, MetaMask, Uniswap, Safe, and dozens of the most widely used platforms in the industry.

Learn more at blockaid.io, and follow us on Twitter and LinkedIn.