Skip to content

BSC MEV Overview

The BSC network has introduced the Builder API Specification to establish a fair and unified MEV market. Previously, BSC clients lacked native support for validators to integrate with multiple MEV providers at once. The network became unstable because of the many different versions of the client software being used. The latest BSC client adopts the Proposer-Builder Separation model. Within this unified framework, several aspects of the BSC network have been improved:

  • Stability: Validators only need to use the official client to seamlessly integrate with various Builders.

  • Economy: Builders that can enter without permission promote healthy market competition. Validators can extract more value by integrating with more builders, which benefits delegators as well.

  • Transparency: This specification aims to bring transparency to the BSC MEV market, exposing profit distribution among stakeholders to the public.

What is MEV and PBS

MEV, also known as Maximum (or Miner) Extractable Value, can be described as the measure of total value that may be extracted from transaction ordering. Common examples include arbitraging swaps on decentralized exchanges or identifying opportunities to liquidate DeFi positions. Maximizing MEV requires advanced technical expertise and custom software integrated into regular validators. The returns are likely higher with centralized operators.

Proposer-builder separation(PBS) solves this problem by reconfiguring the economics of MEV. Block builders create blocks and submit them to the block proposer, and the block proposer simply chooses the most profitable one, paying a fee to the block builder. This means even if a small group of specialized block builders dominate MEV extraction, the reward still goes to any validator on the network.

How it Works on BSC


The figure above illustrates the basic workflow of PBS operating on the BSC network.

  • MEV Searchers are independent network participants who detect profitable MEV opportunities and submit their transactions to builders. Transactions from searchers are usually bundled together and included in a block, or none of them will be included.

  • The builder collects transactions from various sources to create an unsealed block and offer it to the block proposer. The builder will specify in the request the amount of fees the proposer needs to pay to the builder if this block is adopted. The unsealed block from the builder is also called a block bid as it may request tips.

  • The proposer chooses the most profitable block from multiple builders, and pays the fee to the builder by appending a payment transaction at the end of the block.

A new component called Sentry has been introduced to enhance network security and account isolation. It assists proposers in communicating with builders and enables payment processing.

What is More

The PBS model on BSC differs in several aspects from its implementation on Ethereum. This is primarily due to:

  1. Different Trust Model. Validators in the BNB Smart Chain are considered more trustworthy, as it requires substantial BNB delegation and must maintain a high reputation. This stands in contrast to Ethereum, where becoming an Ethereum validator is much easier, the barrier to becoming a validator is very low (i.e., 32 ETH).

  2. Different Consensus Algorithms. In Ethereum, a block header is transferred from a builder to a validator for signing, allowing the block to be broadcasted to the network without disclosing the transactions to the validator. In contrast, in BSC, creating a valid block header requires executing transactions and system contract calls (such as transferring reward and depositing to the validator set contract), making it impossible for builders to propose the whole block.

  3. Different Blocking Time. With a shorter block time of 3 seconds in BSC compared to Ethereum’s 12 seconds, designing for time efficiency becomes crucial.

These differences have led to different designs on BSC’s PBS regarding payment, interaction, and APIs. For more design philosophy, please refer to BEP322:Builder API Specification for BNB Smart Chain.