OAK — OnChain Attack Knowledge

Worked example · 2026-06

jaredfromsubway.eth — a counter-MEV honeypot lures the sandwich bot into leaving standing token allowances, then sweeps them — Ethereum — 2026-06-20

Loss
~$7.5M realised. On 2026-06-20 (~18:49 UTC) the well-known Ethereum MEV bot jaredfromsubway.eth was drained of genuine WETH, USDC and USDT in a single sweep transaction. Blockaid put the loss at about $7.5M and classified it as a "counter-MEV honeypot," explicitly not phishing, not a private-key compromise, and not a protocol contract bug. An operator-linked X account claimed a higher ~$15M figure; that claim is unverified and no reporter could confirm the account's link to the bot, so OAK records ~$7.5M as the corroborated figure. No funds were recovered as of the Chainalysis writeup on 2026-06-26.
OAK Techniques observed
OAK-T4.004 (Allowance / Approve-Pattern Drainer — primary mechanism. The abused primitive is the ERC-20 approve() / allowance: when a spender is granted an allowance and a trade does not fully consume it, the leftover allowance stays standing, and the holder can later call transferFrom() to move the victim's tokens up to that amount with no new signature. The attacker structured trade routes so the bot's own routing logic granted allowances to attacker-controlled helper contracts that were then left partly or wholly unused. Once enough standing allowances had accumulated, a coordinator contract swept the bot's real WETH/USDC/USDT in one atomic transaction. See techniques/T4.004-allowance-approve-drainer.md). OAK-T6.006 (Counterfeit Token Impersonation — the bait was roughly 66 fake token contracts mimicking the names and interfaces of WETH, USDC and USDT, each paired with sham liquidity pools so the routes looked like the profitable arbitrage and sandwich opportunities the bot was built to hunt). The stolen stablecoins were swapped to ETH within minutes and about 1,000 ETH was deposited into Tornado Cash (OAK-T7.001).
Attribution
unattributed. No named individual or group. Funds were traced to an attacker address reported as beginning 0x3e37 (single-source), consolidated into roughly 4,427 ETH before the mixer hop. The operator-linked account offered a bounty for return of funds; the bounty amount and the account's authenticity are both unverified. Blockaid's classification is quoted consistently across outlets, though no standalone Blockaid post was located; Chainalysis published the fund-tracing analysis on 2026-06-26.
Key teaching point
A standing ERC-20 allowance is a live liability, and an automated trader that leaves them open can be baited into being drained without any key compromise or phishing. The bot was not tricked into signing anything out of band; its own routing logic issued legitimate approvals during trades that under-consumed them, and the attacker collected those dangling allowances until a single transferFrom sweep across ~66 contracts was worth the trap. The size-dependent behaviour is the trap's core: on small test trades the granted allowance was fully consumed, so the routes looked benign, while larger trades were structured to leave the approval open. The controls that break this are exact-amount approvals rather than unlimited ones, zeroing out allowances after each route instead of leaving them standing, validating token contracts and pools before interacting, and monitoring for non-consumed allowances as a red flag. The case also inverts OAK's existing jaredfromsubway.eth entries, where the same bot is the sandwich attacker (see examples/2023-02-jaredfromsubway-mev.md); here the automation that industrialised extracting value from others' trades was itself turned by a trap built against its approval behaviour.

Summary

jaredfromsubway.eth is Ethereum's best-known sandwich and front-running MEV operation, active since early 2023 and frequently the network's single largest daily gas spender. Reporting attributes roughly 70% of Ethereum sandwich attacks between November 2024 and October 2025 to it. The bot scans for profitable routes and executes them automatically, granting ERC-20 approvals to spender contracts as a normal step in its own pipeline.

Weeks before the drain, an attacker deployed about 66 fake token contracts that copied the names and interfaces of WETH, USDC and USDT and paired them with sham liquidity pools, so the routes resembled the opportunities the bot hunts. To trade those routes the bot approved attacker-controlled helper contracts to spend its real tokens. On small transactions the allowance was fully consumed inside the trade, so nothing looked wrong. On larger transactions the routes were structured so the allowance was left standing after the trade. Repeated across the fake contracts, open allowances accumulated.

On 2026-06-20, once enough standing allowances had built up, a coordinator contract called withdraw across all the child contracts at once; each called transferFrom() against the bot's balance up to its open allowance and forwarded the genuine WETH, USDC and USDT to the attacker, draining about $7.5M in one atomic transaction. The stolen stablecoins were swapped to ETH within minutes to avoid issuer freezes, consolidated into roughly 4,427 ETH, and about 1,000 ETH was routed through Tornado Cash. No funds were recovered.

Timeline (UTC)

When Event OAK ref
Weeks before 2026-06-20 Attacker deploys ~66 fake token contracts mimicking WETH/USDC/USDT plus sham pools T6.006 (bait)
Ongoing Bot's routing logic grants approvals to attacker helper contracts to trade the routes; small trades fully consume the allowance and look benign T4.004 setup
Ongoing Larger trades are structured so the allowance is left standing; open allowances accumulate across the fake contracts T4.004 accumulation
2026-06-20 ~18:49 A coordinator contract calls withdraw across the child contracts; each transferFrom()s the bot's real WETH/USDC/USDT up to its open allowance; ~$7.5M swept in one transaction T4.004 extraction
2026-06-20 (minutes later) Stablecoins swapped to ETH; consolidated to ~4,427 ETH; ~1,000 ETH deposited to Tornado Cash T7.001
2026-06-26 Chainalysis publishes fund-tracing analysis; no funds recovered (third-party forensics)

What defenders observed

  • Pre-event (unvetted token contracts and pools). The bait depended on the bot interacting with contracts it had not validated. Validating token contracts and pools before trading, and treating unvetted contracts as hostile, is the pre-event control; speed-over-diligence on automated routing is what the trap exploited.
  • At-event (standing allowance as the live liability). The extraction needed no key and no new signature, only accumulated approve() grants that later trades did not consume. Exact-amount approvals and post-route allowance revocation remove the standing liability entirely. Non-consumed allowances after a completed route are the red-flag signal.
  • At-event (size-dependent benign behaviour). The trap behaved benignly on small trades and left approvals standing on large ones, so sampling small interactions would not have surfaced it. Allowance monitoring has to cover the full trade, not a sampled subset.
  • Post-event (fast conversion to ETH, then mixer). Stablecoins were swapped to ETH within minutes to pre-empt issuer freezes, then partly mixed. Once value reaches the mixer hop inside the same window as the drain, on-chain recovery is foreclosed, which matches the outcome here.

Public references

Discussion

This is OAK's approve-pattern anchor for an automated victim rather than a phished human. T4.004 usually covers a drainer that harvests allowances from users tricked into signing; here the same primitive is turned against a bot whose own routing logic grants approvals, with the twist that the trap is patient, accumulating standing allowances across many fake-token routes until a single sweep is worthwhile. The counterfeit tokens (T6.006) are the bait that makes the routes look profitable, and the size-dependent behaviour is what keeps the trap hidden during the accumulation phase.

The case is worth preserving for two reasons. First, it restates the standing-allowance liability in a setting where there is no user to phish and no key to steal, which sharpens the control set toward exact-amount approvals and post-route revocation rather than user education. Second, it inverts the corpus's earlier jaredfromsubway.eth entries: the bot that automated extracting MEV from others' trades was drained by automation built to exploit its approval behaviour. The neutral reading is that any automated trader leaving allowances open carries a live liability regardless of what side of the trade it usually sits on, and the defensive unit is the allowance lifecycle, not the identity of the operator.

Techniques demonstrated (3)