- by x32x01 ||
What is a Sandwich Attack? (Short)
A sandwich attack is an MEV (Maximal Extractable Value) tactic where an attacker “sandwiches” a victim’s on-chain trade: one transaction in front (front-run), the victim’s transaction, then one after (back-run). The attacker profits from the price movement caused by the victim’s trade.Step-by-step explanation (with UUID example)
1. A dApp submits a user order that includes an internal tracking id (UUID) in off-chain logs:victim_tx_uuid = "3fa85f64-5717-4562-b3fc-2c963f66afa6"
(Important: do not expose such identifiers publicly on-chain or in mempool-visible metadata.)
2. The victim’s transaction enters the public mempool: it’s a market buy for 100 TOKEN.
3. An attacker watching the mempool sees the intent and submits a higher-priority buy (front-run) that gets mined just before the victim.
4. Victim’s buy executes next, pushing the token price up (slippage).
5. Attacker immediately sells (back-run) into the newly elevated price and pockets the difference (minus gas/fees).
Numeric example - compute step-by-step (digit by digit)
This is a simplified AMM example to show the math clearly.
Initial price per TOKEN = $1.00.
Attacker front-runs and buys 100 TOKEN at $1.00 each.
Cost calculation:
100 × 1.00 = 100.00 → attacker pays $100.00
Victim’s buy executes and moves price to $1.05 per TOKEN (approx. 5% impact).
Attacker back-runs and sells 100 TOKEN at $1.05 each.
Revenue calculation:
100 × 1.05 = 105.00 → attacker receives $105.00
Gross profit (before fees) = 105.00 − 100.00 = 5.00 → $5.00
Subtract gas/priority fees (example: assume total gas = $2.00)
Net profit = 5.00 − 2.00 = 3.00 → $3.00
So, digit-by-digit:
100.00 (revenue) - wait, revenue was 105.00; correct steps:
1. cost = 100 × 1.00 = 100.00
2. revenue = 100 × 1.05 = 105.00
3. gross profit = 105.00 − 100.00 = 5.00
4. net profit = 5.00 − 2.00 = 3.00
(Real AMM math includes slippage curves, liquidity depth, price functions — this is illustrative only.)
What makes victims attractive?
High slippage tolerance set by the user or dApp.Large trade size relative to pool liquidity.
Broadcasting via the public mempool (no privacy / private relay).
Predictable fee/nonce behavior that allows precise front-running.
How UUIDs factor in (good vs bad)
Bad: If UUIDs or verbose metadata are placed on-chain or leaked in mempool-visible fields, they make it trivial for bots to correlate off-chain high-value orders with on-chain transactions.Good: Keep UUIDs strictly off-chain (for internal tracing) and avoid including them in any fields that will be broadcast publicly.
Defenses & mitigation (practical & prioritized)
1. Use private transaction relays (e.g., Flashbots / private RPCs): bypass the public mempool so MEV bots can’t see the pending tx.2. Tighten slippage tolerances: require minimal acceptable price impact (e.g., 0.5%–1%) so attackers have less room.
3. Limit order / batch auctions: use mechanisms that remove first-seen priority (limit orders or frequent batch auction windows).
4. Use time-weighted or randomized order submission patterns: avoid predictable fee/nonces that enable exact placement.
5. Slippage & impact UI for users: show estimated price impact and require the user to explicitly accept it.
6. Liquidity protection: increase pool liquidity for important pairs to reduce price impact.
7. Avoid exposing identifiers on-chain: never place internal order UUIDs or rich metadata in any mempool-visible transaction fields.
8. Monitoring & detection: log abnormal front/back run patterns and alert users or pause suspicious trades.
9. Protocol solutions: support fair ordering or on-chain ordering guarantees where possible (FO, auctioned ordering, etc.).
Additional notes (for dApp builders & traders)
For builders: treat UUIDs as internal secrets. Use them for server logs only; do not attach them as public calldata or as part of human-readable transaction memos.For traders: when using wallets, set conservative slippage and consider private execution options for large trades.
MEV is an economic phenomenon - reducing opportunity is usually done by reducing visibility or reducing price impact.
Sandwich Attack explained 
A sandwich attack is when an attacker front-runs your trade, your trade moves the price, and then the attacker sells into that higher price (back-run).Example: victim_tx_uuid = "3fa85f64-5717-4562-b3fc-2c963f66afa6" - if your order is visible in the public mempool and slippage is large, you’re at risk. Defend with private relays (Flashbots), tight slippage, limit orders, and never leak order IDs on-chain.