SandwichCheck
Forensic guide

How to detect a sandwich attack

Detection starts with the victim transaction, reconstructs its position in the block, and tests whether the surrounding activity matches an economically coherent attack.

Evidence to examine

  1. Confirm the swap. Decode the router call and identify the pool, tokens, direction, input amount, and output constraints.
  2. Locate it in the block. Record the exact transaction index and successful or reverted receipt.
  3. Inspect nearby swaps. Look before and after the victim for trades involving the same pool.
  4. Link the legs. Test whether the surrounding transactions share a sender, funding source, builder bundle, or token-flow relationship.
  5. Verify direction and economics. A typical attacker buys before the victim, sells after it, and ends with positive net value after gas and fees.

What counts as a strong signal?

A same-pool transaction immediately before the victim and an opposite-direction transaction immediately after it, both controlled by the same actor, is a strong structural signal. Execution traces and balance changes make the conclusion more reliable.

A mempool record is not required after mining. Pending transactions normally disappear from the mempool when included. The mined block, receipts, logs, traces, and state changes preserve the evidence needed for post-trade analysis.

Avoiding false positives

Arbitrage, liquidations, routing across multiple pools, and unrelated swaps can resemble parts of a sandwich. Do not label a victim from adjacency alone. Check ownership links, exact swap direction, asset flows, gas costs, and realized profit.

Analyze a transactionFull methodologySupported networks