Sandwich attacks on BNB Chain: how they work and how to limit them

A sandwich bot buys right before your swap and sells right after it. How it works, what your slippage setting caps, and what BNB Chain and private RPCs changed.

Every swap you send is visible before it is final. Between the moment your wallet broadcasts it and the moment it lands in a block, other people can see it, and some of them run bots that profit from trades they can see coming. The best known trick is the sandwich. It does not steal your tokens. It makes your swap execute at a worse price and keeps the difference.

The good news is that the damage has a ceiling, and you set it. This guide explains the mechanism with numbers, shows exactly what your slippage tolerance limits, and covers what BNB Chain and private RPCs have changed.

What a sandwich is

The general name for this kind of profit is MEV, maximal extractable value: value captured by choosing which transactions go into a block and in what order. The Ethereum documentation on MEV describes the sandwich plainly. A searcher watches for a large DEX trade, buys just before it, and sells just after it at the higher price the large trade created. In its words, users who are sandwiched "face increased slippage and worse execution on their trades."

Three transactions end up next to each other:

1. Front-run. The bot buys the token you are buying. The price moves up.
2. Your swap. You buy at the worse price the bot created, and push the price up further.
3. Back-run. The bot sells into the price you pushed, at a profit.

A worked example

Take a constant-product pool with 1,000 BNB and 770,000 USDT, charging 0.25 % per trade like a PancakeSwap V2 pool. You buy BNB with 7,700 USDT. With nobody in the way, the pool pays you 9.8765 BNB.

Now a bot sees your transaction. It knows your minimum received, because that number is written into your transaction. In the simplest version of the attack, it buys just enough BNB first that your swap still clears your minimum, and not a bit more. At 1 % tolerance that front-run is about 3,903 USDT. Here is how the attack plays out at different tolerances, computed with the pool's own formula:

Tolerance	You receive	Your loss	Bot's profit
1 %	9.7777 BNB	about $76	about $58
0.5 %	9.8271 BNB	about $38	about $29
0.1 %	9.8666 BNB	about $7.60	about $5.80

Losses are measured against the 9.8765 BNB quote, and the bot's profit is before gas.

Two things stand out.

First, your loss equals your tolerance times the quote, almost exactly. That is the ceiling. The bot cannot push you below your minimum received, because then your transaction reverts, nothing trades, and its own front-run is left holding tokens it bought at a high price.

Second, the bot keeps most of what you lose. The rest goes to pool fees. Gas on BNB Chain is cheap enough that even the 0.1 % row is worth attacking in this example, but the prize is ten times smaller than at 1 %.

What your slippage setting does and does not do

Your slippage tolerance becomes a minimum output in the transaction. If execution would return less, the contract reverts. That makes slippage your hard limit on sandwich damage, and it is also why bots prefer victims with loose settings. BNB Chain's own explainer on sandwich attacks says attackers prioritise transactions with higher slippage tolerances and like low-liquidity pools, where a small purchase moves the price a lot.

What slippage does not do is hide your trade. A tight tolerance makes you a smaller target. It does not make you invisible. And it has a cost: set it too tight and ordinary price movement makes your swaps fail.

A sensible approach:

• Liquid pairs such as BNB against major stablecoins: 0.1 % to 0.5 % is usually enough.
• Thin or volatile tokens: you may need more, but every extra tenth of a percent is room a bot can use.
• Tokens with a transfer tax need the tax on top of your real tolerance, which makes them more exposed. Our guide to taxed tokens covers this.
• Large orders in shallow pools are the juiciest targets. Splitting an order across pools lowers its price impact, which also shrinks what a sandwich can extract. More on that in how aggregators split routes.

What BNB Chain changed in 2025

On BNB Chain, most blocks are assembled by specialised block builders who bid for the right to fill the block, a design called proposer-builder separation. The specification is BEP-322. Unlike on Ethereum, there is no relay between builders and validators. Validators choose the most profitable bid and rely on their reputation instead.

That structure gave the ecosystem a lever. On 2025-03-18 BNB Chain launched the Good Will Alliance: two key builders, BlockRazor and 48 Club, deployed filters against sandwich attacks, and validators were asked to accept block bids only from builders on an agreed list. In July 2025 BNB Chain reported that daily sandwich attacks had fallen from about 140,000 to under 1,000, a drop of more than 95 %, with all active validators enforcing the rules. The same report says cross-block attacks, where the legs land in different blocks, are still hard to detect.

Blocks also got much faster. BNB Chain went from 3 second blocks to 0.45 seconds over 2025 and early 2026, and its own specification notes that this narrows the time searchers, builders and validators have to coordinate. Our post on BNB Chain block times has the full timeline.

Those are BNB Chain's own figures, and they describe the network as a whole. They do not mean a given swap cannot be sandwiched, which is why your own settings still matter.

Private RPCs: what they change

Your wallet sends transactions to an RPC endpoint, which normally gossips them to the whole network. A private RPC sends them to block builders directly instead, so bots watching the public mempool never see them.

BNB Chain keeps an official MEV user guide that lists free private RPCs (from PancakeSwap, 48 Club, Merkle and BlockRazor), wallets with protection built in, and paid builder services. Switching is usually a matter of adding a custom network in your wallet with the private RPC URL.

Read the promises carefully, though:

• The wording is relative. BNB Chain's guide says users are "less likely" to be front-run, and that transactions are "exposed to fewer parties." 48 Club describes "mitigating the risk." Treat it as a strong reduction, not a guarantee.
• Someone still sees your transaction. The RPC operator and the builders it forwards to receive it before it is final. You are choosing whom to trust.
• Some endpoints share your transaction with back-runners in exchange for a rebate. BlockRazor, for example, says it returns 60 % of the distributable back-run revenue to users by default. A back-run that happens after your swap does not worsen your price, but you should know it exists.

Where Tirio fits

A Tirio swap is an ordinary transaction that your own wallet signs and sends. That has two consequences.

• Your minimum received is enforced on chain. The quote's minimum is written into the transaction, and Tirio's Router checks what actually reached your address against it. Anything less reverts the whole swap. The default tolerance in the app is 0.5 %, and the app warns from 5 % upward.
• Your wallet decides the path. The transaction goes out through whichever RPC your wallet is set to use. If you point your wallet at a private RPC, your Tirio swaps travel that way like any other transaction.

A short checklist

1. Keep tolerance as tight as the pair allows. It is the one setting that caps your worst case.
2. Be careful with size in thin pools. Check price impact before you sign. High impact means a fat target.
3. Consider a private RPC from BNB Chain's official list, and read what it promises.
4. Check the receipt after unusual fills. If you received close to your minimum on a liquid pair, look at the transactions just before and after yours in the block.

For the vocabulary used here, see the glossary. For how slippage and price impact differ, see price impact vs slippage.