Call for proposal: Addressing Malicious MEV Attacks on BNB Chain

BNB Smart Chain
1

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!

2 Likes
2

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
3

Make all RPCs on bnbchain.org private.

Done.

5

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
6

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.