A user initiates a token swap on a decentralized exchange through their Bitget Wallet: sending 10 ETH to receive USDC at a quoted rate. The transaction enters the public mempool, visible to all network participants before settlement. Within seconds, a sophisticated attacker detects the pending swap, broadcasts a competing transaction that executes first, pushing the price upward, then places the victim’s transaction after it, and finally sells their own position immediately after—capturing the difference. The user receives significantly fewer USDC than expected. This is a sandwich attack, and it exemplifies a category of risks that exist not because the wallet failed, but because the underlying blockchain infrastructure broadcasts transaction intent before execution.
Sandwich attacks exploit the temporal gap between transaction submission and finality. An attacker observes pending swaps in the mempool, manipulates the transaction ordering, and extracts value through slippage—the difference between the quoted price and the actual execution price. The attack is not a wallet vulnerability in the traditional sense. It is a protocol-level weakness that every user of public blockchains and decentralized exchanges faces. However, wallet-level design choices, protection mechanisms, and user practices can substantially reduce exposure. Understanding the mechanics, recognizing the signs, and implementing practical defenses transforms the attack from an invisible threat into a manageable risk.
How sandwich attacks work in the mempool
The mempool is the set of transactions broadcast but not yet included in a block. On Ethereum, Polygon, and other EVM-compatible chains, miners and validators can observe all pending transactions. A sandwich attack relies on three transactions executed in sequence: the attacker’s initial transaction (front-run), the victim’s swap, and the attacker’s exit (back-run). When a user broadcasts a large token swap, the attacker sees the transaction details—the input token, output token, amount, and slippage tolerance. The attacker then bids a higher gas price to ensure their transaction executes first, moving the market price. The victim’s swap then executes at a worse rate, and the attacker exits with profit.
The severity depends on liquidity, transaction size, and time of day. A small swap in a deep liquidity pool may suffer minimal slippage. A large trade during low-liquidity periods is far more vulnerable. The attacker profits from the difference between the price before their front-running transaction and the price after the victim’s swap. In some cases, the loss to the user can range from a few percent of the transaction value to much more in extreme cases. The attacker does not steal funds directly; they exploit predictable market mechanics that every participant can see.
Miner extractable value (MEV) is the broader technical term for this category of risk. Miners and validators have the power to determine transaction order within a block, and they can extract value by observing, reordering, or including transactions strategically. Sandwich attacks are one form of MEV exploitation. Others include liquidations that occur during volatile prices, arbitrage opportunities that execute before they are visible to users, and flash loan attacks that borrow and repay large quantities of assets within a single block to manipulate prices or access functions.
The attack is not necessarily carried out by a single attacker. Many MEV extraction strategies are automated, running continuously on relay services such as Flashbots Protect or other builders that aggregate transactions and optimize ordering. Some of these services aim to reduce MEV by randomizing order or using encryption; others are neutral infrastructure that miners and searchers use to find profitable transactions. The user’s exposure depends partly on which service is used and how the wallet or frontend routes transactions.
Why slippage settings matter more than they appear
When executing a token swap, the wallet allows the user to set a maximum slippage tolerance—the maximum acceptable difference between the quoted price and the actual execution price, usually expressed as a percentage. A 1% tolerance means the user will accept between 99% and 100% of the quoted amount. A 5% tolerance allows the swap even if execution is 95% to 100% of the quote. The slippage setting is the primary wallet-level defense against sandwich attacks because it prevents execution at an unfavorable price.
Setting slippage too high removes the protection entirely. A user who sets 50% slippage will accept almost any execution price, turning their swap into an invitation to MEV extraction. Conversely, setting slippage too low can cause the transaction to fail—sometimes repeatedly—if market volatility exceeds the threshold. The user must then decide whether to retry with higher slippage or abandon the swap. Under time pressure or frustration, users often increase slippage to ensure the transaction goes through, inadvertently lowering their defenses.
Bitget Wallet and other decentralized exchange interfaces typically suggest a default slippage of 0.5% to 1% for most trades. This is a reasonable starting point for stable pairs with deep liquidity. For volatile assets, new tokens with thin order books, or trades during periods of high network activity, 1% to 3% may be realistic. The key is to adjust based on the specific token pair, liquidity, and market conditions rather than using a fixed percentage for every trade. A user should also understand that slippage protection prevents execution only if the price moves against them; it does not prevent the sandwich attack itself from occurring or the attacker from profiting.
Mempool observation and timing as early warning signals
The mempool is public on most blockchains. Tools such as etherscan, Blocknative, and Flashbots Transparency Dashboard allow users to observe pending transactions and their gas prices. A user who checks the mempool immediately before and after broadcasting a swap can sometimes identify sandwich attack patterns. If multiple high-value transactions for the same token pair appear within a few seconds before their transaction, followed by rapid exit trades, the pattern indicates possible MEV extraction.
More concretely, a user can observe whether their transaction took longer to execute than usual, whether the execution price deviated significantly from the quote despite low slippage, or whether the transaction cost in gas seemed reasonable for the network conditions at that moment. If a swap that was quoted at a favorable rate executes at a much worse price, and the user reviews the mempool to find that several other transactions were ordered before theirs despite offering lower gas prices, that is a sign of sandwich attack activity.
Some advanced users employ tools such as MEV Block Explorer or other analytics to reconstruct what happened. This forensic approach is useful after the fact, but the real-time detection signal is simpler: if a swap fails due to slippage, attempt it again with identical settings. If it fails multiple times in rapid succession with different slippage settings, an active sandwich attacker is likely present. The appropriate response is to wait a few minutes and retry, rather than continuously increasing slippage in hopes that one transaction will go through.
MEV protection mechanisms and their limitations
Private transaction pools, such as Flashbots Protect or MEV Guard, promise to hide transaction details from the public mempool until they are included in a block. By submitting the swap through a private relay instead of broadcasting it publicly, the user prevents attackers from observing the transaction details before execution. Bitget Wallet and other secure wallet implementations may offer integration with these services, either directly or through the DeFi protocol interface.
The limitation is not cryptographic but organizational and probabilistic. Private relays do not eliminate MEV; they relocate it. The relay builder, the validator, or the protocol itself may engage in sandwich attacks or sell transaction information to MEV extractors. Additionally, multiple relays exist, and no single relay processes all transactions. A user who submits through one private relay while the rest of the network uses another may actually become more visible, not less. The effectiveness of private mempool protection depends entirely on the relay’s integrity, the validator’s incentive structure, and adoption across the network.
Batch auctions and encrypted mempools represent a longer-term approach. Protocols such as MEV-Burn, Threshold Encryption, and encrypted transaction ordering attempt to remove the attacker’s ability to order transactions predictably. However, these require changes at the protocol level or consensus, and they introduce complexity and latency. As of today, most public blockchains—including Ethereum, Polygon, and Solana—have not fully implemented encryption-based MEV mitigation.
Intent-based architectures, such as CoW (Coincidence of Wants) swaps, allow users to express settlement intent without revealing execution details to miners. The swap is settled by a separate solver process that matches users directly, avoiding the mempool entirely. This approach can eliminate sandwich attacks for users participating in the system, but it introduces a new dependency on the solver and may reduce liquidity access compared to traditional decentralized exchanges. Integration into a best crypto wallet would require the wallet to offer the option as an alternative route.
Practical defensive measures within Bitget Wallet’s workflow
The first defense is to understand the token swap mechanics within the wallet. Most modern wallets, including Bitget Wallet, show a preview of the swap before confirmation, displaying the input amount, output amount, estimated price, slippage, and network fees. The user should verify that the output token is correct, the amount is reasonable given the input, and the slippage percentage matches the user’s tolerance. Copy-paste errors, token name confusion, and careless approval are common sources of loss that have nothing to do with sandwich attacks but can be caught at this stage.
Second, monitor network conditions. During high congestion—usually visible through high average gas prices—sandwich attacks become more profitable because the attacker can bid higher gas prices to prioritize their transactions. Avoid large swaps during peak hours if possible. If a swap is time-sensitive, confirm that the slippage setting accounts for current volatility before broadcasting. Some wallet interfaces provide real-time gas price data and network congestion indicators; check these before confirming.
Third, use smaller transaction sizes for frequent trades. A $500 swap is far less attractive to an attacker than a $50,000 swap because the MEV profit scales with the amount being traded. If large amounts must be moved, consider splitting them into multiple smaller swaps over time. This increases total fees and requires more patience, but it reduces exposure to any single sandwich attack. The wallet’s transaction history and portfolio tracking features can help monitor these accumulated changes.
Fourth, if available within the wallet interface or connected decentralized exchange protocol, select private mempool submission. If Bitget Wallet offers integration with Flashbots Protect or similar services, use it for sensitive swaps. Read the documentation to understand what protections the service provides and what information is retained. Accept that private relays reduce but do not eliminate MEV risk; they are a defensive layer, not an absolute guarantee.
Fifth, enable two-factor authentication and hardware wallet support if available. Sandwich attacks do not steal keys or drain wallets; they exploit smart contract interactions that the user explicitly approves. However, device security affects whether the user’s transaction can be intercepted or modified before broadcasting. A compromised device can be used to confirm swaps that the user did not intend, or to alter the recipient address or slippage settings before submission. Hardware wallet confirmation and PIN protection can prevent such tampering.
Recognizing and responding to failed or suspicious swaps
A swap may fail for several legitimate reasons: insufficient liquidity, slippage exceeded, gas limit too low, or the receiving wallet address being incorrect. It may also fail because an attacker sandwiched the transaction and the actual execution price fell outside the user’s slippage tolerance. The first response is not to panic-increase slippage and retry immediately. Instead, wait several minutes and check whether network conditions have changed. Monitor the mempool to see if there are unusually high volumes of the same token pair being traded.
If a swap executes successfully but the amount received is significantly lower than the quote shown by the wallet interface, examine the transaction on a blockchain explorer. Compare the execution price to the price of the token pair on Uniswap, SushiSwap, or other sources at the exact time the swap occurred. If the on-chain price was much better than the execution received, MEV extraction occurred. The wallet did not fail; the user experienced the predictable cost of executing transactions on a transparent blockchain with public mempool visibility.
For larger amounts or repeated sandwich attacks on the same token pair, consider whether the DeFi wallet supports alternative swap routes. Different decentralized exchanges have different liquidity pools, fee tiers, and router algorithms. Uniswap v3 offers multiple fee tiers (0.01%, 0.05%, 0.30%, 1%) with different liquidity concentrations; routing the same swap through a different fee tier can avoid the main sandwich attack target. Some wallets aggregate across multiple exchanges; using that aggregation feature rather than selecting a single exchange can reduce exposure.
The broader context of MEV and protocol-level solutions
Sandwich attacks represent a fundamental tension in blockchain design: transparency is necessary for decentralization, but it enables transaction ordering attacks. The technical community has recognized this for years, and several long-term solutions are under development. Ethereum’s merge to proof-of-stake opened the door for MEV-Burn mechanisms and encrypted mempools. Layer 2 solutions such as Arbitrum and Optimism provide some MEV mitigation through different sequencing mechanisms, though they are not immune.
Solana, despite high throughput, has faced sandwich attack issues because validators see transactions before they are finalized. BNB Chain and other EVM-compatible networks inherit the same MEV dynamics as Ethereum. A user choosing among blockchains to minimize sandwich attack exposure might prioritize those with encrypted mempools, intent-based architectures, or sequencing designs that make transaction reordering difficult. However, the choice of blockchain is usually driven by liquidity, assets, and application availability rather than MEV protection.
In the nearer term, wallet-level mitigations and user discipline remain the primary defenses. Bitget Wallet’s focus on security, multi-chain asset management, and DeFi integration positions users to implement these defenses effectively. The wallet cannot eliminate sandwich attacks, but it can expose the risk, offer protective settings, and allow users to make informed choices about slippage, routing, and mempool privacy. The user’s responsibility is to understand that risk and apply appropriate caution during each transaction.
Frequently asked questions
Can a sandwich attack steal my private keys or drain my wallet directly?
No. A sandwich attack exploits the MEV available in transaction ordering and liquidity mechanics; it does not compromise cryptographic security or bypass wallet authorization. The attacker profits from the difference between the quoted execution price and the actual price, but they do not access your private keys. To execute the attack, you must voluntarily approve and sign the swap transaction. Device security and transaction verification prevent attackers from modifying the swap parameters before you approve, but the swap itself is your authorized action.
What is the ideal slippage setting to avoid sandwich attacks?
Slippage settings depend on the token pair liquidity, market volatility, and network conditions. For stable pairs with deep liquidity, 0.5% to 1% is typical. For volatile or less liquid assets, 1% to 3% may be necessary. Slippage protection prevents execution if the price moves against you, but it does not stop the sandwich attack itself. If a swap fails multiple times in succession due to slippage, an active attacker is likely present; wait and retry rather than continuously increasing slippage.
Should I always use private transaction pools when available?
Private transaction pools such as Flashbots Protect reduce visibility to public mempool attackers, but they do not eliminate MEV entirely. The pool operator, validator, or builder may themselves extract MEV. Adoption is imperfect; submitting through one private pool while most network participants use another may increase visibility instead of reducing it. Use private pools as one layer of defense for sensitive or large swaps, but do not treat them as an absolute guarantee. Understand what the specific pool operator promises and what trade-offs you accept by using it.