What Is a Sandwich Attack? Complete DEX Safety Guide

A sandwich attack is a type of DEX execution attack where a bot places one transaction before a user's swap and another transaction after it. The goal is to profit from the price movement created around the user's trade. In simple terms, the victim's transaction becomes the middle of a “sandwich”: the attacker's first transaction pushes the price against the user, the user's swap executes at a worse price, and the attacker's second transaction closes the position for profit. If you are new to DEX swaps, start with How DEX Swaps Work because sandwich attacks are easier to understand once swaps, liquidity pools, slippage, price impact, minimum received, mempools, and transaction ordering are separated.

Sandwich attacks matter because a swap can succeed on-chain while still giving the user worse execution than expected. Many beginners only ask whether a transaction failed or succeeded. In DEX trading, that is not enough. A successful transaction can be economically poor if the user allowed high slippage, traded into shallow liquidity, ignored price impact, used a public transaction path during volatile conditions, or confirmed a minimum received value that was much lower than the quote. For the execution boundary behind this issue, read What Is Minimum Received?.

This guide explains what sandwich attacks are, how they relate to MEV, front-running, back-running, slippage, price impact, liquidity depth, AMMs, mempools, block builders, private transaction routes, DEX aggregators, and wallet safety. It also covers practical scenarios, common mistakes, explorer verification, long-tail questions, and beginner safety habits. This page is neutral education only. It does not recommend any specific DEX, wallet, token, chain, private RPC, builder, relay, aggregator, trading strategy, MEV protection service, or transaction.

Quick answer

A sandwich attack is a DEX attack pattern where a bot trades before and after a user's swap to exploit the user's slippage tolerance and the price movement caused by their trade. It matters because the user's swap may execute successfully but at a worse price. Before confirming a DEX swap, users should check slippage tolerance, minimum received, price impact, pool depth, token contract, route details, wallet prompt, and the final transaction result on the correct block explorer.

Simple example: A user wants to buy a token in a shallow AMM pool and sets high slippage. A bot sees the pending swap, buys the token first to push the price up, lets the user's buy execute at the worse price, and then sells after the user's swap. The user receives fewer tokens while the bot profits from the price movement. That is the basic sandwich pattern.

Why sandwich attacks matter

Sandwich attacks matter because they turn normal DEX mechanics against the user. DEX pools are designed to adjust prices as trades move through liquidity. This is how AMM markets function. A trade that is large compared with pool depth naturally moves the price. A sandwich bot tries to position transactions around that movement so the user absorbs worse execution.

The user often does not see the attack before signing. The swap screen may show a quote, a slippage setting, and a minimum received value. The wallet prompt may look normal. The transaction may succeed. But if the transaction was publicly visible before execution and the trade had enough slippage tolerance or enough price impact, a bot may have been able to reorder trades around it.

This is why sandwich attacks are not only a technical MEV topic. They are a user-experience and safety topic. A beginner who does not understand slippage may set a high tolerance because a social post said “increase slippage if the swap fails.” A trader may push a large order through a thin pool. A token buyer may ignore minimum received. A DEX user may assume that a successful transaction means fair execution. Sandwich attacks exploit those gaps.

The most important safety boundary remains the same: public blockchain information and secret wallet information are different. A wallet address, token contract, pool address, route, transaction hash, and explorer link can usually be checked publicly. A private key, seed phrase, recovery phrase, Secret Recovery Phrase, password, recovery code, device unlock code, or remote device access should never be entered into a DEX page, MEV protection form, sandwich recovery site, liquidity rescue tool, fake refund page, or wallet validation link. If a site asks for wallet secrets, read How to Avoid Crypto Scams before doing anything else.

Useful next step: If sandwich attacks feel complex, read What Is MEV in DEX?, What Is Front-Running?, What Is Price Impact?, and What Is Max Slippage Risk?. Those pages explain the surrounding concepts that make sandwich attacks possible.

The basic idea behind a sandwich attack

A sandwich attack has three parts. First, the attacker places a trade before the user's swap. Second, the user's swap executes after the attacker's first trade. Third, the attacker places another trade after the user's swap. The attacker is trying to profit from the price movement caused by the user's own transaction and the user's accepted execution range.

In an AMM pool, prices move when reserves change. If a bot buys before the user, it can push the price up. If the user is also buying and has enough slippage tolerance, the user's transaction may still execute at the higher price. Then the bot sells after the user, capturing the difference. The user receives fewer output tokens than they would have received without the attacker's surrounding trades.

The same basic pattern can appear in the opposite direction when the victim is selling. The attacker can trade before the victim to move the price against the sale, allow the victim's sale to execute at worse output, and then trade back after. The details depend on the asset pair, AMM formula, route, pool depth, fees, slippage tolerance, and transaction ordering.

1. The user's transaction is visible or targetable

A sandwich attacker needs information about a pending or targetable swap. On some networks or transaction paths, pending transactions can be observed before they are included in a block. On other paths, order flow may be routed differently. The key idea is that the attacker finds a transaction worth trading around.

2. The user allows enough execution room

Slippage tolerance and minimum received determine how much worse the final output can be before the transaction fails. Wide tolerance gives more room for the user's swap to execute at a worse price.

3. The pool can be moved

Shallow liquidity, high price impact, volatile tokens, and large trade sizes can make a pool easier to move. A deep pool may require much more capital to manipulate around a user.

4. The attacker captures the spread

The attacker's first and second trades are designed to profit from the price change around the user's trade after accounting for fees, gas, priority costs, and execution risk.

5. The user's swap may still succeed

A sandwich attack is especially confusing because the user's transaction may not fail. The user may simply receive worse output while the explorer shows a successful transaction.

Sandwich attack versus front-running

Sandwich attacks and front-running are related, but they are not identical. Front-running generally means an actor places a transaction before another transaction to gain an advantage. A sandwich attack includes a front-run transaction before the user's trade and a back-run transaction after the user's trade. The user is trapped between the two attacker transactions.

A simple front-run can happen without a back-run. For example, an actor may buy before a known buy pressure event or claim an opportunity before another transaction. A sandwich attack has a more specific DEX execution structure: move the price before the victim, let the victim trade at the worse price, then unwind after the victim.

This distinction helps users understand why sandwich attacks often connect to slippage and AMM liquidity. The attacker is not merely “going first.” The attacker is using the user's accepted execution range and the pool's pricing mechanics to extract value from the swap. For more detail, read What Is Front-Running?.

Sandwich attack versus MEV

MEV stands for maximal extractable value. It refers to value that can be extracted from transaction ordering, inclusion, or exclusion. A sandwich attack is one type of MEV strategy in DEX environments. Not all MEV is a sandwich attack. Some MEV can involve arbitrage, liquidations, back-running, rebalancing, or other transaction-ordering opportunities.

Sandwich attacks are one of the most user-visible MEV problems because they can directly worsen swap execution. A user sees a worse fill. The attacker captures value. The transaction may still look normal to a beginner because it succeeded and transferred tokens as allowed.

MEV discussions can become highly technical, but the user-facing lesson is practical. Large trades, shallow pools, wide slippage, public transaction routing, volatile tokens, and low-liquidity launches can increase exposure to poor execution. The user should review swap parameters before signing. For the broader topic, read What Is MEV in DEX?.

Sandwich attack versus normal price impact

Normal price impact is not the same as a sandwich attack. Price impact is the effect of the user's own trade on the pool price. If a user makes a large trade in a shallow pool, the output can be worse even with no attacker involved. The AMM curve itself causes the average execution price to move.

A sandwich attack adds adversarial ordering around that trade. The attacker intentionally moves the price before the user and then reverses after the user. From the user's perspective, both normal price impact and sandwich activity can lead to worse output, but the causes are different.

This distinction matters because users should not blame every bad fill on a sandwich attack. A bad result may come from high price impact, low pool depth, route changes, token taxes, fees, volatility, or a sandwich. Explorer review and surrounding transaction analysis can help, but it can still be hard for beginners to prove the exact cause. Start by reading What Is Price Impact?.

Sandwich attack versus slippage

Slippage is not the same as a sandwich attack, but slippage tolerance can make sandwich attacks easier to execute. Slippage tolerance defines how much worse the final output can be compared with the quote before the swap should fail. If a user sets very wide slippage, the transaction may still succeed after the price is moved against them.

A common beginner mistake is treating high slippage as a universal fix for failed swaps. High slippage may help a transaction execute in volatile or taxed-token conditions, but it can also allow poor execution. If the route is shallow and visible, wide slippage can provide room for MEV bots to trade around the swap.

Minimum received is the practical boundary. If the user accepts a very low minimum received amount, they are accepting a wide range of possible bad outcomes. The safest habit is not simply “set low slippage” or “set high slippage,” but to understand why a swap needs a given tolerance and whether the minimum received value is acceptable. Read What Is Max Slippage Risk? for the detailed version.

How AMM pools create sandwich opportunities

Automated market makers quote prices from liquidity. In a simple constant product pool, reserves define price. When a user buys one asset, they add the input asset to the pool and remove the output asset. The reserve ratio changes, so the price changes. Larger trades move the pool more. This design is what allows wallet-connected swaps without a traditional order book, but it also creates predictable price movement.

Predictable price movement can attract bots. If a bot sees that a user's trade will move the price and that the user's slippage tolerance allows a worse fill, the bot can calculate whether surrounding the trade might be profitable. The bot must account for pool fees, transaction costs, priority costs, competition from other bots, and execution risk. If the expected profit is positive, the bot may attempt the attack.

Concentrated liquidity can change the shape of this problem. Liquidity may be very deep near the current price and thin outside a range. A trade that crosses ranges can move through uneven liquidity. Stable pools can reduce price movement near a stable target but may still become vulnerable under imbalance or stress. The general principle remains: sandwich opportunities become more attractive when a trade creates predictable movement and leaves enough room for profitable surrounding transactions. For AMM mechanics, read What Is a Constant Product AMM?.

Why pool depth matters

Pool depth is one of the biggest factors in sandwich risk. A deep pool can absorb a trade with less price movement. A shallow pool moves more easily. If a user trades a large amount relative to pool depth, the trade creates a bigger target for bots because the price movement is more meaningful.

Pool depth is not the same as market cap. A token can have a large displayed market value but weak tradable liquidity. A token can be popular on one network but shallow on another. A token can have several pools, but the route selected by a DEX may still be thin. Users should check usable route depth, not only token name, logo, chart, or social media hype.

Depth can also change quickly. Liquidity providers can add or remove capital. Incentives can start or end. New token liquidity can migrate. A pool can become imbalanced. During volatile launches, depth may be unstable. A user checking a trade should evaluate current route conditions, not old screenshots. Read What Is Pool Depth? for the liquidity side of the problem.

Why minimum received matters

Minimum received is the lowest amount of output the user is willing to accept before the swap should fail. This field is one of the most important defenses against bad execution. If the minimum received value is too low, the transaction can succeed even when the final output is much worse than the user expected.

In a sandwich attack, the attacker's first transaction tries to move the price against the user. The user's transaction will still execute if the final output remains above the minimum received value. That means the attacker's room is partly defined by the user's tolerance. A wide tolerance creates a larger execution window. A tighter tolerance may cause the transaction to fail if the price moves too far, but it may also make the transaction less likely to execute during normal volatility.

There is no universal minimum received setting that works for every token, pool, chain, and market condition. The user must review the actual amount, not just the percentage. If receiving the minimum amount would be unacceptable, the user should not sign. For more detail, read What Is Minimum Received?.

How a sandwich attack appears to a user

A sandwich attack can be hard to recognize from the wallet alone. The wallet may show that the transaction succeeded. The DEX may show that the swap was completed. The user may receive the output token. The problem is that the amount received may be worse than it would have been without the surrounding trades.

A user may notice a sandwich-like problem when the final output is close to the minimum received amount, when the price moved sharply during execution, when explorer records show a similar buy before and sell after the user's transaction, or when a low-liquidity token's chart has sudden spikes around the transaction. These are clues, not automatic proof.

For beginners, the practical lesson is not to become a forensic MEV analyst. The practical lesson is to check slippage, minimum received, price impact, pool depth, route, and token contract before signing. After the trade, use the explorer to verify actual transfers and surrounding context if the result looks abnormal.

What users should check before a DEX swap

This checklist is useful before any DEX swap, especially if the token is new, the route is large, the pool is shallow, the price impact is high, the slippage setting is wide, the transaction is public, the market is volatile, or a social community is pushing users to trade quickly.

Official source: Confirm the DEX, aggregator, wallet, and token page from official sources before connecting a wallet.
Selected network: Verify the chain, token contract, explorer, route, and gas token belong to the same network.
Input token contract: Make sure the token you are spending is the intended token.
Output token contract: Verify the token you are receiving, especially if the symbol is common or newly launched.
Trade size: Compare the swap amount with available route depth.
Pool depth: Check whether enough usable liquidity exists near the current price.
Price impact: Review how much your own trade moves the pool.
Slippage tolerance: Avoid high tolerance unless you understand why it is needed and what outcome it allows.
Minimum received: Read the actual output amount, not only the slippage percentage.
Route complexity: Check whether the route uses multiple pools, intermediate tokens, aggregators, or wrapped assets.
Token tax or restrictions: Be careful with tokens that require unusually high slippage or show abnormal buy and sell behavior.
Wallet prompt: Confirm whether the wallet asks for an approval, swap, signature, network switch, or other contract interaction.
Explorer result: After signing, verify status, token transfers, actual output, and any surrounding context on the correct explorer.
Secret information: Never reveal seed phrases, private keys, recovery phrases, passwords, recovery codes, or remote device access.

Can users prevent every sandwich attack?

No user can guarantee perfect protection in every market condition, chain, route, token, and transaction path. DEX execution depends on many moving parts: pool liquidity, transaction ordering, public or private routing, slippage, builders, validators, block producers, fees, network state, and bot competition. However, users can reduce exposure by understanding the main risk factors.

The most direct user-side controls are slippage tolerance, trade size, minimum received, route selection, and liquidity review. Smaller trades relative to pool depth usually create less movement. Tighter output boundaries reduce the amount of bad execution the user accepts. Deeper routes can reduce price impact. Avoiding suspicious tokens and fake links reduces unrelated scam risk.

Some wallets, DEXs, aggregators, RPC providers, and transaction services may offer private routing, MEV protection, or other execution features. These can have trade-offs, limitations, and trust assumptions. This page does not recommend any specific tool. Users should evaluate official documentation, risks, supported networks, failure modes, and privacy assumptions before using any protective route.

Lower slippage is not a magic shield

Lower slippage can reduce the room for bad execution, but it can also cause swaps to fail during normal movement. The user should understand the market, not blindly copy a number.

Smaller trade size can reduce impact

A smaller trade usually moves the pool less. This may reduce sandwich attractiveness, but it does not eliminate all risk.

Deeper liquidity can improve execution

Deeper route liquidity usually reduces price impact. It may also make the trade harder to manipulate with small capital.

Private routing may help but has trade-offs

Private transaction routes can reduce public mempool exposure on some networks, but users should understand the service, network support, and trust assumptions.

Verification still matters

MEV protection does not verify token contracts for the user. Fake tokens, phishing pages, unsafe signatures, and seed phrase theft remain separate risks.

Common sandwich attack mistakes

Sandwich attack mistakes usually come from treating the swap screen as a simple exchange form. In reality, a DEX swap is a public or semi-public on-chain transaction interacting with liquidity that can move before and during execution. The user does not need to fear every swap, but they should respect the mechanics.

Mistake 1: Thinking successful means fair

A transaction can succeed while giving poor output. Success means the transaction satisfied the rules and accepted boundaries. It does not automatically mean the user received ideal execution.

Mistake 2: Setting slippage too high

High slippage can let a transaction execute at a much worse price. It can also create more room for sandwich bots in some conditions.

Mistake 3: Ignoring minimum received

Minimum received is the actual lower output boundary. Users should read the token amount, not only the percentage.

Mistake 4: Trading large size in shallow pools

Large trades in shallow pools create higher price impact and can be more attractive targets for bots.

Mistake 5: Blaming every bad fill on bots

Bad execution can come from normal price impact, low depth, fees, route changes, token taxes, volatility, or a sandwich. Explorer context helps, but not every poor output is a sandwich attack.

Mistake 6: Trusting social slippage advice

“Set slippage to 20%” or “raise slippage until it works” can be dangerous advice. Understand why the trade needs tolerance before accepting the risk.

Mistake 7: Ignoring token contract verification

A sandwich-safe route does not make a fake token safe. Always verify token contracts or token mints from official sources.

Mistake 8: Clicking fake MEV protection links

Scammers may advertise fake MEV protection, sandwich refund, swap recovery, or private node tools. No legitimate protection tool needs a seed phrase or private key.

Mistake 9: Not checking the explorer

The explorer can show actual output, transaction status, token transfers, and surrounding transactions. It is the public record after execution.

Mistake 10: Repeating the trade without changing the problem

If the route is shallow, slippage is wide, or the token is risky, repeating the same action may repeat the same bad execution pattern.

When to be extra careful

Some DEX situations deserve extra caution because they combine multiple sandwich-risk factors. Slow down when a trade is large relative to pool depth, price impact is high, slippage tolerance is wide, minimum received is much lower than the quote, the token is newly launched, the route is complex, a token requires unusual slippage, a market is extremely volatile, or a social group pressures users to confirm quickly.

Before trading a new token: Verify the token contract, official source, liquidity depth, buy and sell activity, and route.
Before increasing slippage: Ask whether the issue is volatility, token tax, low depth, route failure, or fake-token behavior.
Before selling a large balance: Check whether the pool can absorb the sale without extreme impact.
Before using an aggregator route: Review the route, output boundary, tokens involved, and final wallet prompt.
Before using MEV protection: Read official documentation and understand network support, trust assumptions, and limitations.
Before following a support link: Confirm official support routes and never share wallet secrets.

How to verify a possible sandwich attack

Verifying a sandwich attack can be more advanced than checking a basic swap, but a user can still learn useful clues from a block explorer. The goal is not to share secrets or use a recovery page. The goal is to inspect the public transaction record and compare the quote, actual output, and nearby activity.

Copy the transaction hash: Use the exact hash or signature from the wallet or DEX interface.
Open the correct explorer: Make sure the explorer matches the chain where the swap happened.
Check transaction status: Confirm whether it succeeded, failed, reverted, or was replaced.
Review token transfers: Compare the input amount, output amount, and expected minimum received.
Check the pool or route: Identify which pool, router, or aggregator contract was involved.
Look at nearby transactions: If the explorer or analytics tool makes this possible, check whether similar trades occurred directly before and after the user's transaction.
Compare direction: A sandwich often involves an attacker moving in before the victim and reversing after the victim.
Account for normal price impact: A bad fill does not prove a sandwich. Check whether the trade itself was large relative to depth.
Save public records: Keep transaction hashes, wallet addresses, pool addresses, and screenshots of public information if needed.
Do not use secret recovery tools: Public analysis never requires a seed phrase, private key, recovery phrase, or remote access.

Sandwich attack examples and scenarios

The following examples are educational scenarios. They are not financial, trading, investment, legal, tax, or security recovery advice. They show how sandwich risk appears in ordinary DEX use.

Scenario 1: High-slippage buy in a shallow pool

A user buys a low-liquidity token with high slippage. A bot sees the pending buy, buys first, lets the user's buy execute at a higher price, then sells. The user receives fewer tokens than expected.

Scenario 2: Large sell into thin liquidity

A user sells a large token balance into a shallow pool. A bot trades before the sale to move the price down, lets the user's sale execute poorly, then reverses after. The user's received amount is close to the low boundary.

Scenario 3: Normal price impact mistaken for a sandwich

A user trades a large amount in a tiny pool and receives poor output. Nearby explorer records do not show clear surrounding bot trades. The main issue may have been normal price impact rather than a sandwich attack.

Scenario 4: Aggregator route still gets poor execution

A user assumes an aggregator eliminates MEV risk. The route is still public, the token is shallow, and slippage is wide. The final output is worse than expected. Aggregators can improve routing, but they cannot remove every execution risk.

Scenario 5: A user reads minimum received before signing

The swap screen shows a minimum received amount much lower than the quote. The user realizes that the accepted downside is too large and pauses instead of signing. This prevents a possible bad execution.

Scenario 6: A fake token requires extreme slippage

A social media post tells users to set very high slippage for a new token. The token has unclear contract details and shallow liquidity. The problem may involve token tax, fake-token behavior, or risky liquidity, not just normal market movement.

Scenario 7: Deep pool reduces the opportunity

A user swaps a small amount in a deep pool. The trade has low price impact and a tight output boundary. The potential sandwich opportunity may be too small after fees and competition.

Scenario 8: Transaction fails because tolerance is tight

A user sets a tight slippage tolerance. The market moves before execution, and the swap fails instead of accepting a worse output. A failed swap can be frustrating, but it may prevent worse execution.

Scenario 9: Private routing changes exposure

A user uses a private transaction route offered by a reputable wallet or DEX feature. The transaction may have less public mempool exposure, but the user still needs to verify token contracts, route details, and wallet prompts.

Scenario 10: Bot competition changes the outcome

Several bots compete to capture the same opportunity. The user's transaction may be included with surrounding activity that is difficult for a beginner to interpret. Explorer analysis can show clues, but MEV competition can be complex.

Scenario 11: Token launch volatility

A newly launched token has rapid buying and selling. Quotes change quickly, slippage is high, and pool depth is unstable. A user who rushes may get poor execution even without fully understanding whether the cause was volatility, price impact, or sandwich activity.

Scenario 12: Wrong chain creates false assumptions

A token has deep liquidity on one chain but shallow liquidity on another. A user trades the shallow version and sees high impact. Sandwich risk depends on the actual route and pool, not the token's reputation elsewhere.

Scenario 13: Token tax mixed with MEV

A token includes buy or sell taxes. The user sees poor output and suspects a sandwich. The result may include token tax, slippage, normal impact, and possible MEV. Multiple causes can overlap.

Scenario 14: A fake support account offers a refund

After a poor swap, a fake support account claims the user was sandwiched and can receive a refund by connecting to a recovery page. The page asks for a seed phrase. This is a scam pattern, not a recovery method.

Scenario 15: A user reviews the explorer calmly

A user saves the transaction hash, checks the explorer, compares actual output with minimum received, and reviews nearby swaps. They do not share secrets. They learn from the execution before making another transaction.

External patterns users may see

Sandwich attack discussions appear across DEX interfaces, wallet swap features, aggregators, private RPC products, MEV dashboards, block explorer analytics, DeFi education pages, token launch communities, and trading bot conversations. The language can vary. Some pages say “MEV protection.” Some say “anti-sandwich.” Some say “private transactions.” Some say “protected swaps.” Users should understand what is actually being protected and what is not.

One common external pattern is “slippage advice.” A token community may tell users to raise slippage because the token has taxes or because many transactions fail. That may make the swap pass, but it can also increase downside. Users should read the minimum received amount and understand the token mechanics before copying a number.

Another pattern is “MEV refund bait.” Scammers may claim they detected a sandwich attack and can refund the difference through a special form. They may ask users to connect a wallet, sign a message, approve a token, or enter a seed phrase. Public transaction analysis can use a transaction hash. It does not require secret wallet information.

A third pattern is “private route misunderstanding.” A user may assume that any private route makes a trade safe. Private routing can reduce a specific kind of exposure in some contexts, but it does not verify token contracts, remove fake-token risk, remove liquidity risk, remove price impact, or make poor trades profitable.

A fourth pattern is “explorer confusion.” A beginner may see several swaps around their transaction and assume every nearby trade is an attack. Sandwich analysis depends on ordering, direction, pools, amounts, and profitability. It can be subtle. The user-facing habit is still the same: check parameters before signing and verify public records after.

Real-world reference paths for learning

Readers who want to understand sandwich attacks more deeply can review neutral DeFi education, Ethereum documentation, MEV research pages, DEX documentation, and block explorers. External pages can change over time, so users should verify that they are reading current official sources and that token contracts, pool addresses, transaction hashes, and routes match their actual wallet action.

Sandwich attack safety checklist for beginners

A beginner does not need to become an MEV searcher to develop safer habits. The important user-side lesson is that swap execution is not only about the displayed token price. It is also about route depth, price impact, slippage, minimum received, transaction ordering, and wallet prompts.

Beginner sandwich-risk routine: Verify the official DEX or aggregator source, selected network, input token contract, output token contract, route, pool depth, price impact, slippage tolerance, minimum received, token tax behavior, wallet prompt, transaction hash, and final explorer result. Never share seed phrases, private keys, recovery phrases, passwords, recovery codes, or remote device access.

Do not treat a successful transaction as automatically good execution.
Read minimum received before signing.
Do not raise slippage blindly to force a swap.
Check whether trade size is large compared with pool depth.
Check price impact before confirming.
Be extra careful with new tokens and thin pools.
Verify token contracts from official sources.
Review aggregator routes before trusting the output.
Use block explorers to check actual transfers and status.
Be skeptical of fake MEV refund, anti-sandwich, or recovery pages.
Never enter a seed phrase into a DEX, MEV protection site, or support form.

Long-tail sandwich attack questions

What is a sandwich attack in crypto?

A sandwich attack is a transaction-ordering attack where a bot trades before and after a user's DEX swap. The bot tries to profit from the price movement around the user's transaction while the user receives worse execution.

What is a sandwich attack on a DEX?

On a DEX, a sandwich attack usually means a bot places a front-run trade before a victim's swap and a back-run trade after it. This can exploit AMM price movement, slippage tolerance, and shallow liquidity.

Why is it called a sandwich attack?

It is called a sandwich attack because the victim's transaction is placed in the middle of two attacker transactions. The attacker transaction before the victim and the attacker transaction after the victim form the “bread” around the victim's swap.

Is a sandwich attack the same as MEV?

A sandwich attack is one type of MEV. MEV is the broader category of value extracted through transaction ordering, inclusion, or exclusion. Not all MEV is a sandwich attack.

Is a sandwich attack the same as front-running?

No. A sandwich attack includes front-running, but it also includes a back-running transaction after the victim. Front-running alone means going before another transaction to gain an advantage.

Can a sandwich attack happen on any DEX?

Sandwich risk depends on the chain, transaction path, pool design, route, liquidity, slippage, and ordering environment. AMM-based public swaps with wide tolerance and shallow liquidity are more exposed than deep, tightly bounded routes.

Does high slippage cause sandwich attacks?

High slippage does not cause every sandwich attack by itself, but it can give bots more room to move the price against the user while still letting the transaction execute.

Can low slippage stop sandwich attacks?

Lower slippage can reduce the room for bad execution, but it is not a perfect shield. It can also make swaps fail during normal volatility. Users should review minimum received and route conditions.

What does minimum received have to do with sandwich attacks?

Minimum received is the lowest output the user accepts. A sandwich bot may try to move the price against the user while keeping the final output above that boundary so the swap still succeeds.

Why are shallow pools more vulnerable?

Shallow pools move more easily because a smaller trade can change reserves more significantly. This can make price movement around a victim's swap more profitable for bots.

Can a sandwich attack happen if my swap succeeds?

Yes. A sandwich attack can result in a successful swap with worse output. A successful status only means the transaction executed within the accepted conditions.

How can I tell if I was sandwiched?

You can check the transaction hash on a block explorer and look for surrounding trades in the same pool before and after your transaction. Clear proof can require advanced analysis, and not every bad fill is a sandwich.

Can aggregators prevent sandwich attacks?

Aggregators may improve routing or offer protective features, but they cannot remove every risk. Users still need to check slippage, minimum received, route, price impact, token contracts, and wallet prompts.

Can private RPC stop sandwich attacks?

Private routing or private RPC may reduce public mempool exposure in some contexts, but it has limitations and trust assumptions. It does not protect against fake tokens, poor liquidity, unsafe signatures, or bad trade decisions.

Are sandwich attacks illegal?

Legal treatment depends on jurisdiction and specific facts. This page is not legal advice. Users concerned about legal issues should consult qualified professionals and rely on official legal sources.

Can token taxes look like a sandwich attack?

Yes. Token taxes, low liquidity, price impact, route changes, fees, and MEV can all reduce output. Users should not assume one cause without checking transaction details and token behavior.

What is the safest slippage for avoiding sandwiches?

There is no universal safe slippage number. The safer habit is to understand the token, route, liquidity, volatility, price impact, and minimum received before choosing a tolerance.

Can a fake MEV protection tool steal my wallet?

Yes. Fake protection tools may ask for seed phrases, private keys, unsafe approvals, or unclear signatures. Public analysis and legitimate swap protection should never require secret wallet recovery information.

Why did my final output nearly equal minimum received?

This can happen because the trade experienced price movement, slippage, route changes, token tax, or possible MEV. It is a warning to review the route and surrounding transactions before making another similar swap.

What is the most important sandwich attack safety habit?

Read the minimum received amount and price impact before signing. If the accepted output would feel unacceptable, do not confirm the transaction just because the DEX button is available.

FAQ

What is a sandwich attack in simple terms?

A sandwich attack is when a bot places one trade before your swap and one trade after your swap to profit from the price movement around you. Your swap becomes the middle of the sandwich and may receive worse output.

Why do sandwich attacks happen on DEXs?

They happen because DEX swaps can be visible before execution and AMM prices move when trades change pool reserves. If a user allows enough slippage and the pool can be moved profitably, a bot may try to trade around the user's swap.

Can I lose funds from a sandwich attack?

A sandwich attack usually does not steal tokens directly like a seed phrase theft. Instead, it can cause worse trade execution, meaning the user receives fewer output tokens than they would have received without the surrounding trades.

Does a sandwich attack require my private key?

No. A sandwich attack targets transaction ordering and swap execution. It does not require the attacker to know your private key. However, fake “sandwich recovery” pages may try to steal private keys or seed phrases.

What settings make sandwich attacks worse?

Wide slippage tolerance, a low minimum received boundary, large trade size, shallow liquidity, high price impact, volatile tokens, and public transaction routing can increase exposure to poor execution.

Should I always use the lowest possible slippage?

Not always. Very low slippage can cause transactions to fail during normal market movement. The better habit is to understand the route, pool depth, volatility, and minimum received before choosing a tolerance.

Can sandwich attacks happen on stablecoin swaps?

They are generally less attractive when pools are deep and price impact is low, but risk depends on the actual route, liquidity, slippage, and market conditions. Stable assets can still experience execution issues in stressed or shallow pools.

Does MEV protection guarantee a perfect price?

No. MEV protection may reduce certain transaction-ordering risks, but it does not guarantee a perfect price, verify tokens for the user, remove liquidity risk, or prevent every bad execution outcome.

Can I get a refund after a sandwich attack?

In most public blockchain systems, confirmed swaps are final unless a specific service has an official refund policy. Be skeptical of anyone claiming they can recover a sandwich loss by asking for your seed phrase, private key, approval, or remote access.

How do I check my transaction after a suspected sandwich attack?

Copy the transaction hash and open the correct block explorer. Review actual token transfers, route, pool interactions, and nearby transactions before and after your swap if the explorer or analytics tools support it.

Is every MEV bot malicious?

MEV is a broad category and includes many strategies, such as arbitrage and liquidations. Sandwich attacks are user-harmful because they worsen swap execution for the victim. Not every MEV activity is the same.

Why does high price impact attract sandwich bots?

High price impact means the user's trade moves the pool price significantly. That movement can create a larger opportunity for a bot to trade before and after the user if slippage tolerance allows it.

What should beginners check first?

Beginners should check official links, token contracts, selected network, pool depth, price impact, slippage tolerance, minimum received, wallet prompts, and the final transaction record on a block explorer.

Can a token launch be more vulnerable?

New token launches often involve volatile prices, shallow liquidity, high slippage, bot activity, and user urgency. These conditions can increase execution risk, including sandwich-like behavior.

What is the main lesson from sandwich attacks?

The main lesson is that DEX execution is not only about the displayed quote. Users should understand the accepted downside before signing: minimum received, slippage, price impact, and liquidity depth matter.

Related concepts

Sandwich attacks connect to several nearby crypto concepts. Understanding these pages can help readers move through the Eonwell archive in a safer order, especially if they are learning how wallets, DEX swaps, AMMs, liquidity pools, slippage, price impact, minimum received, MEV, front-running, token contracts, aggregators, and block explorers fit together.

Summary

A sandwich attack is a DEX execution attack where a bot places a transaction before and after a user's swap to profit from the price movement around that swap. The user's transaction becomes the middle of the sandwich. The result can be a successful transaction that still gives the user worse output.

Sandwich attacks are closely related to MEV, front-running, back-running, AMM pricing, slippage tolerance, price impact, pool depth, and transaction ordering. They are not the same as normal price impact, but normal price impact can make a trade more attractive to sandwich bots. They are not the same as slippage, but wide slippage can give more room for a sandwich to execute.

The most important user-side fields are price impact, slippage tolerance, and minimum received. Price impact shows how much the user's trade moves the pool. Slippage tolerance defines how much execution can move from the quote. Minimum received shows the actual lower output boundary. If the minimum received value is unacceptable, the user should not sign the swap.

Pool depth matters because shallow pools move more easily. Large trades in shallow pools can create stronger price movement and more attractive transaction-ordering opportunities. Deep liquidity, smaller trade size, careful slippage, route review, and official protective features may reduce exposure, but no method removes every risk in every context.

Public blockchain data and secret wallet information must always be separated. A wallet address, token contract, pool address, router address, transaction hash, route, and explorer link can usually be checked publicly. A seed phrase, private key, recovery phrase, Secret Recovery Phrase, password, recovery code, or remote device access should never be entered into a DEX, MEV protection site, sandwich refund page, recovery form, token migration portal, or wallet validation tool.

The safest sandwich-risk habit is to verify before acting. Check the official DEX or aggregator source, selected network, input token contract, output token contract, route, pool depth, price impact, slippage tolerance, minimum received, token tax behavior, wallet prompt, transaction hash, and final explorer result before confirming a DEX swap.

Eonwell does not recommend any specific DEX, wallet, token, exchange, protocol, bridge, liquidity pool, router, explorer, RPC provider, approval checker, aggregator, private transaction service, MEV protection service, liquidity strategy, service, or transaction. This page is for neutral crypto education only.

Topics