MEV: Implementation Principles within BSC (For Discussion Purpose)

MEV: Implementation Principles within BSC (For Discussion Purpose)


This document proposes and elucidates a set of principles and guidelines for engaging in Maximal Extractable Value (MEV) operations within the BNB Smart Chain (BSC) Network. It intends to ensure that such actions do not compromise the user experience or manipulate users for value extraction. We address specific practices such as transaction prioritization, emphasizing the balance needed between fairness and efficiency between users and the BNB Ecosystem.


MEV denotes an advanced concept within blockchain systems-- especially EVM Chain – representing the total value that validators can derive by strategically manipulating transactions within a block they are producing. As MEV gains more traction, it is essential to set clear guidelines within the BNB Chain ecosystem. This helps to protect the network and its users from undue manipulation while maintaining a strong and reliable infrastructure.

Example: Let’s consider a scenario where a validator intentionally reorders transactions within a block to profit from arbitrage opportunities. Such activity requires some guidelines to prevent the ecosystem being susceptible to manipulation.

Transaction Prioritization:

This involves users providing incentives to BSC validators to handle their transactions preferentially. This disrupts the blockchain’s ideals of transparency and fairness, leading to an impact in transaction processing and creating an environment prone to “manipulation” and “centralization”. MEV implementation should maintain as much as possible of the core blockchain principles of decentralization, transparency and equality.

MEV: Principles and Guidelines

1.1. User-Focused Approach:

A well-designed MEV strategy must always prioritize user experience and integrity, ensuring no negative impacts result from MEV practices. This involves preserving transactional efficiency, maintaining reasonable gas prices, and protecting users from front-running and similar predatory practices.

Example: An MEV strategy that prioritizes large transactions and disregards smaller ones could result in increased gas prices and delayed transactions for regular users. An effective approach ensures transactional efficiency is maintained for all users, regardless of transaction size.

1.2. Transparency:

Every MEV implementation should foster an environment of trust through transparency.permitting users to understand the process and implications fully.

Example: Validators who manipulate block content for personal gain break trust. Hence, transparency is critical to fostering a trustworthy environment.

1.3. Fairness and Equality:

To align with the decentralization principle of blockchain, effective MEV practices should ensure fairness and give equal opportunities to all participants, irrespective of their stake.

Example: A system where certain transactions are consistently prioritized over others, based on the stake of the user, compromises fairness. MEV strategies should avoid such bias, ensuring all participants, regardless of their stake, have equal opportunities.

1.4. BSC Network Adaptability:

Compared to Ethereum, the BSC has a shorter blocking time (3 seconds) and a larger capacity (140MM gas ceiling). Directly applying Ethereum’s MEV solution on the BSC network may pose challenges to its performance and block stability. Therefore, it is essential to fully consider the unique characteristics of the BSC network when proposing new solutions.

Example: An MEV solution that assumes a block time similar to Ethereum’s might struggle with BSC’s shorter block time. This compromises performance and block stability, therefore MEV solutions should be tailored to BSC’s unique features.

1.5 Network Security:

The MEV solutions often have certain security assumptions and require direct access to validator nodes through third-party services. These security assumptions and network security issues need to be fully discussed.

Example: Some MEV solutions might require direct access to validator nodes via third-party services which could create potential security vulnerabilities. Any MEV solution should fully discuss and address such issues, ensuring a secure network topology.

1.6. Decentralization and Diversity:

MEV strategies should promote decentralization to prevent the centralization of power and prevent the risk of single points of failure.

Example: Consider a scenario where one block builder becomes dominant and imposes unfair transaction ordering to maximize their MEV extraction. This would be harmful to the fairness and transparency of the network. To prevent this, it’s essential to encourage a diverse array of MEV providers. One strategy could be implementing a rotational system for block proposers or a randomized system that selects builders for block construction. This ensures that no single entity has excessive influence over block formation and MEV extraction.

1.7. Collaboration and Innovation:

Continuous research and innovation should be encouraged to address MEV-related challenges. For instance, collaboration between different stakeholders can lead to innovative solutions.

Example: Developers from different blockchain projects could work together on open-source projects to create tools that increase the transparency of MEV activities, or researchers from academic institutions could publish studies on the impact of MEV and propose mitigation strategies. Innovation could also come in new algorithms for fairer transaction ordering or sophisticated strategies for protecting validator nodes from potential security threats.

Closing points:

The principles and guidelines presented in this document are designed to address the various challenges and considerations associated with implementing Maximal Extractable Value (MEV) within the BSC network. By prioritizing good practices and user-centric approaches and continuously promoting transparency, security, decentralization, diversity, collaboration, and innovation, we believe that the potential for MEV can be harnessed in a way that aligns with the core values of the BSC network and the broader blockchain community.

However, it is essential to recognize the landscape of blockchain technology, especially MEV, which is rapidly evolving and inherently complex. Though comprehensive, the strategies, issues, and examples cited herein are not exhaustive. This post is open to continual refinement and expansion in response to new developments and insights in the field.

We aim to keep this document relevant and timely, incorporating new findings, feedback, and network parameters or technology changes. We can ensure a stable and adaptive approach to MEV within the BSC network by maintaining our commitment to transparency, security, and decentralization. Together, we can shape an MEV implementation that benefits the network and its users.


I am in favor of the idea, but what bothers me is the issue of bots/people being able to have control over the placement of my tx without my permission, a good % of the use of this in Ethereum is for arbitrage/sandwich, Bots position the target tx and his tx for a particular gain and this is something that bothers me a lot, someone being able to “touch” a transaction that was supposed to be under my control

Example: Let’s consider a scenario where a validator intentionally reorders transactions within a block to profit from arbitrage opportunities. Such activity requires some guidelines to prevent the ecosystem being susceptible to manipulation.

We are in favor at Merkle and can contribute to building the tools required for this proposal (relay, builder), but would like to address the sandwich problem. Front-running it not beneficial for any crypto user, and if a MEV supply chain were to be added to BSC, it needs to come with front-running protection or penalization.


I support the concept, but what concerns me is the matter of automated systems/individuals having the authority to manipulate the execution of my transactions without my consent. A significant portion of Ethereum’s utilization revolves around arbitrage and sandwiching strategies. Bots strategically position their transactions and mine in order to gain an advantage, and this is a matter that greatly unsettles me. It’s disconcerting to think that someone can interfere with a transaction that should solely be under my control.

For instance, let’s envision a situation where a validator purposefully rearranges transactions within a block to exploit arbitrage opportunities. Such conduct necessitates establishing guidelines to safeguard the ecosystem from being vulnerable to manipulation.

1 Like

Re:1.2, in our view, the issue isnt with transparency, but rather with privacy. Trust is not tenable with complete transparency but rather with a blend with privacy.

Transparency is good for accountability. But accountability is a deterance and not a preventative application. A blend of transparency and privacy where the user or system controls the visibility of critical data is needed to prevent situations that can be manipulated.

A lot of these can be acheived using zero knowledge technologies privatizing critical input data in a transaction.


Hi everyone!

My name is Alex and I lead the team at FastLane Labs. I’m posting because a friend of mine in the BNB ecosystem recently asked me to take a look at what your community is doing to handle MEV. For context, FastLane Labs designed the largest MEV protocol on the Polygon blockchain.

We previously hadn’t considered deploying our protocol on BNB because we thought it would be hard to convince BNB Validators to join; our solution is less profitable for them than the solution(s) that many of them are currently using. To be blunt, this is because our solution does not empower Validators to give sandwich bots the protection and privacy that the bots need to “safely” attack users. With Validators unable to protect these attackers, the attacks simply don’t happen, and therefore the bribes / kickbacks from the attackers back to the Validators don’t happen… which is why we originally thought it would be tough to convince BNB Validators to use our system.

However, after reading your new guidelines, I think that many BNB Validators who follow the guidelines may be more open-minded about using a system like FastLane. I was very surprised to discover that these guidelines are virtually identical to the guidelines we had in mind when we built our Polygon MEV solution.

Some quick highlights of how the protocol we designed for Polygon works and how it matches up to your guidelines:

  • FastLane’s MEV protocol is unique from all other MEV protocols; it is smart contract based.
  • Every MEV transaction is a call to the verified FastLane smart contract, making it the most transparent MEV protocol. Every single MEV transaction can be seen and identified on chain (or via the block explorer).
  • Its setup does not allow the FastLane Labs team to censor transactions for Validators. Even if the FastLane team wanted to, it would be impossible for us to block a validator from mining an OFAC transaction because we do not have a monopoly on the routes that transactions can take to reach the validator.
  • Every MEV auction is fully public and fully auditable. The FastLane MEV explorer shows all bundles that arrived at the relay, not just the winning one.
  • Validator nodes do not need to run any custom code or expose themselves to an external Relay. Validators can join the system by peering their node with a FastLane node and then installing a one line patch on their sentry nodes.
  • Bundles can be submitted by searchers via the mempool - FastLane is the only MEV protocol that could turn its relay off and still function :slight_smile:
  • Every transaction in every bundle received by the FastLane relay is broadcast into the mempool. This has three unique benefits:
    • “Sandwich” attacks are strongly disincentivized. As we saw with the $24m beacon chain “exploit” on Ethereum Mainnet a few months ago, sandwich attackers lose a lot of money when their attacks are made public. Since FastLane went live six months ago, not a single successful sandwich attack has been observed occuring via the protocol.
    • MEV is democratized. More Searchers see the mempool transaction, leading to more bids.
    • The FastLane model is the only MEV model that doesn’t allow the custodians of private orderflow to exclude the validator from revenue generated from orderflow-based MEV. Ironically, the private orderflow protocols’ revenue would go to Validators by default if the Validator didn’t provide a private relay for free.

Regarding network adaptability:

  • FastLane was initially designed for a 2s block time, so going to 3s would be very doable. Both Polygon and BNB nodes are forks of geth and the team has already confirmed that all the backend code is portable over to BNB chain.

Regarding how FastLane makes money:

  • This is something I want to be very transparent about because neither FastLane nor any other MEV company is a non-profit. In the future, we plan to build in atomic, cross-chain support, not just for MEV but for traders and DEX aggregators as well. To use this system, collateral will have to be posted. We plan to stake that collateral with FastLane-using validators and to keep a portion of the staking rewards to fund our operations. In other words, our profit will come from the interest earned on collateral posted searchers and aggregators.

Sorry for the long post. I don’t want to come across as a marketer… it’s just that your guidelines were a perfect match. If there’s interest from the BNB community, I can start a new thread to answer any questions you have. The FastLane team would very much like to launch here too, we just don’t know many Validators here and would appreciate some introductions. :wink:

TLDR: As an MEV protocol on an EVM chain that’s built, deployed, and battle-tested an MEV solution for Validators that matches your guidelines, we’d love to contribute and help in whatever way we can and would be happy to share research and data from our experience so far.


1 Like

In my humble opinion, an MEV bot that executes frontrun operations on unsuspecting users or even reorders blocks for personal benefit and financial gain to the validator, are situations of extreme risk to the principles of decentralization and transparency, deeply undermining the core of what the essence of blockchain technology aims to achieve.

Therefore, I believe that measures should be taken to restrict the possibilities of such practices.

1 Like