Solana Player's Quick Guide to the BSC Network (Part II) — MEV Path (PBS vs Jito)

After understanding the similarities and differences in the transaction broadcasting mechanisms between BSC and Solana, we now delve into a topic critical for all traders: the MEV (Maximal Extractable Value) Path.

On Solana, you are already well-acquainted with Jito Labs' MEV infrastructure (covering over 90% of staked volume). BSC, on the other hand, officially implemented the Proposer-Builder Separation (PBS) mechanism in May 2024 via the BEP-322 proposal. Currently, 99% of blocks on the BSC chain are MEV blocks, meaning understanding PBS is essential for engaging in trading on BSC.

1. BSC PBS Mechanism Deep Dive

BSC's PBS mechanism, similar to Jito's approach, decouples "block construction" from "block proposal." However, on BSC, this is a competitive market with multiple Builders, rather than the near-monopoly seen with Jito.

1.1 Step 1: Builder Collects Transactions (Searcher's Entry Point)

The Builder's primary responsibility is to construct the "most valuable" block. They collect transactions from three sources:

Searchers and DApps (Private Channels): This is where you submit your Bundles and private transactions.
Public P2P Network: Builders also monitor transactions in the public Mempool (as described in Part I).

For Searchers, you primarily submit to Builders using the following two methods:

eth_sendPrivateTransaction (Private Transaction):
- Purpose: To submit a single transaction, hoping it will not be publicly broadcast (to prevent front-running or other attacks).
- Note: This interface does not provide revert protection. If your transaction fails, it may still be included on-chain and consume Gas.
eth_sendBundle (Bundle):
- Purpose: To submit an atomic package of transactions (e.g., a Backrun arbitrage where the target transactions are tied together).
- BSC Unique Mechanism (Bundle Merge): Some BSC Builders (such as BlockRazor and 48Club) offer a Bundle Merge feature.
  - Default Behavior: The Builder might break up your Bundle and reorder your transaction with other Mempool transactions or Bundles to create a block with higher overall value (which also increases your Bundle's inclusion rate).
  - How to Disable: If the continuity and atomicity of your Bundle are critical, you can disable the merge function by setting the parameter noMerge: true.

1.2 Step 2: Builder Sorting and Packaging (Defining Value)

How does a Builder measure the "value" of your Bundle or transaction? On BSC, value typically consists of two parts:

$Total Value = Gas Fee + Transfer To Builder EOA (Tip)$

Gas Fee: The Gas Fee you pay, i.e., $Gas Fee = Gas Price \times Gas Used$ .
Transfer to Builder (Tip): This is the "tip" you pay directly to the Builder.
- Implementation: This can be a separate transfer transaction within your Bundle, or an internal transfer within your smart contract logic.
Builder Preference: With equal total value, Builders prefer Bundles with a higher Tip component.

Other Notes: Builders dynamically adjust their sorting strategies based on network congestion. Sometimes they choose the highest total value, and other times they prioritize filling the block with transactions that have the highest average Gas Fee.

1.3 Step 3: Block Bidding and Broadcast

Packaging and Bidding: The Builder sorts the transactions according to the above rules, constructs what it deems to be the highest-value block, and then submits a block bid to the current Validator/Proposer.
Selection and Proposal: The Validator chooses the Builder with the highest bid, signs the block, and broadcasts it to the network.

🔔 Developer Alert: BSC's "Deadline"

This is one of the biggest differences between BSC MEV and Solana: Time.

BSC's block time is 450 milliseconds.
Builder packaging, bidding, and Validator signing all take time.
Key Strategy: To maximize the on-chain probability of your transaction in the current block, we recommend submitting your transaction to the Builder within the first 300 milliseconds after the Validator is proposed. Transactions submitted later have a significantly higher chance of entering the competition for the next block.

This is completely different from Jito's mechanism on Solana, which continuously runs parallel auctions and streams Bundles to the Validator.

2. Comparison with the Solana Jito Mechanism

We'll quickly recap Jito's process:

Submission: Searchers submit Bundles to Jito's Block Engine.
Auction: The Block Engine simulates execution, groups by account conflict, and runs a parallel auction.
Selection: Jito selects the Bundle combinations that yield the highest Tip per Compute Unit (CU) within the CU limit.
Streaming: The optimized Bundles are streamed via gRPC to the Validator's BundleStage.
Payout: The Validator executes the Bundle, and the Tip is collected into the Tip Payment Program and distributed at the end of the Epoch.

3. BSC (PBS) vs Solana (Jito) Difference Summary

4. New Insights for Solana Developers

From "Jito Monolith" to a "Multi-Builder Market": On BSC, you cannot rely on just one MEV infrastructure. You need to connect to multiple Builders simultaneously (such as BlockRazor, 48Club, etc.), as you don't know which Builder will win the bid for the next block. This enhances the network's stability and decentralization but also increases your integration and development costs.

Core Difference: "Block Deadline": BSC MEV is a batch competition with a hard deadline. Your strategy must be built around "how to send the most valuable Bundle to all major Builders before they submit their block bid to the Proposer."

You now understand BSC's transaction broadcast mechanism and the MEV bidding mechanism. In the final article, we will introduce the last segment: The Block Broadcast Path, where we will also provide guidance on efficiently obtaining signal sources on BSC. Furthermore, we sincerely welcome all users to join our Discord channel to discuss related topics.