What Does a Sandwich Searcher Extract?
Place a searcher before and after the user, then compare minimum output, pool price, and extracted difference.
- Explain how a front-run changes the user's output
- Use minimum output as a slippage boundary
- Separate searcher profit, pool fees, and user loss
- PREVIOUSWho Can See a Trade Before It Executes?
- CURRENTWhat Does a Sandwich Searcher Extract?
Place a searcher before and after the user, then compare minimum output, pool price, and extracted difference.
- NEXTWho Back-runs the Price Gap a User Creates?
Think about these questions first.
Choose an answer before opening the explanation. You can add anything unexpected to your review list.
Q01If the user transaction succeeds, how can a sandwich still harm it?＋
Success only means no revert, not fair execution. The attacker moves the pool first, the user fills near the allowed worst price, and the attacker reverses; the loss is hidden in poorer output.
A sandwich is not simply “the pool was hacked.” It uses public intent and the AMM curve: a searcher changes reserves before the user, lets the user execute in the worse state, then sells back to turn part of the price impact into extraction.
Put three trades in one order
In a plain public scenario, a block may contain only the user swap. In a sandwich, the searcher proposes:
- Front-run buy: consume some TOKEN depth first;
- User swap: execute against the new reserves;
- Back-run sell: sell the TOKEN bought in front.
Who gets to choose the order?
Put one swap into a deterministic pool, then watch visibility, ordering, slippage protection, and extraction change the result.
Run the same public sequence with a loose and a tight minimum-output guard.
- 01Mempoolintent is visible→
- 02Block orderwho goes first→
- 03Statereplayed by nodes
A mempool record is not a fill. The block order is not a payout. Only execution moves balances and pool reserves.
Searcher profit, proposer tip, pool fees, and user output live on the same ledger.
Submit one user swap first. The key question is not whether the transaction is valid, but who can see and order it before it becomes shared state.
- 01
Public pool created: 120,000 credits + 1,000 TOKEN, any public transaction can change the next quote.
Use the slider to return to an earlier step. Continuing from there replaces the later history with a new sequence.
Compare the user's quoted output with actual output. A loose minimum-output guard accepts a worse fill; a tight guard reverts the user trade, so the searcher cannot treat a failed transaction as a completed sale.
Expand: how this step works
front = swap(searcher, X → Y)
victim = quote(pool_after_front, X → Y)
if victim.amountOut < victim.minOut:
revert(victim)
else:
execute(victim)
back = swap(searcher, Y → X)
Production protocols also handle atomicity, gas auctions, private bundles, router minimums, and multi-pool routes. This lab keeps the smallest state machine that makes the asset flow visible.
What does a minimum-output guard protect in a sandwich?
Read one extraction on one ledger
Keep the user's missing TOKEN, the searcher's credit change, pool fees, and the proposer's possible ordering tip together. Otherwise every negative price impact looks like the same kind of attack.