Hours later, the attacker attempted to convert the stolen stablecoins into ETH via a decentralized exchange. That's when the operation fell apart — not because of a protocol exploit, but because the attacker failed to set slippage protection on the swap. An automated MEV bot detected the pending transaction in the public mempool and executed a classic "sandwich attack": it bought ETH just before the attacker's swap (driving the price up), allowed the attacker's purchase to fill at the inflated price, then immediately sold its ETH position for a profit .

The bot extracted approximately $371,000 of the stolen funds, paying roughly 3.5 ETH in gas fees to secure the transaction ordering. The attacker walked away with only about 67 WETH (~$129,000) — a net loss of over 74% of the stolen haul .

How the MEV sandwich attack worked

A sandwich attack is a form of maximal extractable value (MEV) exploitation that relies on transaction ordering in a public blockchain mempool. Here's how the bot pulled it off :

1. Mempool monitoring: MEV bots continuously scan the public mempool for large, pending swap transactions with weak slippage tolerances.
2. Front-running: The bot spots the attacker's swap (buying ETH with USDC) and immediately submits its own buy order for ETH ahead of the attacker's transaction.
3. Victim fills in the middle: The attacker's swap executes at the now-higher price, receiving less ETH for the same amount of USDC.
4. Back-running: The bot sells its ETH immediately after the attacker's transaction completes, profiting from the price difference.

In this case, the attacker used Uniswap V4 without setting a slippage cap, giving the bot nearly unlimited room to manipulate the execution price across the transaction batch .

What this reveals about DeFi security

• MEV bots operate as impartial opportunists. They don't distinguish between legitimate traders and criminals. Any transaction visible in the public mempool with weak slippage settings is a target, regardless of who sent it .
• Slippage protection is non-negotiable. The attacker set the swap without a tight slippage tolerance, allowing the bot to manipulate the execution price across multiple blocks. A small slippage cap would have prevented most of the loss .
• DeFi's transparency cuts both ways. The same open mempool that makes DEX trading permissionless also makes large, poorly configured trades easy for bots to front-run and sandwich .
• Phishing is still the most common entry vector. The initial theft relied on a compromised wallet, not a protocol exploit. User-side security — approvals, signatures, and wallet hygiene — remains the weakest link .

Key lessons for users

1. Always set a tight slippage tolerance — typically 0.5%–1% for large swaps on liquid pairs. Never use "auto" or infinite slippage .
2. Use MEV-protected RPC endpoints or private mempool services (e.g., Flashbots Protect, BloxRoute) to keep transactions out of the public mempool .
3. Revoke unused token approvals regularly. The victim here had given a phishing signature that allowed the attacker to drain USDC directly .
4. Test large swaps with small amounts first — especially after gaining control of funds from any suspicious source.
5. Understand that blockchain transparency can backfire — having the private keys does not guarantee safe execution if the transaction is publicly visible and poorly parameterized .

The incident serves as a stark reminder that in DeFi, technical sophistication matters at every step — even criminals can lose to better-automated adversaries when they ignore basic transaction hygiene.

Hours later, the attacker attempted to convert the stolen stablecoins into ETH via a decentralized exchange. That's when the operation fell apart — not because of a protocol exploit, but because the attacker failed to set slippage protection on the swap. An automated MEV bot detected the pending transaction in the public mempool and executed a classic "sandwich attack": it bought ETH just before the attacker's swap (driving the price up), allowed the attacker's purchase to fill at the inflated price, then immediately sold its ETH position for a profit .

The bot extracted approximately $371,000 of the stolen funds, paying roughly 3.5 ETH in gas fees to secure the transaction ordering. The attacker walked away with only about 67 WETH (~$129,000) — a net loss of over 74% of the stolen haul .

How the MEV sandwich attack worked

A sandwich attack is a form of maximal extractable value (MEV) exploitation that relies on transaction ordering in a public blockchain mempool. Here's how the bot pulled it off :

1. Mempool monitoring: MEV bots continuously scan the public mempool for large, pending swap transactions with weak slippage tolerances.
2. Front-running: The bot spots the attacker's swap (buying ETH with USDC) and immediately submits its own buy order for ETH ahead of the attacker's transaction.
3. Victim fills in the middle: The attacker's swap executes at the now-higher price, receiving less ETH for the same amount of USDC.
4. Back-running: The bot sells its ETH immediately after the attacker's transaction completes, profiting from the price difference.

In this case, the attacker used Uniswap V4 without setting a slippage cap, giving the bot nearly unlimited room to manipulate the execution price across the transaction batch .

What this reveals about DeFi security

• MEV bots operate as impartial opportunists. They don't distinguish between legitimate traders and criminals. Any transaction visible in the public mempool with weak slippage settings is a target, regardless of who sent it .
• Slippage protection is non-negotiable. The attacker set the swap without a tight slippage tolerance, allowing the bot to manipulate the execution price across multiple blocks. A small slippage cap would have prevented most of the loss .
• DeFi's transparency cuts both ways. The same open mempool that makes DEX trading permissionless also makes large, poorly configured trades easy for bots to front-run and sandwich .
• Phishing is still the most common entry vector. The initial theft relied on a compromised wallet, not a protocol exploit. User-side security — approvals, signatures, and wallet hygiene — remains the weakest link .

Key lessons for users

1. Always set a tight slippage tolerance — typically 0.5%–1% for large swaps on liquid pairs. Never use "auto" or infinite slippage .
2. Use MEV-protected RPC endpoints or private mempool services (e.g., Flashbots Protect, BloxRoute) to keep transactions out of the public mempool .
3. Revoke unused token approvals regularly. The victim here had given a phishing signature that allowed the attacker to drain USDC directly .
4. Test large swaps with small amounts first — especially after gaining control of funds from any suspicious source.
5. Understand that blockchain transparency can backfire — having the private keys does not guarantee safe execution if the transaction is publicly visible and poorly parameterized .

The incident serves as a stark reminder that in DeFi, technical sophistication matters at every step — even criminals can lose to better-automated adversaries when they ignore basic transaction hygiene.