Solana's New Challenge: Pursuing Higher Quality Transactions

Solana is known for its high speed and large transaction volume, but does this mean it has reached perfection? When we closely examine these transactions, we can't help but ask: are they all creating real value?

In fact, a large number of transactions on Solana do not stem from real demand, but rather from high-frequency arbitrage traders profiting from millisecond information asymmetries. These "toxic traders" leverage their technical advantages to increase Gas fees just as market makers are about to cancel their orders, ensuring their transactions are prioritized for packaging, thereby completing arbitrage and causing losses for the market makers. To compensate for these losses, market makers are forced to widen the bid-ask spread, ultimately passing the costs onto ordinary users.

Solana has always had the vision of implementing an order book on-chain to replace centralized exchanges. However, the existence of "toxic traders" has become an obstacle to achieving this goal. This is the new challenge facing Solana: trading volume does not equate to liquidity. A truly healthy market requires not more transactions, but higher quality transactions.

How to eliminate toxic trading and better protect liquidity?

In the current system, due to Solana's consensus periodic auction mechanism, takers actually enjoy priority, which leads to malicious MEV affecting market fairness.

Under the existing consensus mechanism of Solana, transactions within each time period (Slot) are prioritized based on the paid Gas fees, with the highest bidding transactions being executed first. This auction occurs every 400 milliseconds.

In this process, market makers need to frequently adjust quotes, cancel orders, and re-list orders to adapt to changes in market prices. On the other hand, takers, especially high-frequency arbitrageurs, continuously monitor price differences and execute trades immediately upon discovering opportunities. As a result, arbitrageurs can secure trades by paying higher fees to jump ahead of order cancellations, leading to frequent losses for market makers.

For an order book decentralized exchange, the ideal order should be: execute all cancellations first as prices fluctuate, then execute new orders, and finally execute trades. However, Solana's current consensus mechanism cannot achieve this at the micro level.

Similar issues exist with oracle pricing. Ideally, the oracle prices should be updated first before executing trades that depend on those prices. However, within the current 400-millisecond interval, if there are significant market fluctuations, it may result in trades being executed at the original prices.

For lending agreements, the best practice is to first supplement the margin before proceeding with liquidation.

Therefore, the ideal solution is to allow different protocols to prioritize transactions based on demand, which is what Solana has always emphasized with Application-Controlled Execution (, ACE ).

Block Assembly Marketplace, BAM( is exactly the solution proposed by Solana to this issue.

BAM has built a sorting layer, also known as a preprocessing layer, between applications on the Solana chain and the mainnet. It utilizes Trusted Execution Environments )TEEs( to construct a privacy sandbox, where transactions are sorted according to predefined sorting rules or the first-in, first-out )FIFO( principle.

This mechanism can better serve protocols such as order books, perpetual contract exchanges, and dark pools.

![Understanding 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 Sort Mode

BAM supports three operating modes:

1. Solana default mode
2. Block-Engine mode: Currently the core of a certain MEV solution, mainly based on a bidding mechanism.
3. BAM Mode: Validators strictly sort according to FIFO principle.

The core of the BAM model includes the following points:

1. Trusted Execution Environments ) TEEs (: Using TEEs to build a privacy environment for transaction sorting, ensuring fairness.
2. Plugin System: Through the plugin system, BAM allows applications to build custom transaction sorting logic, but this sorting is based on predetermined rules rather than arbitrary decisions by nodes.

The plugin system plans to implement complex transaction ordering while maintaining the security guarantees of the TEE environment. Currently, the system is still in the early development stage.

Specific Applications of BAM

1. Lending liquidation protection: For lending agreements, upon detecting liquidation risk, prioritize executing supplementary collateral operations before conducting liquidation checks.

2. Atomic-level transaction combination: For decentralized exchanges, update the oracle price first, and then execute trades that depend on that price. For contract exchanges, relevant derivatives can also be settled within the same time window.

3. Price Fluctuation Protection: For decentralized exchanges, detect abnormal large orders, split them into smaller chunks for execution in batches, giving the market enough reaction time to avoid severe consequences caused by cascading liquidations or arbitrage.

4. Market Maker Protection: In the event of an emergency, the ability to complete order cancellations, oracle price updates, and market maker re-listings within milliseconds to prevent malicious arbitrage and reduce the price spread.

With the deployment of BAM, the trading experience on Solana will be significantly improved, making the experience of its mainnet applications closer to that of centralized exchanges.

Overall, BAM brings verifiability, privacy protection, and programmability to the transaction processing workflow of Solana. It enables developers to build centralized limit order books, perpetual contract exchanges, dark pools, and other financial infrastructures that require order control, deterministic execution, and privacy protection, thus promoting innovative development within the Solana ecosystem.