Call for proposal: Addressing Malicious MEV Attacks on BNB Chain

Hi everyone,

As many of you are aware, a snaptshot voting proposal to reduce malicious MEV attacks has been put forward. The majority of voters so far are in favor of penalizing the attackers, builders, and validators who take part in the attacks.

While there has been some progress in raising awareness about MEV, the development and implementation of effective technical solutions needs to be accelerated. This thread calls upon members of the community to collaborate and propose innovative ways to mitigate these malicious MEV attacks.

Please share your ideas, technical expertise, and any relevant resources in this thread. Let’s make the BNB Chain a safer and more equitable platform for all.

Looking forward to hearing your thoughts!

3 Likes

As a member of 48Club-puissant-builder and the 48Club validator dev team, as well as a long-time contributor to go-ethereum and BSC code, I’m happy to engage in this discussion.

First, it’s undeniable that sandwich attacks have caused significant harm to regular users on EVM chains, impacting the reputation of the network and potentially leading to user attrition. However, we must also acknowledge that smart contracts on EVM chains are inherently permissionless, and the mempool is a fundamental feature of blockchain. This means that solving this issue at the consensus level is practically impossible.

That said, I see two potential approaches:

1. MEV-Protected RPC

As builders, we are currently offering free MEV-protected RPC access to various wallets and DEXs. Transactions sent through our RPC go directly to builders and validators, bypassing public P2P and RPC disclosure before being included on-chain. This ensures privacy protection and mitigates front-running risks.

Check out some posts on X about 48Club Privacy RPC integration:
with PancakeSwap, With Binance Wallet, OKX Wallet, MathWallet, ListaDao, TokenPocket, Rescue Box SecurityTeam, HashDit SecurityTeam, etc.

Since only two links are allowed in this post, you can find more details on our X account 48Club.

2. Penalizing Builders and Validators

While this approach has been suggested, I believe it is highly impractical. Validator and builder code changes require complex upgrade processes, whereas MEV searchers can easily adapt and modify their front-running strategies. While it’s theoretically possible to identify sandwiching patterns in a block and filter them out during block construction, searchers will inevitably find ways to obfuscate their behavior—potentially even executing cross-block sandwiching strategies—rendering this approach ineffective.

For these reasons, I strongly advocate for approach #1, as it is the simplest and least disruptive solution while preserving the fundamental principles of EVM.

48Club’s Commitment to BNB Chain

48Club has been deeply involved in the BNB Chain ecosystem for years, navigating through multiple bull and bear markets, witnessing both its challenges and growth. With the introduction of the BEP-322 PBS model last year, which introduced the builder role, 48Club immediately responded, enhancing transaction security on BSC and injecting new energy into the validator ecosystem.

It’s worth noting that 2021-2022 was the peak of sandwich attacks on BSC . Since then, with our Privacy RPC integration in collaboration with multiple wallets and DEXs , front-running activities have significantly decreased . We hope to work together on this community proposal and bring back a great BSC mainnet .

Looking forward to hearing more thoughts from the community!

4 Likes

Make all RPCs on bnbchain.org private.

Done.

We are BlockRazor, the team behind the BlockRazor Builder, and we’d like to share our insights on on-chain MEV attacks, particularly front-running and sandwich attacks.

First, contrary to the widespread perception that BSC is plagued by an unusually high number of sandwich attacks, the proportion of such attacks on BSC is actually comparable to Ethereum.

Second, sandwich attacks rely on two core mechanisms: transaction visibility and the ability to manipulate transaction ordering. We strongly agree with Mars’ conclusion that the most effective and low-cost solution to mitigate on-chain MEV attacks is to encourage users to adopt MEV-Protect RPCs. By using the correct MEV-Protect RPC, users can leverage Builder services to bypass the public mempool, making their transactions invisible to attackers and effectively eliminating the risk of sandwich attacks. Currently, BSC offers several MEV-Protect RPCs, including our own ScutumRPC product: https://rpc.blockrazor.io/.

Additionally, Builders and Validators can indeed play a more significant role in preventing MEV attacks. The privacy-enabled mempool mechanism and flexibility in transaction ordering introduced by Proposer-Builder Separation (PBS) are powerful tools for addressing sandwich attacks. In fact, PBS has the potential to completely eliminate sandwich attacks. However, the challenge lies in the design of mainstream PBS systems, such as Ethereum’s PBS and Solana’s Jito. These systems were primarily designed to maximize block value by encouraging Validators to select the most profitable blocks.

From an economic perspective, it’s crucial to reward Validators and Builders who implement technical measures to mitigate sandwich attacks, while also leveraging community oversight to hold malicious Validators and Builders accountable. This approach creates positive incentives for the community to address the prevalence of sandwich attacks and aligns with the principles of decentralization.

Lastly, a quick reminder: not all MEV-Protect RPCs guarantee complete transaction privacy. Individuals and projects using MEV-Protect RPCs should regularly verify that the protection features are functioning correctly. We offer a real-time sandwich attack detection tool to help users confirm the effectiveness of their RPC’s anti-sandwich functionality. If you’re interested, feel free to reach out to us at team@blockrazor.io.

4 Likes

Hi, I am Minimoon, a member of the Cryptic Woods Research team https://crypticwoods.com/

We run the MEV analytics dashboard https://libmev.com/ on Ethereum which is used by the majority of searchers, an Ethereum block builder and are MEV participants.

Block building and MEV are both ultimately a game of economic incentives - if we wish to remove malicious MEV, it is important that players are incentivised to behave in a way which doesn’t hurt the community.

Currently, malicious MEV e.g. sandwich attacks are profitable.

This means that searchers are economically incentivised to propose these bundles, and block builders and validators are economically incentivised to create and accept blocks which contain these bundles.

Who are the players and how do we rewire their incentives?

Users

One solution we’ve heard a lot is to have every user using a private RPC. You could do this 2 ways

  • Enforce that all RPCs must be private. Not realistic for a public blockchain, and penalising RPC providers for non compliance feels excessive given that they aren’t causing any harm (and users are choosing to use these services themselves)
  • Educate every single user. Sounds great in theory but in practice not all users can be reached, there is already much talk about malicious MEV and yet many transactions use the public mempool.

However, this does not guarantee removal of malicious MEV, as a malicious searcher-builder could easily still frontrun and sandwich users.

Searchers

Searching is public and permissionless so it isn’t really possible to govern here

Builders

Currently permissioned (whitelist) and incentivised with rewards for building blocks. Malicious builders are also at an advantage compared to a non malicious builder.

This means that malicious blocks need to be made uneconomical - possible solutions include penalties for building blocks with malicious MEV or ensuring malicious blocks are not included.

Relay?

One possible solution could be to explore the reintroduction of the relay role on BSC

This would introduce a number of potential simplifications and benefits such as:

  • Allowing permissionless block building on BSC - due partially to the lack of a relay on BSC currently, building on BSC is currently whitelist only
  • A relay can segregate blocks which don’t comply with OFAC
  • A relay can drop blocks with malicious MEV

This can all be done in a public manner, with dropped blocks and reasons published to builders who can then work on and improve their blocks while protecting users.

MEV monitoring

For many of these solutions, in order to monitor and track malicious MEV, it will be important to have an accurate and reliable MEV dashboard.

Closing words

We don’t have the perfect solutions here at Cryptic Woods Research but we do have deep block building, MEV and MEV analytics experience. We would love to be involved in any additional discussions or working groups which may arise from this, and would be interested in contributing to eventual solutions.

Technical Proposal: Transaction Relay for Enhanced Block Building

Overview

Current block building systems, particularly in the context of Proposer-Builder Separation (PBS), often suffer from limitations in validator selection and transaction inclusion speed. The current model, where builders are restricted to sending bids only to pre-registered validators, creates a bottleneck. This proposal outlines a system where a proxy layer can broadcast transactions to a broader network, fostering competition and reducing transaction latency.

Problem Statement

  • Increased Transaction Latency: Transactions must wait for specific, pre-selected validators to propose blocks, especially the registered validators are not incumbent validators that propose blocks to the network. This can lead to significant delays, especially if the builder has few validators registered.
  • Consensus block production: The delay can be deteriorated if the number of blocks that each validator can propose consecutively. The current setting is 4, but can be increased in the future.
  • Reduced Competition: Limited validator selection reduces competition among builders and validators, potentially leading to less efficient fee markets and suboptimal block construction.

Proposed Solution: Open Transaction Relay Proxy (OTRP)

The core of this proposal is the creation of an Open Transaction Relay Proxy (OTRP). This role acts as a parallel, permissionless layer alongside the existing validator set. It enables proxy to disseminate transactions more widely, increasing the likelihood of inclusion in a block, regardless of pre-registration.

Workflow

  1. Transaction Submission: A user submits a transaction to a proxy.
  2. OTRP Broadcast: The proxy broadcasts the transaction to all registered builders.
  3. Builders will pick up the transactions, build blocks and send bids to validators.

Advantages

  • Increased Validator Competition: Opens up block building to a wider range of validators(through the whole network of builders), fostering competition and potentially leading to lower fees and better transaction inclusion.
  • Faster Transaction Inclusion: Transactions are broadcast to a larger network, increasing the probability of being included in a block quickly, even if specific pre-registered validators are unavailable or slow.
  • Improved Censorship Resistance: Makes it more difficult for individual validators to censor specific transactions, as there are more avenues for inclusion.
  • Enable the possibility to increase the consecutive block production when block time is reduced to subsecond(see details from BNBChain 2025 roadmap).

User Journey

After implementation, a user sending a transaction to any proxy, regardless of the service provider behind that proxy, will have their transaction broadcast to all registered builders (listed in the GitHub repository you linked: https://github.com/bnb-chain/bsc-mev-info/tree/main/mainnet/builders). This broadcast increases the likelihood of the transaction being included in the next block proposed by validators.

Conclusion

The Open Transaction Relay Network presents a viable path towards a more open, competitive, and efficient block building ecosystem. By allowing builders to broadcast transactions to a wider network, it addresses the limitations of current systems and promotes faster transaction inclusion, and greater validator participation.

Hi
I’m lucas, a member of Renewable Energy Token, in my opinion, the best way to address the issue of MEV attacks on BNB Chain is through a structured approach that integrates 3 fundamental solutions

1- Encrypted Mempool – Preventing front-running and sandwich attacks by ensuring that pending transactions remain private until they are confirmed
2- Fair Ordering Protocol – Enforcing strict transaction sequencing based on the actual submission time rather than gas fees
3- AI-Powered MEV Detection – Identifying and penalizing wallets and validators engaging in MEV strategies through machine learning-based transaction analysis

By implementing these solutions together, BNB Chain can significantly enhance transaction fairness, improve network security, and minimize manipulative activities that distort the market Below, I will outline how each solution works and why it is effective

1- Encrypted Mempool to Prevent Front-Running and Sandwich Attacks

One of the main reasons MEV attacks are so prevalent is the public nature of the mempool, which allows bots and validators to analyze unconfirmed transactions and exploit them for profit The most effective way to mitigate this is to encrypt transaction details while they are in the mempool, only decrypting them once they are included in a block

How This Works:

When a transaction is submitted to the network, instead of being publicly visible in the mempool, it is encrypted using zk-SNARKs or TEEs (Trusted Execution Environments)
The validator can only see an encrypted version of the transaction, meaning they cannot determine its purpose or content
Once the transaction is included in a block, it is decrypted and executed in the exact order it was received

Why This Is Effective:

Eliminates front-running and sandwich attacks since attackers cannot view pending transactions in real-time
Ensures fair trading conditions for users executing large swaps or limit orders
Maintains network efficiency without altering fundamental blockchain operations

2- Fair Ordering Protocol to Prevent Transaction Reordering

Currently, validators can manipulate the order of transactions within a block by prioritizing those with higher gas fees This creates an unfair environment where MEV actors can submit their own transactions ahead of others, profiting from price movements

To prevent this, transactions should be ordered strictly by their timestamp of entry into the mempool, rather than by gas fees This can be implemented using a Commit-Reveal Scheme that works as follows:

How This Works:

Users submit a hashed version of their transaction to the network (commit phase)
The validator sequences transactions based on their arrival time without knowing their content
Once the transaction order is finalized, users reveal the full details of their transactions (reveal phase)

Why This Is Effective:

Eliminates reordering-based MEV (eg, back-running and time bandit attacks)
Prevents validators from selectively prioritizing transactions based on their profit potential
Encourages fairer gas pricing, as users no longer need to overpay to avoid MEV exploits

3- AI-Powered MEV Detection and Dynamic Penalties

Even with encrypted transactions and fair sequencing, sophisticated MEV bots can still exploit patterns in trading activity without direct mempool access To combat this, BNB Chain should deploy an AI-based monitoring system that automatically detects and penalizes addresses engaging in repeated MEV behavior

How This Works:

Machine learning models analyze transaction history to detect patterns associated with MEV activity
When a transaction is flagged as potentially exploitative, the system applies one of the following measures
Dynamic Gas Pricing – Increasing the required gas fee for repeated MEV transactions
Execution Delay – Introducing a slight randomized delay for flagged transactions
Reputation-Based Restrictions – Penalizing wallets or validators that continuously engage in MEV strategies

Why This Is Effective:

Proactively identifies MEV bots rather than just mitigating their effects
Increases the cost of MEV operations, making them less profitable
Discourages validators from engaging in malicious behavior by imposing financial disincentives

By integrating an AI-based detection system, BNB Chain can continuously adapt to new MEV strategies and prevent emerging forms of transaction manipulation