Interpreting the Solana BAM Block Assembly Market: When Speed is No Longer the Sole Pursuit

Solana is already fast enough, and the volume is large enough. So is it really "enough"?

When we examine those transactions, one question persists: Are these transactions really creating value?

The large volume of transactions on Solana does not come from genuine trading demand, but rather from high-frequency arbitrageurs exploiting millisecond-level information asymmetry to profit. These "toxic traders" (Toxic-takers) use technological advantages to increase Gas when market makers (Makers) are about to cancel orders, allowing their trades to be packaged first, completing the arbitrage and causing losses for the market makers. To compensate for these losses, market makers can only widen the bid-ask spread.

In the end, ordinary users pay the price for this. Solana has always had a dream of implementing an order book on-chain, replacing CEX. However, this makes "toxic traders" an obstacle to realizing that dream. This is the new challenge that Solana faces: volume ≠ liquidity. A truly healthy market needs better trades, not more trades.

How can we eliminate toxic trades to better protect liquidity?

In the current system, takers have actual priority due to the periodic auction mechanism of the Solana consensus, which makes malicious MEV affect market fairness.

How to Understand?

In the current consensus of Solana, within each time period Slot, transactions are sorted according to the paid priority Gas fees; the higher the bid, the earlier the transaction is executed. This auction is periodic, with one Slot every 400 milliseconds.

In this process, market makers need to frequently adjust quotes, cancel orders, and re-list orders. When the market price changes, it needs to be updated immediately.

The takers, especially high-frequency arbitrageurs, monitor price discrepancies and execute trades immediately upon identifying opportunities. Therefore, arbitrageurs can pay higher fees to execute trades before orders are canceled, resulting in market makers often being "sniped" and incurring losses.

For order book DEX, the ideal order of execution should be to first execute all cancellations, then execute new orders, and finally execute trades as prices fluctuate. This is something that the Solana consensus cannot achieve at the micro level currently.

The same applies to the oracle pricing layer; ideally, the oracle price should be updated first, and then transactions relying on that price should be executed. However, within the current interval of 400 milliseconds, market conditions may fluctuate dramatically, leading to transactions still being executed at the original price.

For lending agreements, it is best to first replenish the margin before proceeding with liquidation.

Therefore, it is best to have a way to allow different protocols to sort transactions according to demand, which is what Solana has always emphasized: Application-Controlled Execution (ACE).

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

BAM has built a sorting layer, also known as a pre-processing layer, between the application on the Solana chain and the mainnet.

Using Trusted Execution Environments ( to build a privacy sandbox, transactions are sorted within the sandbox according to predetermined sorting rules, or FIFO (First In, First Out).

Better serve CLOBs (Central Limit Order Books), Perpetual Exchanges, and Dark Pools protocols.

) Solana usually compares transaction packaging with BAM mode.

How to understand that BAM has built a sorting layer between Solana applications and the mainnet? Let's start with an intuitive comparison.

Solana normal transaction process,

1. The user confirms the transaction in the wallet,

2. Transactions sent to the RPC node,

3. The RPC sends to the Leader node of the Solana mainnet during the current Slot period.

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

5. Voting by the remaining nodes.

If an application connects to BAM, the transaction process is as follows,

1. The user confirms the transaction in the wallet,

2. The transaction is sent to the RPC node,

3. Transactions are transferred to the BAM network and sorted in TEE privacy. During the process, nodes may add extra transactions through plugins, such as updating oracle prices, and then generate proofs.

4. The transaction data package is submitted to the Solana mainnet Leader node,

5. When the Leader collects transactions, it collects the BAM data packets, then packages them into blocks for broadcasting.

6. Voting by the remaining nodes.

Therefore, BAM does not actually conflict with the current Solana mainnet consensus process, but serves as an "option." BAM does not run directly on the Solana mainnet; it operates in a so-called "off-chain" manner, pre-sorting transactions, packaging them, and then submitting them to the Solana mainnet.

![Interpreting the Solana BAM Block Assembly Market: When Speed Is No Longer the Sole Pursuit]###https://img-cdn.gateio.im/webp-social/moments-80b3584e69b2d2874adfe16a0331ad66.webp(

) BAM trading sorting mode

BAM supports three operating modes,

1. Solana default mode;

2. Block-Engine mode; the current MEV solution of Jito, which is centered around a bidding mechanism.

3. BAM mode, validators strictly follow FIFO (First In, First Out) ordering.

The core of the BAM model includes the following points,

1. Trusted Execution Environments (TEEs): Privacy and Fairness Utilizing Trusted Execution Environments (TEEs) to build a privacy environment and sort transactions. The other side of privacy is called fairness.

2. Plugin System: Complex Sorting Through the plugin system, BAM allows applications to build custom trading sorting logic. This custom sorting does not mean that nodes can sort in any way they want, but rather that it is sorted according to pre-established rules.

The plugin aims to implement complex transaction sorting while maintaining the security guarantees of the TEE environment. It is currently in the early stages of development.

As mentioned earlier,

For the order book DEX, the ideal order should be to first execute all cancellations, then execute new orders, and finally execute trades as prices fluctuate. This is something that the current Solana consensus cannot achieve at the micro level.

The same applies to the oracle pricing layer. Ideally, the oracle prices should be updated first, followed by executing trades that depend on those prices. However, within the current 400-millisecond interval, market fluctuations may cause trades to still execute at the original price.

For lending agreements, it is best to add collateral first and then proceed with liquidation. This actually implements the ACE application control execution function.

So, what exactly has BAM achieved?

For example,

1. Loan liquidation protection

For lending agreements, after detecting liquidation risks, priority should be given to performing additional collateral operations, followed by liquidation checks.

2. Atomic-level transaction combinations

For DEX, first update the oracle price and execute trades that depend on that price. If it is a contract DEX, related derivatives can also be settled. All of the above operations are completed within the same time window.

3. Price Volatility Protection

For DEX, detect abnormal large orders, split large orders into smaller pieces, execute in batches, give the market time to react, and avoid a death spiral caused by cascading liquidations or arbitrage.

4. Market Maker Protection

In the event of an emergency, cancel orders within milliseconds, oracles update prices, and market makers re-post orders. Avoid malicious arbitrage and reduce price differences.

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

Moreover, with the deployment of BAM, the Solana trading experience will be significantly improved. BAM will make the experience of using Solana's mainnet applications closer to that of a CEX.

In summary,

BAM brings verifiability, privacy protection, and programmability to the transaction processing flow of Solana, enabling developers to build Central Limit Order Books (CLOBs), Perpetual Exchanges, Dark Pools, and other financial infrastructures that require order control, deterministic execution, and privacy protection, thus driving the innovative development of the Solana ecosystem.

Above.