# 20 — The case of the sandwich around the mint > Scenario file: `scenarios/sandwich_attack.yaml` Severity observed: MEDIUM (HIGH in low-liquidity pools) Time-to-reproduce: 8 minutes The sandwich is the workhorse MEV attack. Search any Solana mempool feed for fifteen minutes during a busy hour and you will find one. We model it here not because it is novel, but because most of the protocols we have looked at do not realise *they* are the venue being sandwiched. ## The setup A protocol mints LP tokens proportional to its share of a Raydium-style pool. The mint instruction reads the pool's reserves, computes the user's share, and issues LP tokens accordingly. The bug is in the assumption. The protocol assumes the reserves it reads are the reserves that will be in the pool *at the moment the user's deposit lands*. They are not. Between the protocol's read and the user's deposit, an arbitrary number of swaps can land. An adversary watching the mempool can make sure of that. ## The attack The adversary sees a victim's deposit transaction in the mempool. They construct a triple: 1. **Front-run**: a swap that moves the pool's price against the victim, increasing the spot price of the asset the victim is depositing. 2. **Victim's transaction**: the original deposit, which now mints fewer LP tokens than the victim expected because the pool's price has moved. 3. **Back-run**: a swap that reverses the front-run, restoring the price and capturing the spread. The victim's loss equals the spread the adversary captures, minus the gas of the three transactions. On Solana, where priority fees are predictable, the math almost always works in the adversary's favour for deposits above a few hundred dollars. ## What the fuzzer does `sandwich_attack.yaml` orchestrates the three transactions in the same simulated block. The conservation invariant is evaluated against the *victim*: did they receive LP tokens worth what they deposited? The genetic fuzzer (chapter 70) is particularly useful here. The profitability of a sandwich depends on three parameters — the front-run size, the back-run size, and the fee tier. The fuzzer's genetic search converges on the parameters that maximise adversary profit per attack. We have run this search against six AMM-fronting protocols; in five of them, the search found a parameter triple worth more than $200 per victim transaction. ## The fix Sandwiches cannot be prevented at the protocol level on a public chain. They can be made unprofitable. The standard mitigation is a slippage parameter: the user supplies a `min_lp_tokens_out`, and the mint reverts if the actual mint would be lower. This shifts the cost from the user to the adversary — the adversary's front-run still works, but the victim's transaction reverts and pays only a base fee. The adversary's back-run is now a loss-making swap with no offsetting gain. ```rust let lp_out = compute_lp_amount(reserves, deposit); require!(lp_out >= min_lp_tokens_out, MintError::Slippage); ``` The slippage parameter has to come from the user, not from a constant. A constant slippage cap that is generous enough for a $10 deposit is a license to print money on a $10,000 deposit; that is the inverse of the protection it pretends to be. The hardening index entry is `SANDWICH-1`. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://economicfuzz.gitbook.io/economicfuzz-docs/case-studies/20-case-sandwich-around-mint.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.