Was My Swap Sandwiched? Compare the Quote and Execution

A worse swap execution than the quote does not, by itself, prove that someone sandwiched your trade. A quote estimates an output from a particular pool state; execution happens later, after transactions may have changed that state. To assess a sandwich, compare the quoted route and bounds with the transaction’s actual route, the pool’s state changes, and the order of transactions in the block.

What does a swap quote actually promise?

A quote is a calculation, not a reservation of tokens or a promise of execution at that price. A decentralized exchange router typically uses current pool reserves to estimate how much of the output token a trade will receive. In a constant-product pool, trading one asset changes the reserve ratio, which changes the price available to the next trade. A quote can become stale while the transaction waits to be included.

The transaction usually carries a minimum acceptable output, often derived from a slippage setting. If the route cannot deliver at least that amount when executed, the swap should revert instead of completing below the bound. A successful trade can still return less than the quoted output, as long as it meets the minimum. The route may also use multiple pools, so checking only one pool’s price can miss where the difference arose.

Wallet tools and token charting sites may show useful context around a BSC wallet’s activity, but the quote, transaction and block data answer different questions. For more background on the wallet-side workflow, see this guide to using Poocoin with a BSC wallet. It can help orient a token check; it does not establish why a particular swap received its output.

What evidence points to a sandwich attack?

A sandwich is a transaction-ordering pattern around a victim swap. An attacker’s buy or other price-moving trade executes before the victim’s transaction, and a later trade executes after it, often reversing the attacker’s position. The intervening trade worsens the price available to the victim; the attacker seeks to profit from the resulting movement. A low output alone is not enough to identify this pattern.

Inspect the victim transaction’s block and trace the relevant swaps in execution order. Compare the pool reserves and route immediately before the victim executes with the state after any preceding trades. Then look for a related transaction before and after it that trades the same assets through the same pool or route. A pattern across those transactions is stronger evidence than a gap between a wallet quote and final output.

• Record the quoted route, expected output and time of the quote.
• Read the transaction’s minimum output and actual output from its receipt.
• Follow each pool in the executed route and note reserve changes before and after the swap.
• Check transaction ordering for trades that bracket yours and move the same pool price.

How can you tell execution drift from a sandwich?

Execution drift can result from ordinary price movement between quote and inclusion, competition from other swaps, or differences between the quoted and executed route. Network delay gives the pool more time to change; a larger trade can also move a pool’s price more against itself because it consumes a greater share of available reserves. These mechanisms can lower output without a coordinated attacker.

Start with the receipt: confirm the transaction succeeded and compare actual output with the minimum output encoded in the transaction. Then reconstruct the route and ordering from the block. If the output is below the original quote but above the minimum, the quote-to-execution difference is real, but its cause remains open until the pool changes and neighboring transactions support an explanation. If the transaction reverted, it did not complete the swap, though it may still have incurred a network fee.

The practical test is comparative: quote against execution, then execution against pool state and block order. Slippage bounds limit how far execution can move before a swap fails; they do not identify who caused the movement. Call a swap sandwiched only when the transaction sequence supports that conclusion.