Solana BAM Block Assembly Market Analysis: When Speed Is No Longer the Only Quest

Solana is fast enough, and its trading volume is high enough. But is that really enough? When we examine those transactions, a persistent question remains: Are they truly creating value? A significant portion of Solana's trading stems not from genuine demand, but from high-frequency arbitrageurs exploiting millisecond information gaps to profit. These "toxic traders" exploit their technological advantages to increase gas prices just as market makers (makers) are about to cancel orders, allowing their own trades to be included first, thereby achieving arbitrage and causing losses for market makers. To offset these losses, market makers are forced to widen the bid-ask spread. Ultimately, ordinary users foot the bill. Solana has always dreamed of implementing an on-chain order book and replacing CEXs. However, this has become a barrier to achieving this dream. This is Solana's new challenge: trading volume ≠ liquidity. A truly healthy market requires not more trades, but better trades.

How can we eliminate toxic transactions and better protect liquidity?

In the current system, takers enjoy de facto priority due to Solana's consensus' periodic auction mechanism, allowing malicious MEVs to compromise market fairness.

How to Understand?

In Solana's current consensus, within each time slot, transactions are ranked by the priority gas fee paid. The transaction of the highest bidder is executed first. This auction is periodic, with one slot every 400 milliseconds.

During this process, market makers need to frequently adjust their quotes, cancel orders, and re-enter them. Market price fluctuations require immediate updates.

Takers, especially high-frequency arbitrageurs, monitor price discrepancies and execute trades immediately when they see an opportunity. Therefore, arbitrageurs can pay higher fees to execute trades before their orders are canceled. This results in market makers being frequently targeted and incurring losses.

For order book DEXs, the ideal ordering should be to execute all canceled orders first, followed by new pending orders, and finally trades as prices fluctuate. This is currently not possible with Solana consensus at the micro level.

The same is true at the oracle price level. Ideally, the oracle price should be updated first, followed by trades dependent on that price. However, within the current 400-millisecond interval, market fluctuations can cause trades to be executed at the original price.

For lending protocols, it's best to replenish margin first, followed by liquidation.

Therefore, it would be ideal to have a way for different protocols to prioritize trades based on their needs—what Solana has been emphasizing: ACE (Application-Controlled Execution).

BAM (Block Assembly Marketplace) is Solana's answer.

BAM builds a sorting layer, or pre-processing layer, between Solana on-chain applications and the mainnet.

Leveraging Trusted Execution Environments (TEEs), it builds a privacy sandbox where transactions are sorted according to predetermined sorting rules, or FIFO (first-in-first-out).

This improves the performance of order books (CLOBs), perpetual swaps, and dark pools.

Comparison of Solana's typical transaction bundling and BAM's model

How do we understand BAM's creation of a sorting layer between Solana applications and the mainnet? Let's start with a visual comparison.

The normal Solana transaction process:

1) The user confirms the transaction in their wallet.

2) The transaction is sent to an RPC node.

3) An RPC is sent to the Leader node on the Solana mainnet during the current slot.

4) The Leader collects transactions from the transaction pool, sorts them, packages them into blocks, and broadcasts them.

5) Other nodes vote.

If an application integrates with BAM, the transaction process is as follows:

1) The user confirms the transaction in their wallet.

2) The transaction is sent to an RPC node.

3) The transaction is transferred to the BAM network and sorted privately within the TEE. During this process, nodes may add additional transactions via plugins, such as updating oracle prices, and then generate proofs.

4) The transaction data packet is submitted to the Solana mainnet Leader node.

5) When the Leader collects transactions, it gathers BAM data packets, packages them into blocks, and broadcasts them.

6) The remaining nodes vote.

Thus, BAM does not actually conflict with the current Solana mainnet consensus process; rather, it exists as an "optional" feature. BAM does not run directly on the Solana mainnet, but rather operates "off-chain," pre-ordering transactions, packaging them, and then submitting them to the Solana mainnet.

BAM Transaction Ordering Mode

BAM supports three operating modes:

1) Solana Default Mode;

2) Block-Engine Mode; Jito's current MEV solution is centered around a bidding mechanism.

3) In the BAM model, validators strictly follow FIFO ordering.

The core of the BAM model is as follows:

1) Trusted Execution Environments (TEEs): Privacy and Fairness. Using Trusted Execution Environments (TEEs), we build a private environment to sort transactions. The flip side of privacy is fairness.

2) Plugin System: Complex Sorting. Through the plugin system, BAM allows applications to build custom transaction sorting logic. This custom sorting doesn't mean that nodes can sort transactions however they want, but rather that transactions are sorted according to pre-defined rules.

Plugins are designed to implement complex transaction sorting while maintaining the security of the TEE environment. Currently in early development.

As mentioned above,

For order book DEXs, the ideal ordering should be to execute all canceled orders first, then new pending orders, and finally trades as prices fluctuate. This is currently not possible with Solana consensus at the micro level.

The same is true at the oracle price level. Ideally, the oracle price should be updated first, followed by trades that depend on it. However, within the current 400 millisecond interval, market fluctuations may cause trades to be executed at the original price.

For lending protocols, it is best to replenish margin first, followed by liquidation. This effectively implements the ACE application-controlled execution feature.

So, what exactly does BAM achieve?

For example,

1) Lending and Liquidation Protection

For lending protocols, upon detecting liquidation risk, collateral replenishment is prioritized before liquidation checks.

2) Atomic Trade Combination

For DEXs, the oracle price is updated first, and then trades dependent on that price are executed. For contract-based DEXs, related derivatives can also be settled. All of these operations are completed within the same time window.

3) Price Fluctuation Protection

For DEXs, we detect abnormally large orders, split them into smaller pieces, and execute them in batches, giving the market time to react and preventing chain liquidations or arbitrage-induced death spirals.

4) Market Maker Protection

In the event of an emergency, orders are canceled within milliseconds, the oracle updates the price, and the market maker re-enters the order. This prevents malicious arbitrage and reduces the price spread.

BAM was originally scheduled to launch at the end of July.

Furthermore, with the deployment of BAM, the Solana trading experience will be significantly improved. BAM will bring the Solana mainnet application experience closer to that of a CEX.

In summary,

BAM brings verifiability, privacy, and programmability to Solana's transaction processing, enabling developers to build central limit order books (CLOBs), perpetual swaps, dark pools, and other financial infrastructure that requires ordering control, deterministic execution, and privacy, thereby driving innovation in the Solana ecosystem.

The above.