Overview
Table of Contents
What Is Slippage in Crypto
Slippage is the difference between the price you expected to receive when placing a trade and the price at which the trade actually executes. In highly liquid markets with large order books and stable prices, slippage is minimal. In low-liquidity markets, thin order books, or during periods of high volatility, slippage can be significant — sometimes representing a meaningful percentage of the transaction value.
Slippage occurs because markets move continuously. Between the moment you submit a trade and the moment it executes, the available price may have changed. On centralized exchanges, this happens because other orders ahead of yours consumed the liquidity at the price you expected. On decentralized exchanges (DEXs), this happens because the automated market maker (AMM) adjusts the price based on the ratio of tokens in the liquidity pool — the larger your trade relative to the pool size, the more the price moves against you during execution.
Slippage is not always negative. Positive slippage occurs when the price moves in your favor between order submission and execution — for example, a token’s price drops slightly between when you placed a buy order and when it executed, meaning you received more tokens than expected. Negative slippage is more common and more significant in low-liquidity or high-volatility conditions. Understanding which type of slippage you are likely to encounter — and under what market conditions — is fundamental to evaluating the true cost of any DEX transaction.
Slippage >Slippage on Centralized Exchanges vs DEXs
chanism of slippage differs significantly between centralized exchanges and decentralized exchanges. This difference matters because it determines what attack vectors are available to bad actors and what protective measures are effective.Centraliz>Centralized Exchange Slippage
entralized exchange with an order book — Binance, Coinbase, Kraken — your buy or sell order is matched against existing orders from other participants. Slippage occurs when the volume at your desired price is insufficient to fill your entire order, and the remainder is filled at progressively less favorable prices further into the order book. This is called price impact and is directly related to order size relative to available liquidity at each price level.Market orders — which execute immediately at the best available price — are most susceptible to slippage on centralized exchanges. Limit orders eliminate slippage by specifying the exact price you will accept, but they may not execute if the market does not reach your price. For large trades on centralized exchanges, using limit orders or splitting the order across multiple smaller executions over time reduces slippage significantly.
DEX and AMM Slipp>DEX and AMM Slippage
ed exchanges using automated market makers — Uniswap, PancakeSwap, Curve, SushiSwap — slippage works through a mathematically determined price function. The most common AMM model uses a constant product formula: x × y = k, where x and y are the quantities of the two tokens in the pool and k is a constant. When you buy Token A using Token B, you add Token B to the pool and remove Token A. This changes the ratio x/y and therefore the price.The price impact of a given trade is mathematically determined by pool depth — the total value locked in the liquidity pool. A pool with $10 million in liquidity will show minimal price impact on a $1,000 swap. A pool with $50,000 in liquidity may show 5–10% price impact on the same $1,000 swap. This is why newly launched tokens with thin liquidity have high slippage — not because the token is necessarily fraudulent, but because the pool depth is insufficient for the transaction size.
Most DEX interfaces display a slippage tolerance setting — typically 0.5% to 1% by default. This setting tells the smart contract the maximum price movement you will accept before the transaction reverts. If slippage exceeds your tolerance, the transaction fails and you pay only the gas fee. If slippage is within your tolerance, the transaction executes at whatever price results, up to your maximum tolerance. This tolerance setting is the mechanism exploited by MEV sandwich attacks.
What Is MEV — The Invisible Ta>What Is MEV — The Invisible Tax on DEX Users
lue, formerly Miner Extractable Value) refers to the profit that can be extracted from the ordering of transactions within a block. On public blockchains, transactions are submitted to a public mempool — a waiting area where pending transactions are visible to anyone before they are included in a block. MEV bots monitor this mempool and exploit the ordering of transactions for profit, effectively acting as an invisible tax on DEX users who do not take protective measures.According to Flashbots data, MEV revenue on Ethereum averaged over $500,000 per day in 2023, stabilizing at approximately $300,000 daily in 2024. Sandwich attacks constituted $289.76 million, or 51.56% of the total MEV transaction volume of $561.92 million in the period analyzed.
Cointelegraph Research, citing exclusive data from analytics platform EigenPhi, found that sandwich attacks on Ethereum caused approximately $60 million in trader losses between November 2024 and October 2025, based on analysis of more than 95,000 documented sandwich attacks. Despite a sharp drop in monthly extraction — from nearly $10 million in late 2024 to approximately $2.5 million by October 2025 — attack frequency remained high at 60,000 to 90,000 per month even as monthly DEX volumes rose from $65 billion in Q1 2025 to over $100 billion by Q3.
How a Sandwich Attack Works — Step by St>How a Sandwich Attack Works — Step by Step
and directly harmful MEV attack for retail DEX users. Here is exactly how it works, using a concrete example.You submit a transaction to buy Token X on Uniswap. You set your slippage tolerance to 2% because Token X has moderate liquidity. You click confirm in your wallet. The transaction is now in the public Ethereum mempool — visible to every MEV bot running on the network before it is included in a block.
An MEV bot detects your pending transaction and calculates that it can profitably sandwich you within your 2% slippage tolerance. In the same block, it inserts three transactions in the following order:
- Front-run: the MEV bot buys Token X immediately before your transaction, paying a slightly higher gas fee to ensure priority. This purchase drives the price of Token X upward.
- Your transaction: executes at the now-higher price — the price increase falls within your 2% slippage tolerance, so the transaction does not revert. You receive fewer Token X than you expected.
- Back-run: the MEV bot immediately sells the Token X it bought in step 1, now at the higher price your purchase helped create. It pockets the spread between its buy price and its sell price, minus gas costs.
The net result: you paid more for Token X than you needed to. The MEV bot extracted the difference. A single USDC-to-USDT swap on Uniswap V3 — a stablecoin swap that many users would consider low-risk — resulted in a sandwich attack loss of over $215,000, illustrating that even large transactions on well-established pools are not immune.
In 2025, approximately 38% of all sandwich attacks on Ethereum targeted stablecoin pools — attractive targets because their assets trade within a predictable, narrow price range, making the front-run/back-run calculation more reliable for bots.
The Concentration Problem
On Ethereum, a singl>The Concentration Problemromsubway.eth” controlled approximately 70% of all sandwich attacks in 2025, while average profit per attack dropped to just $3 — illustrating how the practice has become industrialized, high-volume, and dominated by a few sophisticated operators. This concentration means that a small number of automated actors are systematically extracting value from hundreds of thousands of retail DEX transactions per month.
Research published in December 2025 confirmed 2,932 private sandwich attacks in November-December 2024 alone, affecting 3,126 private victim transactions and producing $409,236 in losses — with a single bot accounting for nearly two-thirds of private front-runs. This demonstrates that private transaction routing — while reducing public mempool exposure — does not eliminate sandwich risk entirely.
Private Mempools and Their Limitations
In response to >Private Mempools and Their Limitationsutions emerged. Private transaction relays like Flashbots Protect and MEV Blocker route your transaction directly to block builders without passing through the public mempool, reducing exposure to front-running bots.
Research tracking user behavior after sandwich attacks found that around 40% of victims migrate to private routing within 60 days of being sandwiched, rising to 54% after repeated exposures. However, private channels themselves remain exploitable — private sandwich activity is heavily concentrated on a small set of DEX pools, and users who move to private routing often appear unaware that they can still be sandwiched.
On Solana, Jito’s public mempool — a key enabler of sandwich attacks — was shut down in March 2024, but private mempools have since filled the gap, demonstrating that the economic incentives behind MEV attacks are durable enough to persist even after significant structural changes to the mempool infrastructure.
Other MEV Forms Affecting Retail Users
Pure arbitrag>Other MEV Forms Affecting Retail Userssitive for retail users — MEV bots capture price differences between pools and exchanges, which serves to equalize prices across the market. However, arbitrage bot competition increases gas fees in blocks where large opportunities are being competed for, raising the cost of all transactions in those blocks during high-activity periods.
Liquidation MEV affects borrowers on DeFi lending protocols such as Aave and Compound. MEV bots compete to be first to liquidate undercollateralized positions. While liquidations are a necessary mechanism for protocol solvency, bot competition can result in liquidations at marginally worse prices for the borrower than would occur in a less competitive environment.
Just-In-Time (JIT) liquidity is a sophisticated MEV strategy where a liquidity provider adds concentrated liquidity to a pool immediately before a large swap and removes it immediately after — capturing a disproportionate share of the swap fees. This is controversial because it can reduce the fees earned by long-term liquidity providers without directly harming the swapper.
Fake DEX Context — How Slippage Is Exploited in Scams
Slippage s>Fake DEX Context — How Slippage Is Exploited in ScamsXs but also as a mechanism in scam tokens and fraudulent DEX interfaces. This is the context most directly relevant to ScammerWatch’s mission: understanding how slippage mechanics are used to steal from retail users on fraudulent platforms.
Honeypot Tokens — Buy But Cannot Sell
A honeypot token is a fraudule>Honeypot Tokens — Buy But Cannot Selln buy the token freely but cannot sell it. The buy transaction executes normally — the user receives the token and may see an apparently rising price on the chart. But the sell function is disabled or restricted in the contract code through one of several mechanisms: a transfer restriction that applies to all addresses except the developer’s, a blacklist function that prevents the sell transaction from executing, a 100% sell tax that takes the entire value of any sell transaction, or a require() statement in the contract that always reverts sell transactions.
Slippage is directly relevant to honeypot detection. A token that requires unusually high slippage tolerance to buy — 10%, 15%, 25% or more — often indicates either a high transaction tax or deliberate contract design to prevent sells. When a sell transaction fails repeatedly regardless of how high the slippage tolerance is set, this is the defining indicator of a honeypot: no slippage setting makes the sell possible because the contract does not permit sells from user addresses.
Before buying any token on a DEX, check it on a honeypot detection tool. Honeypot.is and Token Sniffer (tokensniffer.com) simulate both a buy and a sell transaction against the actual contract and report whether the sell is possible, what tax rates apply, and what contract-level restrictions are in place. This check takes under one minute and eliminates the most common form of DEX token fraud.
High-Tax Rug Pull Tokens
Some fraudulent tokens implement an extreme transacti>High-Tax Rug Pull Tokensom every buy and sell transaction that routes to a developer-controlled wallet. Moderate taxes of 1–3% are used by some legitimate projects to fund liquidity or marketing. Extreme taxes of 10–30% or higher are a documented rug pull preparation pattern: the developer collects tax revenue on every transaction while the token’s trading volume is promoted, then removes all liquidity when the accumulated tax revenue and liquidity position are large enough to make the exit worthwhile.
High-tax tokens require correspondingly high slippage tolerance settings to execute — because the effective price impact after the tax is applied exceeds normal slippage tolerance. A token with a 15% buy tax requires at least 15% slippage tolerance to execute the buy. This is why token promoters for high-tax tokens frequently include instructions to “set slippage to 15%” or higher in their Telegram and Discord channels — they are not warning you about market conditions, they are telling you to set your MEV sandwich exposure to the maximum level required by their own tax mechanism.
When a token requires slippage above 5% and you cannot find a clear technical reason — such as a publicly documented liquidity bootstrapping mechanism — verify the contract code for tax functions before proceeding. The tax rate and tax recipient address should be identifiable in the contract’s verified source code on Etherscan or BscScan. If the contract is not verified, stop. An unverified contract on a DEX should be treated as a red flag regardless of any other positive signals about the project.
Fake DEX Interfaces
Fraudulent DEX interfaces are phishing sites designed to look like Uni>Fake DEX Interfaces or other popular DEXs. They are promoted through social media ads — particularly on Twitter/X and Telegram — search engine advertising, and community channels around token launch events when large numbers of users are simultaneously searching for a way to buy a specific new token.
Fake DEX interfaces exploit slippage in several documented ways. The most common is requiring wallet connection and a transaction approval before displaying the swap interface — the approval itself is a malicious contract approval that allows the site to drain the connected wallet regardless of whether a swap is executed. Others display a functioning-looking swap interface but route transactions to a contract that takes the input tokens without delivering the output, using a high slippage tolerance setting to absorb the effective 100% price impact of a trade that returns nothing.
A third pattern exploits the normal practice of setting higher slippage for new tokens: a fake DEX interface instructs users to set an unusually high slippage tolerance — “set slippage to 49% to avoid failed transactions” — which allows MEV bots or the contract itself to extract most of the transaction value while still technically executing the swap.
How to identify a fake DEX interface:
- Verify the domain before connecting your wallet: Uniswap is app.uniswap.org, PancakeSwap is pancakeswap.finance, 1inch is app.1inch.io, dYdX is dydx.exchange. Any domain that is not exactly the official domain is not the official DEX — verify character by character.
- Check what the wallet approval requests: a legitimate DEX swap approval requests permission to spend a specific token amount for the swap. A “setApprovalForAll” request, an unlimited approval for an unfamiliar contract, or an approval request before any swap parameters have been selected are red flags.
- Do not interact with DEX links from social media or Telegram unless you have verified the official domain first: access the official DEX domain through the project’s official documentation — not through a link in a group, a pinned Telegram message, or a reply to a tweet.
- Verify the token contract address before swapping: find the official token contract address from the project’s verified official website or documentation and paste it into the DEX manually. Do not search by token name in the DEX interface — fake tokens with identical names and similar logos are routinely deployed to impersonate popular tokens, and the real-looking token in the DEX search results may have been promoted to the top of results through transaction volume manipulation.
Infinite Approval Exploitation
When you first interact with a DEX to swap a token, the DEX requests an app>Infinite Approval Exploitationens on the contract. By default, many DEX interfaces request unlimited approval — permission to spend any amount of that token from your wallet, at any time in the future, until you explicitly revoke the approval. This persists even after the swap is completed.
If the DEX contract is subsequently exploited — as has happened to several legitimate DEX router contracts — an unlimited approval gives the exploiter access to your entire token balance, not just the amount you intended to swap. The same applies to malicious DEX contracts from the start: an unlimited approval to a fraudulent contract gives it permanent access to drain any amount of the approved token at any time.
Revoke unused token approvals regularly using revoke.cash for EVM chains, or through your wallet’s built-in approval management if available. When approving tokens for a swap, choose “custom amount” and approve only the specific amount needed for your current transaction — most major DEX interfaces offer this option in an advanced settings menu.
Practical Slippage Settings — Safety Guidelines by Market Type
The following guidelines help balance transaction r>Practical Slippage Settings — Safety Guidelines by Market Typeng scenarios.
- Stablecoin swaps (USDC/USDT/DAI on major pools): 0.05% to 0.1% is typically sufficient and recommended. Research shows that 38% of sandwich attacks target stablecoin pools precisely because the predictable price range makes the attack calculation more reliable for bots. Low slippage on stablecoin swaps significantly reduces sandwich attack viability.
- Major token pairs (ETH/USDC, BNB/USDT on large DEXs): 0.1% to 0.5% is generally appropriate. Higher settings increase MEV sandwich attack exposure without meaningful benefit for large liquid pools.
- Mid-cap tokens with moderate liquidity: 0.5% to 1% is generally appropriate. Check the liquidity depth in the pool before trading a large position — most DEX interfaces show this in the swap interface.
- Low-liquidity new tokens: if the token genuinely requires 5%+ slippage to trade, this indicates either very thin liquidity or a high transaction tax. Both warrant investigation before proceeding. Run a honeypot check, verify the contract, and understand the tax structure before buying.
- Never set slippage above 10% without understanding exactly why it is required: high slippage requirements on a new token are more often a scam signal than a liquidity issue. The required slippage being set to exactly the tax rate — a 15% tax requiring 15%+ slippage — is a documented pattern in pre-rug tokens.
- Use MEV protection where available: Flashbots Protect (protect.flashbots.net) and MEV Blocker (mevblocker.io) are free RPC endpoints that route transactions privately, reducing public mempool sandwich attack exposure. Configure one of these as a custom RPC in your wallet for regular DEX trading. Note that private routing reduces but does not eliminate sandwich risk — private mempools themselves can be exploited, particularly on a small set of high-activity DEX pools.
Report a Fake DEX or Scam Token
If you have encountered a fake DEX interface, a honeypot token, a high-tax rug pull token, or >Report a Fake DEX or Scam Tokenwallet approvals, submit a report at scammerwatch.com/report-a-scam . Include the contract address of the scam token or the URL of the fake DEX, the chain it is deployed on, and any relevant transaction hashes. Contract addresses and transaction hashes are the most useful evidence for provider-level abuse reports targeting scam token infrastructure. Including a honeypot test result from honeypot.is or tokensniffer.com strengthens any report involving a suspected honeypot token.
Author
