The Sandwich Attack

Web3 space is like a dystopian wild west intergalactic planet with no law or rules, where you either eat or get eaten.

Today, we'll explain how you've probably been eaten (sandwiched) if you've been in the Web3 space long enough.

What is a Sandwich Attack?

Every time you make a trade on a decentralized exchange, you broadcast your intentions to the entire world before the transaction confirms.

It sits in a public waiting room, called "The Mempool", which is visible to anyone who knows how to look.

Your token, your amount, and crucially, your slippage tolerance: the maximum price increase you're willing to accept before the trade fails.

A sandwich attack exploits exactly this — an attacker watches The Mempool for your pending trade, jumps in front of it, and profits from the price movement your own transaction creates.

You are the meat. Their two transactions — one before yours, one after — are the bread.

How does a Sandwich Attack work?

Here's how it happens, step by step:

1. Let's say you want to buy $10,000 USD worth of tokens on Uniswap, and you've set a 3% slippage tolerance—this means you'll accept up to $300 above the expected price for the transaction to still confirm.
2. The attacker sees your pending transaction before it confirms.
3. They know what you're buying and how much price movement you'll accept.
4. So they immediately submit their own buy for the same token, cutting in front of you in the block.
5. This pushes the price up.
6. Your transaction then executes at the inflated price — still within your slippage limit, so it doesn't fail.
7. The moment your trade clears, the attacker sells everything they just bought directly into your liquidity.
8. They bought before you moved the price.
9. You moved the price for them.
10. They sold into it.
11. You paid more than you should have. They kept the difference.
12. The whole thing happens in a single block, in under a second, and you never see it coming.
13. The bigger your trade, the wider your slippage tolerance, the fatter the sandwich.

The predator

Named with dark humor after the disgraced Subway spokesman, jaredfromsubway.eth (0xae2f...fae13) is not a person. It's a bot — a machine built from Solidity code and ruthless math, running without sleep across every pool it can reach.

Most sandwich bots are narrow — they pick a few tokens, a few pools, and stay in their lane.

Jared is everywhere.

No matter the token, no matter how many hops the route takes, if there is profit to be extracted from your pending transaction, Jared will be there.

At its peak, the bot was one of the top gas consumers on the entire Ethereum network — burning millions in fees just to stay at the front of the line — and it still printed money.

Tens of millions of dollars, extracted one ordinary trader at a time, for years.

Then, on June 21st 2026, someone decided to cook him a sandwich of his own.

The setup

The attacker didn't find a bug in Jared's code. There was nothing to crack open. Instead, they studied the one thing they knew for certain: how the bot thinks.

Jared's bot is built to find profitable trade routes. If it sees a sequence of swaps across pools that yields more tokens out than tokens in, it fires. Automatically. Speed and greed, wired together.

So the attacker built a trap that looked exactly like profit.

They deployed over a hundred fake Uniswap V2-style liquidity pools, each backed by fake ERC20 tokens — fake WETH, fake USDC, fake USDT.

The pools had the right interface, the right structure, deep apparent liquidity.

From the outside they were indistinguishable from the real thing.

Then they engineered trade routes through these fake pools that showed a small but real profit for whoever ran them.

Just enough to make Jared's bot salivate.

The patience

The attacker began submitting fake swaps into these pools.

Jared's bot noticed.

It backran them, executing arbitrage routes through the fake pools as designed.

And here is the critical part: to execute any swap on-chain, the bot first had to approve the pool contract to spend its real tokens — WETH, USDC, USDT.

Under normal circumstances, an approval gets consumed during the swap. The tokens move, the allowance clears, everything looks clean.

But these routes were engineered differently. The paths pulled in the fake dummy tokens, not the real ones. The bot's real tokens were never actually touched. Which meant the approvals were never revoked. They just sat there, silently accumulating.

The bot didn't notice. It thought these were standard Uniswap contracts. It even made small real profits on each fake route, which kept its detection systems quiet and satisfied.

The attacker couldn't simply drain the funds mid-bundle either. Jared runs atomic transaction bundles — if anything inside the bundle fails, the whole thing rolls back. The dummy tokens were the only way to let approvals build up without triggering a revert. The trap required patience. So the attacker was patient.

The drain

After dozens of these interactions, the attacker had quietly accumulated 50 live spending allowances against Jared's contract — 16 over his WETH, 20 over his USDC, 14 over his USDT.

Eighteen minutes after the last approval was set, they used them.

One clean transaction — transferFrom — called 50 times. No exploit. No flash loan. No vulnerability in the code. Just permissions that the bot itself had willingly signed, one "profitable" trade at a time.

The attacker drained:

• 4759 WETH
• 3.58M USDC
• 2.53M USDT

All of it drained into the attacker's helper contract at 0x3e37...65d0.

Around $14 million USD — gone.

The bot's balance dropped from $25M to $4.4M in a single block.

Some of it moved through Tornado Cash shortly after.

What actually happened

The attacker didn't hack Jared. They turned the bot's own reflexes against it.

No code was broken. No key was stolen. The attack worked entirely because Jared was built to move fast, trust profitable-looking routes, and never clean up its approvals. The approvals were the weapon. The bot handed them over voluntarily, a few at a time, convinced it was making money.

In the mempool, everyone can see your intentions before the transaction confirms.

Jared built a fortune on that fact, and then someone used it against him.

And that's how the sandwich maker got eaten as the fattest sandwich in Web3 history.