Sandwich Attacks Explained: MEV Bots, Slippage, DEX Trades, Front-running, and Trader Protection
A sandwich attack in crypto occurs when an MEV searcher places one trade before a user's decentralized exchange swap and another immediately after it, using transaction ordering, price impact, and the user's permitted slippage to extract value. The user's wallet does not need to be compromised, and the swap may still succeed, but it can settle at a worse price because the bot changes the pool state before the user and closes its position after the user's trade moves the market further.
TL;DR
- A sandwich attack uses three ordered transactions: the bot's front transaction, the user's swap, and the bot's back transaction.
- The bot moves the price before the user trades. The user then executes against a less favorable pool state.
- The user may still receive a successful confirmation. The economic harm often appears as fewer tokens, more input spent, or greater price impact.
- Slippage defines the maximum adverse execution the transaction permits. Wider slippage can create more room for a profitable sandwich.
- Liquidity depth and trade size matter together. Large trades in thin pools are usually easier and cheaper to move.
- Sandwiching is a form of MEV and front-running. The first bot transaction front-runs the user, while the final transaction back-runs the user.
- Private or protected transaction routes may reduce public visibility. They do not guarantee a specific price or remove token-level risk.
- Lower slippage is not a complete solution. Limits that are too tight can cause normal trades to revert during ordinary market movement.
- Sandwich risk is a market microstructure issue. It can affect legitimate assets and major pools, not only scam tokens.
- No single setting guarantees protection. Traders should combine token checks, liquidity analysis, realistic limits, careful routing, and appropriate transaction submission.
The bot submits its own valid transactions. The economic extraction comes from obtaining favorable positions immediately before and after the user's swap.
Evaluate the token and the trade before signing
Use the TokenToolHub Token Safety Checker to review visible token risks such as ownership control, transfer restrictions, minting, blacklists, and transaction fees. Then use the swap safety guide to assess the token address, trading route, approvals, liquidity, price impact, minimum received, and slippage before authorizing the transaction.
What a sandwich attack means in crypto
A sandwich attack is an ordered trading strategy that targets another user's pending decentralized exchange transaction. The attacker places one transaction before the user and another after the user, creating a three-part sequence.
The user's transaction becomes the middle of the sandwich. The attacker's opening trade changes the exchange rate first. The user's trade then executes against that changed rate and pushes the market farther. The attacker's closing trade reverses the opening position and attempts to retain the difference.
The front transaction changes the pool before the user
Consider a user who intends to buy a token from an automated market maker. A searcher detects the pending buy and purchases the same token first. That purchase removes tokens from the pool and raises the marginal price.
When the user's transaction executes next, the pool contains fewer output tokens relative to the payment asset. The user receives less than the earlier quote suggested.
The victim transaction creates additional movement
The user's own purchase pushes the price higher. This additional movement is important because it creates the higher exit price the searcher expects to use.
The user is not necessarily charged a separate attack fee. The loss is embedded in the exchange rate and the amount ultimately received.
The back transaction closes the searcher's position
After the user's buy, the searcher sells the tokens purchased in the front transaction. If the sale proceeds exceed the opening cost and all execution expenses, the searcher retains a profit.
A sell-side sandwich follows the opposite direction. The searcher sells before a large user sale, lets the user's sale push the price lower, and then buys back at the reduced price.
The user's signature remains valid
The searcher does not rewrite the user's transaction. A digital signature would become invalid if signed fields were altered. Instead, the searcher changes the blockchain state that exists when the valid user transaction reaches execution.
The sandwich transaction sequence
A classic buy-side sandwich can be understood as five connected stages: the user reveals an intended swap, the searcher evaluates it, the searcher buys first, the user buys second, and the searcher sells third.
The bot trades first
The opening transaction moves the pool price against the pending user trade.
The user executes second
The user's trade receives a worse price but remains valid if it stays within the signed limit.
The bot reverses third
The closing transaction attempts to capture the value created by the ordered sequence.
The victim must normally remain executable
A searcher cannot simply move the price without limit. If the bot's opening trade pushes the user's output below the minimum amount encoded in the swap, the user's transaction reverts.
That failure can also invalidate the attacker's expected closing conditions. Searchers therefore simulate the sequence carefully and often seek an opening size that consumes a large portion of the user's tolerance without crossing the revert boundary.
Ordered bundles can protect the searcher's sequence
A searcher may submit the opening trade, the user's transaction, and the closing trade through infrastructure that preserves their relative order. The sequence can be designed so it is included together or not included at all.
This reduces the searcher's risk that only the first trade executes while the user transaction disappears, changes, or is replaced.
How automated market maker pricing creates the opportunity
Sandwich attacks are closely associated with automated market makers because their prices change mechanically as pool balances change. A swap does not merely accept an external market price. It moves along a liquidity curve according to the amount traded and the available reserves.
A trade changes the rate available to the next trader
When a buyer removes token B from a pool and adds token A, token B becomes relatively scarcer inside that pool. The next buyer must usually provide more token A for each unit of token B.
The opening searcher trade intentionally creates this less favorable state before the user arrives.
The user's own price impact helps the searcher
Even without a sandwich, a large trade receives progressively worse marginal prices as it moves through the pool's liquidity curve. In a sandwich, the bot first shifts the starting point, then the user's own purchase pushes the curve farther in the bot's favor.
The searcher exits after this additional movement. The bot's opportunity therefore depends on both the inserted trade and the predictable effect of the user's transaction.
Pool fees create a minimum profitability hurdle
The bot usually pays a swap fee when entering and another when exiting. It may also pay network gas, priority fees, direct builder compensation, token transfer taxes, and capital costs.
A mathematically possible sandwich is not automatically profitable. The gross price movement must exceed all costs and leave a sufficient margin for execution risk.
Concentrated liquidity makes active depth important
In concentrated-liquidity designs, liquidity providers choose price ranges. The headline value deposited in a pool may be much larger than the liquidity actively supporting the current price.
A user can therefore see a large total pool value while still trading through a thin active range. Once the price moves across that range, execution can deteriorate rapidly.
Multi-hop swaps can have one weak segment
A route may exchange token A for token B and then token B for token C. The overall route is only as resilient as its weakest pool.
Searchers can simulate every step and target the segment where the user's order creates the greatest predictable price movement.
Why slippage matters in a sandwich attack
Slippage is the difference between the output estimated when a quote is generated and the output available when the transaction executes. A slippage setting allows the transaction to tolerate some market movement instead of reverting after every small change.
The contract enforces an amount, not a feeling
A trading interface may display slippage as a percentage, but the signed transaction generally contains a concrete minimum output or maximum input.
For an exact-input swap, the user supplies a fixed amount and requires at least a specified quantity of output tokens. For an exact-output swap, the user requests a fixed output and limits the maximum input that may be spent.
Slippage is necessary for ordinary execution
Blockchain settlement is not instantaneous. Another trade can execute first, liquidity can move, a route can change, or network congestion can delay inclusion.
A transaction with no tolerance may fail because of normal market activity rather than an attack.
Wide slippage expands the attacker's working range
A wider limit allows the pool price to move farther against the user while the transaction remains valid. Searchers can use that room to increase the size of the opening trade.
The searcher does not necessarily consume the entire allowance. It chooses the sequence that is expected to generate the best net result after fees and competition.
Tight slippage reduces extraction but increases reverts
A stricter minimum output can stop a sandwich sequence that would otherwise settle at a poor price. The tradeoff is reliability. The transaction may revert during a volatile market or when unrelated users trade first.
A reverted transaction can still consume gas. Traders should therefore avoid treating the lowest possible setting as universally optimal.
Minimum received is the most useful number to review
A percentage can feel abstract. The minimum-received field shows the actual number of tokens the user is willing to accept.
Traders should compare that amount with the expected output and estimate its approximate value. This reveals the real size of the authorized execution range.
Unexpectedly high slippage can signal another problem
A trading interface may recommend high tolerance because the market is volatile, liquidity is poor, the route is complex, or the token deducts fees during transfer.
Increasing the setting repeatedly until a trade succeeds can hide dynamic taxes, anti-bot restrictions, rebasing behavior, sell limitations, or malicious token logic.
A sandwich searcher attempts to push execution closer to the user's permitted boundary while keeping the transaction valid and the overall sequence profitable.
Liquidity depth and trade size
Liquidity and trade size must be evaluated together. The same transaction size can be insignificant in one pool and highly disruptive in another.
Thin liquidity makes the price easier to move
When active reserves are limited, a relatively small bot trade can create a large percentage change. The attacker needs less capital and pays less price impact to move the pool against the user.
Thin pools are common around newly launched assets, obscure token pairs, isolated fee tiers, and markets where liquidity providers have withdrawn.
Deep liquidity raises the cost of a sandwich
In a deep pool, the bot must trade more capital to create the same percentage movement. Larger trades also pay greater swap fees and may experience substantial price impact themselves.
This can make small user swaps economically unattractive to searchers.
Deep liquidity does not make the risk disappear
A treasury rebalance, institutional swap, liquidation, or whale trade can be large enough to create meaningful price movement even in a major market.
Searchers evaluate absolute value, not only percentages. A small percentage extracted from a very large trade can justify substantial capital and block-ordering payments.
Splitting a trade has benefits and costs
Dividing a large market order can reduce the immediate impact of each transaction. A smaller individual swap may create less extractable value.
The tradeoff is additional gas, repeated pool fees, longer exposure to market movement, and a visible pattern that may reveal continuing demand.
Route splitting may be more efficient
Some trading systems distribute one transaction across several pools. This can reduce dependence on one shallow venue while keeping the execution atomic.
Traders should still inspect intermediate assets, pool quality, contract approvals, and the active liquidity available along every part of the route.
How MEV bots see and order pending trades
Most public blockchain transactions are visible to network infrastructure before final settlement. When a wallet broadcasts a signed swap through an ordinary node endpoint, the transaction may propagate across peer-to-peer connections and appear in local pending transaction pools.
There is no single global mempool
Each node maintains its own pending transaction view. Transactions reach different nodes at different times because of network latency, peer connections, fee policies, private submission, and transaction replacement.
Searchers operate well-connected infrastructure so they can receive and classify actionable transactions quickly.
The pending transaction reveals useful intent
Depending on the router and transaction type, calldata can reveal the input token, output token, amount, path, recipient, deadline, and minimum acceptable output.
The transaction signature proves authorization, but it does not encrypt the economic purpose of the call.
The bot simulates the complete sequence
Searcher software runs the victim transaction against current blockchain state and tests possible opening trades. It estimates how much the pool price will move, whether the user remains above the minimum output, and what a closing trade would return.
The simulation also includes gas, pool fees, token taxes, builder compensation, failure conditions, and competition from other bots.
Priority fees are only one ordering mechanism
A searcher can submit a public transaction with a competitive priority fee, but modern block construction can also involve private bundles, block builders, relays, direct payments, and application-specific order flow.
The highest visible priority fee does not automatically guarantee the first position inside a block.
Builders evaluate total block value
Builders combine public transactions, private submissions, bundles, arbitrage, liquidations, and other order flow into candidate blocks.
They may choose a sequence that creates the greatest valid total value, then submit a bid to the validator responsible for proposing the block.
Ordered bundles reduce partial-execution risk
A searcher may require the opening trade, victim transaction, and closing trade to execute together in a specific order. If the complete sequence cannot be included, the bundle can be excluded.
This protects the searcher from buying first and becoming trapped if the victim cancels, replaces, or invalidates the expected transaction.
Front-running, back-running, and MEV
A sandwich attack combines two transaction-ordering positions. The first bot transaction front-runs the user, while the second bot transaction back-runs the user.
Front-running changes state before the victim
The opening trade executes first and creates a less favorable pool state for the user. This is the harmful insertion component of the sequence.
Back-running captures the state created by the victim
The closing trade executes after the user and uses the new post-victim price to unwind the position.
Not all front-running is sandwiching
A competitor can front-run a liquidation, claim, token mint, name registration, auction bid, or arbitrage transaction without adding a closing trade afterward.
The TokenToolHub front-running guide explains transaction insertion, copied actions, priority bidding, pending transaction visibility, and broader timing asymmetry.
Not all back-running is harmful
A trade placed after a user's swap may perform ordinary arbitrage and restore prices across pools without first moving the price against the user.
A complete sandwich requires the harmful opening transaction before the victim and the closing transaction after it.
Sandwiching is one category of maximal extractable value
MEV describes value available through transaction inclusion, exclusion, and ordering. Sandwich attacks are a user-facing form of harmful MEV because the searcher changes the victim's execution before collecting the result.
Other MEV categories include arbitrage, liquidations, NFT mint competition, oracle-update positioning, and transaction displacement.
Continue with the TokenToolHub MEV guide for a broader explanation of searchers, builders, validators, sequencers, private order flow, and transaction-ordering markets.
How traders experience a sandwich attack
Sandwich harm is usually hidden inside execution rather than displayed as a separate charge. A wallet may show that the swap succeeded even though another participant captured part of the value the user expected to receive.
Fewer output tokens
In an exact-input trade, the user supplies the intended input amount but receives fewer output tokens because the bot moved the pool price first.
More input spent
In an exact-output trade, the user may spend more input tokens than initially expected, provided the total remains below the signed maximum.
Higher effective execution price
The user buys after the bot has already increased the price or sells after the bot has already lowered it.
A reverted transaction
If the inserted trade or unrelated market movement pushes the user beyond the permitted limit, the transaction can revert. The user receives no trade output and may still pay gas.
Confusing transaction analysis
The visible token transfer may look normal. Identifying the sandwich requires examining the surrounding block order, internal calls, pool changes, and the attacker's opening and closing positions.
Execution uncertainty
Repeated poor execution can reduce confidence in on-chain markets, especially when users do not understand the difference between price impact, slippage, token taxes, and MEV extraction.
Liquidity-provider effects
Liquidity providers may collect fees from all three trades, but passive liquidity can also face adverse selection and lose value to specialized searchers that choose favorable moments to trade.
Practical ways to reduce sandwich exposure
No user-level setting guarantees complete protection. The practical objective is to reduce avoidable price impact, limit unfavorable execution, reduce public visibility where appropriate, and avoid token or liquidity conditions that create excessive risk.
Verify the asset and route
- Confirm the token contract address: Names and ticker symbols can be copied by unrelated tokens.
- Inspect the exact route: Identify every pool and intermediate asset used by the transaction.
- Review token behavior: Look for transfer fees, dynamic taxes, blacklists, pausing, transaction limits, and sell restrictions.
- Confirm that the token can be sold: A successful purchase does not prove that a later sale will work.
- Review liquidity ownership: Determine whether a privileged party can withdraw or migrate the market's liquidity.
- Avoid unknown router contracts: A malicious interface can construct unsafe approvals, routes, fees, or recipients.
Review execution limits
- Inspect minimum received: Understand the actual token amount the trade is permitted to deliver.
- Review price impact separately: Your own trade may move the market even without an attacker.
- Avoid unnecessary slippage: Do not increase tolerance repeatedly without identifying the reason a trade is failing.
- Use a realistic deadline: A stale market order should not execute long after the quote was generated.
- Compare the worst-case value: Convert the permitted output into an approximate value you understand.
- Accept possible reverts: Safer limits can cause a transaction to fail during genuine volatility.
Reduce unnecessary market impact
- Compare trade size with active liquidity: A large pool headline does not always mean deep liquidity near the current price.
- Compare available routes: Another pool or fee tier may provide more resilient execution.
- Consider smaller trades carefully: Splitting can reduce individual impact but adds fees and repeated exposure.
- Consider limit-based execution: A limit condition can refuse execution beyond a defined price.
- Avoid predictable repeated patterns: Searchers may infer continued demand from recurring equal-sized trades.
- Do not force urgent execution: Waiting for stronger liquidity can sometimes be safer than accepting a broad market range.
Consider protected transaction submission
- Private routing can reduce broad visibility: The full transaction may be sent to selected builders instead of the public transaction pool.
- Review the provider's policy: Understand who receives the transaction and whether front-running is restricted.
- Check builder coverage: Limited distribution can reduce the chance of rapid inclusion.
- Understand fallback behavior: Determine whether a delayed transaction can later be broadcast publicly.
- Check replacement rules: Do not create conflicting transactions without reviewing the account nonce and pending status.
- Remember the limits: Private routing cannot repair malicious token logic or guarantee the quoted price.
Use automation for discipline, not guaranteed protection
Rule-based trading can help define position size, price conditions, timing, and maximum acceptable execution cost before volatility rises.
Coinrule can support structured crypto trading workflows. Automation still depends on liquidity, venue quality, account permissions, fees, and execution infrastructure. It should not be treated as automatic protection from MEV or sandwich attacks.
Separate custody protection from execution protection
A hardware wallet can reduce private-key exposure and require physical confirmation before signing. It cannot prevent searchers from reading a publicly broadcast transaction or changing the pool state before it executes.
A device such as Ledger can help separate long-term holdings from an active DeFi account. This limits custody and approval exposure, but the user must still review the token, route, liquidity, slippage, and contract call.
Private transaction routes and their tradeoffs
Private transaction submission sends a signed transaction to selected infrastructure rather than immediately sharing it through ordinary public propagation.
Reduced public visibility
Searchers monitoring common public transaction pools may not receive the complete trade before inclusion. This can make a conventional public-mempool sandwich more difficult.
Restricted visibility is not complete secrecy
The private submission service, participating builders, or other selected infrastructure may still receive the transaction. Users depend on the provider's handling and privacy commitments.
Builder reach affects inclusion
A transaction sent to a limited group of builders may wait if those builders do not produce the next block. Delay can expose the trade to unrelated market changes.
Different services use different policies
Some services restrict front-running, allow back-running, share limited transaction hints, return part of extracted value, or use different fallback methods.
Private routing cannot guarantee a quote
Other public or private trades can still execute first. Liquidity providers can move capital, token rules can change, and the external market can move before settlement.
Network design matters
Ethereum, rollups, and alternative chains use different block builders, validators, sequencers, transaction pools, and private submission systems. A protection method available on one network may not exist or work the same way on another.
How to identify a likely sandwich attack on-chain
A suspected sandwich should be investigated at block level. Looking only at the user's transaction is not enough because the relevant evidence exists before and after it.
Locate the user trade
Record the pool, route, input, output, minimum received, gas and block position.
Inspect the trade before it
Look for the same market, matching direction and a related searcher contract.
Inspect the trade after it
Look for the reverse transaction that closes the opening position.
Calculate the economics
Include token flows, gas, swap fees, taxes and builder payments.
Start with the transaction order
A classic sandwich appears as an opening trade, the user's trade, and a closing trade in consecutive or closely grouped block positions.
The transactions do not always use the same top-level address. A searcher may route through a contract that performs several internal calls.
Compare pools and directions
In a buy-side sandwich, the opening trade usually buys from the same pool before the user and the closing trade sells back afterward.
In a sell-side sandwich, the directions are reversed.
Inspect internal calls and token transfers
Routers, aggregators, flash liquidity, and searcher contracts can hide the relevant swaps inside nested calls. Researchers should follow actual token transfers and pool reserve changes.
Calculate net profit rather than gross movement
The searcher's closing balance must be adjusted for gas, swap fees, direct builder payments, token taxes, and any temporary borrowing costs.
Distinguish sandwiching from ordinary arbitrage
A transaction that occurs only after the user may be ordinary back-running arbitrage. It can restore the pool price without first worsening the user's execution.
Look for repeated behavior
Searcher contracts often perform similar sequences across many blocks, pools, and users. Repeated patterns strengthen the analysis.
Use wallet labels as leads, not proof
Nansen can support wallet, token-flow, and transaction research on covered networks. Labels should be confirmed through contract traces, repeated transaction patterns, funding relationships, and direct on-chain evidence.
How DEXs and protocols can reduce harmful sandwiches
User settings help manage exposure, but the strongest improvements come from changing how orders are revealed, matched, and settled.
Protected order flow
Applications can submit trades through infrastructure that limits public visibility and restricts defined harmful ordering strategies.
Batch auctions
Orders collected during a defined interval can settle at a common clearing price. This reduces the value of being a few milliseconds earlier within the batch.
Frequent batch execution
Instead of processing every order strictly one by one, an application can group transactions into repeated settlement windows.
Intent-based trading
Users can specify a desired outcome while competing solvers search for execution paths. The system can compare solutions rather than exposing one fixed market route publicly.
Limit-based settlement
Users can define a price condition and refuse execution outside it. The tradeoff is that the order may remain unfilled or receive only a partial fill.
Order-flow auctions
An application can auction the right to execute a user's order and direct part of the resulting value back to the user, liquidity providers, or protocol.
MEV refunds
Some systems attempt to return a share of back-running or order-flow value to the transaction originator rather than allowing the complete surplus to remain with searchers and block builders.
Better transaction warnings
Interfaces can warn users about high price impact, thin active liquidity, unusual token taxes, broad slippage, long deadlines, and risky intermediate routes.
Safer token launches
Batch allocation, transparent auctions, purchase caps, predictable liquidity commitments, and delayed reveal mechanisms can reduce launch-block races and extreme early price extraction.
TokenToolHub Research Note: sandwich risk is market microstructure risk
Sandwich attacks are often presented as a problem caused by scam tokens or unusually aggressive bots. Those factors can increase harm, but they do not explain the full mechanism.
Sandwich risk emerges from the structure of on-chain trading itself. The user reveals a signed intention before settlement. The pool's price response can be simulated. Transactions execute sequentially. Specialized participants compete for ordering. The user also authorizes a range of acceptable execution through the minimum-output or maximum-input limit.
Can the trade be observed?
Review public propagation, private routing, RPC handling and calldata exposure.
How far will the trade move the market?
Review active liquidity, trade size, pool design, route and token taxes.
How much adverse movement is permitted?
Review minimum output, maximum input, slippage and the transaction deadline.
Can a searcher surround the user?
Review builders, bundles, validators, sequencers and block-space competition.
A legitimate asset in a major pool can still face sandwich risk when the trade is large enough and publicly visible. A scam token can add high taxes, blocked sales, blacklists, or liquidity withdrawal, but those are additional contract and liquidity risks.
The durable response is not simply to identify one bot. The opportunity remains available to other searchers while the same market structure persists.
Effective protection reduces exploitable visibility, improves execution constraints, deepens liquidity, changes settlement design, or returns more transaction-ordering value to the user.
Sandwich attack risk matrix
| Trade condition | Relative exposure | Main reason | Practical response |
|---|---|---|---|
| Large public market swap with wide slippage | High | The trade creates predictable price impact and authorizes substantial adverse movement. | Review minimum output, route, trade size, protected submission, and limit-based alternatives. |
| Small swap in a deep active pool | Lower, not zero | The potential extraction may be too small after fees and competition. | Use reasonable limits and verify the route. |
| Thin pool with high transfer tax | Critical | Low liquidity and broad tolerance create a large execution range. | Investigate token mechanics and avoid trading until the risks are understood. |
| Private transaction with broad builder reach | Reduced public exposure | Ordinary public searchers may not receive the full trade before inclusion. | Review privacy policy, fallback behavior, builder coverage, and remaining market risk. |
| Private transaction with limited builder reach | Mixed | Visibility may fall, but delayed inclusion and provider dependence increase. | Understand inclusion, expiry, cancellation, and fallback rules. |
| Strict limit-based order | Lower adverse-price risk | Execution is rejected outside the defined condition. | Accept possible delay, partial fill, or no fill. |
| Repeated predictable market purchases | Moderate to high | Searchers can infer continuing demand from the pattern. | Compare timing, order size, venue, and total execution cost. |
| Launch-block purchase | High | Low initial liquidity, bot competition, taxes, and volatility combine. | Review launch rules and avoid uncontrolled slippage. |
| Multi-hop route with one shallow pool | High at the weak segment | The searcher can target the route component with the greatest price sensitivity. | Compare routes and inspect active liquidity in every pool. |
| Hardware-signed public swap | Normal ordering exposure | The signing key is protected, but the transaction can still become visible. | Separate custody controls from execution controls. |
Practical sandwich attack scenarios
Large buy in a shallow pool
A user submits a large token purchase with three percent slippage. The pool has limited active liquidity. A searcher buys first and raises the price.
The user's transaction executes at the changed price because the result remains above the minimum output. The searcher sells afterward and retains the remaining difference after fees.
Large trade in a major pool
A treasury submits a substantial rebalance through a well-known market. The pool is deep, but the absolute trade size is large enough to move the price.
A searcher commits more capital and pays more for ordering. The sequence can remain profitable because even a small percentage of the trade represents significant value.
Fee-on-transfer token
A token deducts a large percentage during transfers. The interface recommends broad slippage so the swap can complete.
The user loses value through the token tax, while a searcher can also use the remaining tolerance to worsen the execution price.
Victim transaction reverts
A bot submits an opening trade, but another transaction moves the pool before the victim. The user's output falls below the minimum.
The victim transaction reverts. If the attack is bundled conditionally, the searcher's opening and closing transactions may also be excluded.
Private route reduces public sandwiching
A user submits a trade through protected infrastructure. Public transaction-pool searchers do not receive the complete transaction before inclusion.
The trade avoids a conventional public sandwich but still receives slightly less than the original quote because unrelated market activity occurred first.
Sell-side sandwich
A user submits a large sale. The searcher sells first and pushes the pool price lower.
The user's sale then executes at the reduced price and creates further downward movement. The searcher buys back afterward at the lower post-victim price.
Concentrated-liquidity gap
A pool displays substantial total value, but only a small amount is active near the current price. The user assumes the market is deeper than it is.
The searcher's opening trade pushes the price through the thin range, causing more adverse movement than the headline pool value suggested.
Ordinary arbitrage mistaken for a sandwich
A user's swap moves one pool away from prices on other exchanges. A searcher trades only after the user to restore the price difference.
There is no opening searcher trade that worsened the user's execution, so the sequence is back-running arbitrage rather than a complete sandwich.
Sandwich risk checklist for traders
Token and pool checks
- Confirm the exact network and token contract.
- Review ownership, minting, pausing, blacklists, transfer limits, and token taxes.
- Identify the exact pool and fee tier selected by the route.
- Review active liquidity near the current price.
- Check whether the token can be sold under current rules.
- Review who controls the pool's liquidity.
Execution checks
- Review expected output and minimum received.
- Review price impact separately from slippage.
- Inspect all intermediate tokens in a multi-hop route.
- Use a realistic transaction deadline.
- Confirm the intended recipient and router contract.
- Review gas and all expected transaction fees.
Protection checks
- Consider a protected route where appropriate.
- Understand who receives the transaction before inclusion.
- Review whether the transaction can fall back to public broadcast.
- Compare market execution with a limit-based alternative.
- Do not keep increasing slippage without diagnosing the failure.
- Accept that safer limits may produce a failed or unfilled trade.
Account and post-trade checks
- Use a separate account for active DeFi trading.
- Review token approvals after using unfamiliar routers.
- Verify the actual received amount on-chain.
- Record the transaction hash for later analysis.
- Ignore unsolicited recovery services after a failed swap.
- Do not confuse MEV protection with protection from market losses.
Related TokenToolHub research
Sandwich attacks connect directly to front-running, MEV, token safety, swap execution, trading risk, and broader DeFi security.
Pending transaction and ordering risk
Read the front-running guide for mempool visibility, copied actions, priority competition, and transaction displacement.
Searchers, builders, and validators
Use the MEV guide to understand arbitrage, liquidations, private order flow, block construction, and transaction-ordering markets.
Contract-level token indicators
Open the Token Safety Checker to review taxes, ownership, minting, blacklist functions, and transfer restrictions.
Route and approval safety
Continue with the swap safety guide for token verification, routes, approvals, liquidity, price impact, and minimum-output review.
Market and execution exposure
Read the trading risk guide for volatility, liquidity, leverage, position sizing, custody, and execution risk.
Protocol dependency risk
Use the DeFi security guide to evaluate contracts, oracles, liquidity, governance, approvals, and protocol composition.
Common misconceptions about sandwich attacks
Sandwich attacks only affect scam tokens
False. Scam-token mechanics can increase losses, but legitimate assets and major pools can be targeted when a trade creates enough predictable price impact.
A sandwich attack means the wallet was hacked
False. The searcher uses separate transactions and does not need the user's private key.
The attacker changes the signed transaction
False. The signed fields remain unchanged. The attacker changes the pool state before the transaction executes.
Every poor swap price proves a sandwich
False. Ordinary price impact, volatility, route changes, token taxes, and unrelated transactions can also produce worse execution.
Every transaction before and after a trade is a sandwich
False. Researchers must compare addresses, pool interactions, directions, internal calls, token flows, and actual profit.
Zero slippage eliminates MEV
False. An extremely strict limit can make ordinary market execution unreliable and does not prevent every form of transaction-ordering value.
Paying more gas guarantees safety
False. Higher priority may improve inclusion competitiveness, but builders can consider private bundles, direct payments, and total block value.
A hardware wallet stops sandwich attacks
False. A hardware wallet protects the signing key, not public transaction visibility, liquidity, slippage, or block ordering.
A private route guarantees the quoted output
False. Other trades and liquidity changes can still occur before inclusion.
Splitting a trade is always safer
False. Splitting can reduce individual price impact but increases fees, time exposure, and the visibility of a repeated trading pattern.
Conclusion: protect the execution range, not only the wallet
A sandwich attack is a three-transaction MEV strategy. The searcher trades before a user's DEX swap, lets the user's transaction create additional price movement, and trades again afterward to close the position.
The exchange contract does not need to malfunction. The user's wallet does not need to be compromised. The opportunity comes from public or privileged visibility, predictable automated market maker pricing, user-authorized slippage, and control over transaction order.
Slippage matters because it defines the execution range the transaction will tolerate. Wider tolerance can create more room for extraction, while excessively strict limits can cause genuine trades to revert.
Liquidity and trade size determine how far the market moves. Thin pools and large swaps usually create greater exposure, but deep pools are not automatically immune when the trade is large enough.
Private submission, limit-based execution, stronger routing, smaller market impact, realistic deadlines, token analysis, and careful minimum-output review can reduce risk. None of them guarantees complete protection.
Wallet security remains essential, but it protects authorization rather than execution order. Traders must evaluate the token, route, pool, approvals, slippage, deadline, submission path, and final on-chain result as separate parts of one workflow.
The broader lesson is that sandwich attacks are not merely a bot or scam-token problem. They are a market microstructure issue created by the interval between visible intent and final settlement.
Your next action is to review the TokenToolHub swap safety guide before signing a large on-chain trade, then continue with the MEV guide to understand the infrastructure that determines final transaction order.
Review the complete trade before signing
Confirm the token contract, pool, route, active liquidity, price impact, minimum received, slippage, deadline, approvals, transaction-submission method, and maximum loss you are willing to accept.
FAQs
What is a sandwich attack in crypto?
A sandwich attack places one searcher transaction before a user's DEX swap and another after it to profit from the user's price impact.
Why is it called a sandwich attack?
The user's transaction sits between the searcher's opening and closing transactions, creating a three-part sequence.
How does a sandwich attack work?
The bot moves the pool price before the user, allows the user to trade at the changed price, and then reverses its position afterward.
Does the attacker need my private key?
No. The attacker submits separate valid transactions and does not need access to the user's wallet.
Can a sandwiched swap still succeed?
Yes. Many sandwiched swaps succeed because the final output remains above the minimum amount authorized by the user.
Why does slippage matter?
Slippage defines how much adverse movement the transaction accepts before reverting, which can determine how much room a searcher has.
Does lower slippage prevent every sandwich attack?
No. It reduces the permitted range but can also cause legitimate transactions to revert during normal market movement.
Can deep liquidity pools be sandwiched?
Yes. Deep liquidity raises the attack cost, but sufficiently large trades can still create profitable opportunities.
Why does trade size matter?
A larger trade usually creates more predictable price impact and can justify greater searcher capital and ordering payments.
Should I split a large swap?
Splitting can reduce individual price impact, but it also adds gas, pool fees, time risk, and repeated information leakage.
Are sandwich attacks a form of front-running?
Yes. The first searcher transaction front-runs the user, while the final transaction back-runs the user.
What is an MEV sandwich?
It is a sandwich attack understood as a form of maximal extractable value created through transaction ordering.
Do private transaction routes guarantee protection?
No. They can reduce public visibility but introduce provider trust and cannot prevent every market or token risk.
Can a hardware wallet stop a sandwich attack?
No. A hardware wallet protects signing keys but does not control liquidity, slippage, transaction visibility, or block order.
How can traders reduce sandwich exposure?
Review liquidity, route, price impact, minimum output, slippage, trade size, token mechanics, deadlines, and protected submission options.
How can I tell whether my trade was sandwiched?
Inspect surrounding block transactions for a related trade before yours and an opposite closing trade afterward using the same pool or route.
Is every bad swap price caused by a sandwich?
No. Ordinary price impact, volatility, token taxes, route changes, and unrelated market activity can also worsen execution.
Can sandwich attacks be eliminated completely?
No single user setting guarantees complete protection, although better execution controls and protocol design can reduce harmful extraction.
References and further learning
Use primary technical documentation when studying Ethereum transactions, MEV, transaction pools, protected submission, block construction, and automated market maker execution.
- Ethereum.org: Maximal Extractable Value
- Ethereum.org: Transactions
- Ethereum.org: Gas and Transaction Fees
- Ethereum.org: Proposer-Builder Separation
- Go Ethereum: Transaction Pool Namespace
- Flashbots Protect Overview
- Flashbots MEV-Boost Introduction
- Uniswap Documentation: Swap Concepts
This TokenToolHub guide is educational research only. It is not investment advice, trading advice, legal advice, tax advice, cybersecurity advice, or a guarantee of transaction protection. Always verify the token contract, pool, route, active liquidity, transfer rules, price impact, minimum received, slippage, deadline, approvals, transaction-submission method, and final on-chain result before trading.