In the previous session, we discussed the different types of MEV. Now let's focus our attention on the most notorious one: Sandwich Attacks.

Figure 1: TOKEN Top50 subjected to sandwich attacks during 2025.1.1 - 2025.4.10

According to the data collected by BlockRazor, in the past 3 months, the most used TOKEN for Sandwich Bots are scattered. Except for BTCB and ETH, the main target is Meme Coin, which has a high price volatility. Users usually set a large slippage in order to avoid failure execution. High slippage and price volatility make Meme coins a perfect prey for sandwich attacker.

During the active period of BSC Meme Coin, we observed a significant increase in the phenomenon of sandwich attacks, and even token launch on the FourMeme platform suffered from sandwich attack [1]. On March 18, 2025, FourMeme encountered a sandwich attack while creating liquidity for the meme coin Mubaraking (0xbe1171610cFD279b8adC6A80240D541Fd9a4b087). An attacker frontrun the transaction, preemptively established the liquidity pool, and added 87.90 BNB to the pool. This caused a significant price deviation when FourMeme added liquidity to the pool. Subsequently, the attacker withdrew 87.9 BNB of liquidity in a backrun transaction and sold their holdings of Mubaraking (262.3M MubaraKing → 20.26 BNB). The purchase price for these Mubaraking was 9.06 BNB, resulting in the attacker earning a profit of 11.2 BNB from this attack.

Undoubtedly, sandwich attacks have provided a terrible experience for meme users, causing them to suffer significant financial losses.

Figure 2: The Four.meme platform was subjected to a sandwich attack while adding liquidity to the pool on 2025.3.18

A Brief History of the BSC Sandwich Attackss

To clearly illustrate the evolution of sandwich bots on the BSC chain, we divide it into three distinct eras:

Barbaric Era

We define this era as the time before the emergence and promotion of secure RPC applications on BSC.

In the barbaric era, transactions were almost entirely sent through the mempool, and there was virtually no protection specifically against sandwich attacks on-chain. The only interactions were horizontal competition and opportunity exploitation among sandwich bots.

The barbaric era can be further subdivided based on the progress of BSC-PBS (i.e., the implementation of BEP 322):

Before BEP 322 Implementation

During this period, sandwich attacks primarily occurred through Gas Wars. A Gas War is a phenomenon of bidding for block space based on Gas Price, where users continuously raise the Gas Price to enhance the competitiveness of their transactions, allowing them to be packed into blocks more quickly and achieve a higher position. This phenomenon was exploited by sandwich bots for sandwich attacks, resulting in what is known as Gas War Sandwich — after capturing a victim's transaction, the sandwich bot submits a front transaction with a high Gas Price, ensuring that the frontrun transaction is placed before the victim's transaction in the block, thereby completing the frontrun.

0x00…e534 is a typical Gas War sandwich bot. The chart below illustrates a typical Gas War attack case. The Gas Price of the victim's transaction 0xfd…68ca was 3 Gwei, while the attacker constructed a front-run transaction 0xad…e7e3 with a Gas Price as high as 32.743267649 Gwei, allowing this transaction to be prioritized above the victim's transaction in the block. Subsequently, the attacker constructed a backrun transaction with a Gas Price of 3 Gwei, selling the entire amount of the asset purchased in the frontrun transaction to realize a profit. The reason the frontrun transaction had an extremely high Gas Price was that the same opportunity was targeted by multiple sandwich bots, which competed for the opportunity by continuously raising their Gas Price.

Figure 3: Schematic of the ordering of transactions in the block for the Gas War sandwich attacks

After the implementation of BEP 322

The implementation of PBS is a gradual process, initially there are multiple MEV solution providers on the chain, which are integrated with a certain number of validators, and due to the different details of the solution implementations, the coverage of MEV solutions integrated by BSC validators is not high. After the implementation of BEP 322, the validators integrated a unified MEV solution, the Builder service tended to be unified, and the sandwich bots could attack by monitoring the Mempool transaction and then constructing the Bundle directly, and their development cost decreased, leading to extremely rampant sandwich bots at this stage. The following figure is a typical example of atomic sandwich attacks. 0x52...1798 is the chain head of the atomized sandwich bot, which figures out that transaction 0x9e...300a needs to buy 5M BDOG, it constructed two transactions: one for buying BDOG and one for selling BDOG, and uses the SendBundle method to send three transactions to the Builder in the order of frontrun transaction, victim transaction, backrun transaction. In the case of a successful attack, profits are made. If the attack fails, the frontrun transaction and backrun transaction will not be packed out of the block and the attacker pays 0 cost for this attack.

Figure 4: Schematic of the transaction ordering in the block for the atomic sandwich attacks

Figure 5: Schematic of the atomic sandwich attacks in the TOKEN transaction perspective

Due to the extremely low attack costs during this period, there were a large number of active atomic sandwich attacks contracts on-chain, such as 0xB6...6C95, 0xb4…83b7, 0xB5…9D95, and others. Since their creation, a significant number of sandwich attacks have been observed, severely impacting user experience.

The RPC Era

After the launch of secure RPC services (BlockRazor Scutum, as a typical product), transactions sent to secure RPCs can avoid being monitored by sandwich bots, thereby preventing from sandwich attacks. The methods of sandwich attacks during this era did not change much. The privacy protection provided by RPC reduced the overall opportunities for sandwich attacks. Nonetheless, for various reasons, less than 40% of transactions get protection from RPCs, most transactions are still at risk of sandwich attacks.

• Protecting users transactions from sandwich attacks is important, but most trading bots and wallet haven’t recognized it, as doing so does not provide significant economic benefits to the bots or wallets themselves. That’s why trading bots and wallet becoming hotspots for sandwich attacks.
• Some early RPC experienced significant delays in transaction inclusion speed, resulting in a poor user trading experience and leaving users with the stereotype that RPC slow down transactions. In pursuit of speed as the main objective, these users had no choice but to continue using Mempool at the risk of being subjected to sandwich attacks.

The GWA Era

To further address the issue of sandwich attacks on the BSC chain, Binance formed the GoodWill Alliance in collaboration with BlockRazor, 48 Club, and others. Members of the GoodWill Alliance introduced sandwich detection tools in the Builder to exclude detected sandwich attacks, thereby reducing the number of sandwich attacks in the blocks.

After BlockRazor and 48Club introduced sandwich detection in March 20, 2025, the number of detectable sandwich attacks on the BSC chain significantly decreased. However, this also directly led some top sandwich bots to attempt more covert and complex sandwich attacks methods: non-atomic sandwich attacks. The idea behind this type of sandwich attacks is to disguise the attack transactions as regular swap transactions and manipulate the ordering relationship between them and the victim's transaction to execute the attack.

Single Transaction Bundled Sandwich

In atomic sandwiches, the bundle consists of three transactions: frontrun transaction - victim transaction - backrun transaction. In a single transaction bundled sandwich, the bundle consists of either a frontrun transaction - victim transaction (frontrun bundle) or a victim transaction - backrun transaction (backrun bundle). The attacker has two methods of attack: ① Ensure that the frontrun transaction gets a position higher than the victim transaction through the frontrun bundle, and then submit a separate backrun transaction; ② Ensure that the backrun transaction gets a position lower the victim transaction through the backrun bundle, and manipulate the ordering to execute the frontrun transaction using other methods (Through send bundle or set high gas price).

Non-bundled Sandwich

This method is similar to the Gaswar Sandwich of the barbaric era, where the attacker ensures that the frontrun transaction is placed before the victim transaction and the backrun transaction is placed after the victim transaction by using send bundle or set high gas price. The example shown in the figure below illustrates a non-bundled sandwich attack.

Figure 6: Schematic of the transaction ordering in the block for an Non-bundled sandwich attack

Figure 7: Illustration of an Non-bundled sandwich attack in the TOKEN transaction Perspective

Cross-Block Sandwich

In addition to sandwich attacks in one block, we have even observed some cross-block sandwich attacks where the frontrun transaction is in a block with the victim transaction, while the backrun transaction appears in the next block. In the example below both frontrun transaction and victim transaction are included in block 48344362 and backrun transaction is included in block 48344363.

Figure 8: Schematic of the ordering of transactions in a block for the cross-block non-atomic sandwich attack

Figure 9: Schematic of the cross-block sandwich attack in the TOKEN transaction perspective

Why are sandwiches difficult to solve?

The sandwich problem is a chain-native issue closely related to block construction and DEX trading.

Block Construction

Transaction Broadcasting

Mempool transactions are visible across the entire network, allowing sandwich bots to discover their targets.

Transaction Ordering

As discussed in our article "BSC MEV101," to maximize block value within limited block space and provide rewards to the chain's infrastructure suppliers (proposers), transactions are sorted based on value rather than time. This creates ordering opportunities for sandwich attacks.

Transaction bundle

The transaction bundle allows sandwich attacks to be atomic—if a sandwich attack is unsuccessful, the attacker's transactions will not appear in the block, making the cost of the attack very low (when successful, the attacker always profits, and when unsuccessful, the attacker doesn’t even need to pay gas fees for the attack, as bundled transactions are canceled rather than failing). After the establishment of the Goodwill Alliance, the transaction bundle no longer provides convenience for sandwich attackers—it's straightforward to determine whether a bundle is a sandwich attack, and Builders will directly exclude these bundles.

DEX Trading

Price Space Caused by Slippage

DEX trading requires setting slippage to ensure execution of transactions. Slippage represents the acceptable range of volatility and indicates the range of exploitation acceptable to users—by manipulating transaction ordering, attackers can front-run users’ transactions, ensuring prices fall within the maximum range acceptable to users.

Economic issue

If we don’t change the mechanism of blockchain, governance of sandwiches will be an economic issue— how to make sandwich attacks unprofitable. In the RPC era, privacy transactions sent via RPC are invisible to attackers, reducing the overall opportunities for sandwich attacks. GWA has decreased the success rate of sandwich bot attacks and has led to a back-and-forth in sandwich detection, increasing the explicit costs of sandwich attacks. (Due to the existence of failure rates, non-atomic sandwich attacks are a game of mathematical expectation). These governance methods have altered the landscape of the sandwich market (some typical sandwich bots have ceased trading, but we cannot confirm whether they have completely exited the sandwich game), seeking a rebalancing point in the new market space.

Figure 10: Typical Sandwich Bot of the Savage Era (0x00...e534) is down in January 2024

Figure 11: Typical sandwich bot from the RPC era (0x52...1798) is already down on March 18, 2025

How to avoid sandwiches as much as possible?

As we discussed in the previous section, sandwiches are difficult to eradicate, which is why we use the term "avoid" rather than "absolutely avoid." We believe that the current defenses against sandwiches mainly include the following aspects:

Avoiding transactions from being captured by sandwich bots

Using RPC privacy transactions

This is an ecological solution with very low costs, suitable for wallets, trading platforms, etc. Although, RPC may auction transactions with user consent, potentially leading to information leaks that invite sandwich attacks. This defense method relies on the reputation of RPC providers, builders, and validators. For example, on Solana, malicious behavior by validators has caused sandwich-protected transactions sent to Jito to suffer from sandwich attacks: Jito offers users anti-sandwich features, allowing them to obtain protection by adding anti-sandwich tips. However, in cases of validator misconduct, this protection is ineffective—despite the Solana Foundation investing significant effort over the past year, sandwich attacks resulting from validator misconduct still occur frequently.

Figure 12: Solana Sandwich Schematic

Figure 13: Distribution of attacks on Solana sandwich bots GHPC...T29e over a 24-hour period reveals the existence of the bad reputation validators

Send the transaction directly to the Builder

This is currently the most secure method. Compared to privacy RPCs, Builders do not auction transactions, ensuring full privacy for the transactions. Users with high-security requirements can connect to the Builder's Private interface themselves: ☞ BlockRazor Send-privatetransaction. Additionally, Scutum's full privacy mode also supports direct transaction submissions to Builders, allowing users without interface integration capabilities to use Scutum's full privacy mode directly.

Governance from the Block Production Program

BSC has demonstrated that forming a goodwill alliance through builders and validators can significantly combat sandwich bots. Since the establishment of the goodwill alliance, the number of sandwiches on BSC has noticeably decreased. However, as the underlying conditions for sandwich attacks still exist, it remains impossible to absolutely avoid them. A technical tug-of-war between sandwich bots and governance entities has already begun.

Figure 14: Sandwich Attacks Significantly Decreased after the Formation of GoodWill Alliance ( https://dune.com/bnbchain/bnnbchain-mev-sandwich-status）

Potential Governance Direction: DEX Optimization

To further address the issue of sandwich bots, following the governance approach of economic considerations, we believe that the FM-AMM function proposed by CowSwap is a potential governance direction. FM-AMM is an adjustable amplitude automated market maker function that ensures the prices of currency pairs after a set of swap transactions are equal to the execution prices of those swaps, thereby reducing the price space exposed to sandwich bots in DEX trading.

Figure 15: FM-AMM function where the execute price is equal to the price after the trade execution [4].

References

[1] Meme Hacked Again: Liquidity Loophole "Swallows" $174,000 - Is Meme Coin Still Safe? https://www.binance.com/zh-CN/square/post/21785190931170

[2] Sandwich trades status on BNBChain: https: //dune.com/bnbchain/bnnbchain-mev-sandwich-status

[3] Recent data leaks from some Jito verifiers have resulted in user blocks being pinched: https: //www.binance.com/zh-CN/square/post/21318544332170

[4] Arbitrageurs' profits, LVR, and sandwich attacks: batch trading as an AMM design response : https://arxiv.org/pdf/2307.02074