Solana's New Challenge: From Pursuing Speed to Pursuing Quality Transactions

Solana is known for its high-speed transactions and massive transaction volumes, but is that really enough? As we delve deeper into these transactions, a key question arises: Are these transactions actually creating real value?

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

Solana has always dreamed of realizing an order book system on-chain that could replace centralized exchanges. However, the presence of "toxic traders" has become an obstacle to achieving this dream. This is the new challenge that Solana currently faces: trading volume does not equate to liquidity. A truly healthy market requires not more trades, but higher quality trades.

How to eliminate toxic trading and better protect liquidity?

In the current system, due to Solana's consensus mechanism adopting periodic auctions, takers actually enjoy priority, which leads to malicious MEV (Maximal Extractable Value) behavior affecting the fairness of the market.

The consensus mechanism of Solana forms a time slot every 400 milliseconds, within which transactions are executed in order of the Gas fees paid. This mechanism forces market makers to frequently adjust their quotes, while high-frequency arbitrageurs can complete trades by paying higher fees before market makers cancel their orders, causing market makers to often incur losses.

Ideally, an order book decentralized exchange (DEX) should execute trades in the following order: first, all cancellation operations, then new limit orders, and finally, trades. However, Solana's current consensus mechanism cannot achieve this at the microscopic level.

Similarly, in terms of oracle pricing, the best practice is to first update the oracle price and then execute trades that depend on that price. However, within the current 400-millisecond interval, severe market fluctuations may cause trades to still be executed at the old price.

For lending agreements, the optimal order is to supplement the margin first and then proceed with liquidation.

Therefore, Solana needs a mechanism that allows different protocols to prioritize transactions based on demand, which is the application-controlled execution (ACE) concept that Solana has always emphasized.

BAM: Solana's Solution

The Block Assembly Market (BAM) is a solution proposed by Solana to address these issues. BAM builds a sorting layer or preprocessing layer between the application on the Solana chain and the mainnet.

BAM builds a privacy sandbox using Trusted Execution Environments (TEEs), sorting transactions within the sandbox according to predetermined rules or the First-In-First-Out (FIFO) principle. This mechanism aims to better serve protocols such as order books, perpetual contract exchanges, and dark pools.

How BAM Works

The transaction process of BAM is different from the normal transaction process of Solana. In BAM mode, transactions are first sent to the RPC node, then forwarded to the BAM network. Sorting is done in a TEE privacy environment, where nodes may add additional transactions through plugins (such as updating oracle prices), and then generate proofs. Finally, the transaction data packet is submitted to the leader node of the Solana mainnet, where it is packaged into a block with other transactions and broadcasted.

BAM supports three operating modes: Solana default mode, Block-Engine mode (current MEV solutions on certain platforms, centered around a bidding mechanism), and BAM mode (validators strictly follow FIFO ordering).

Core Features of BAM

1. Trusted Execution Environments (TEEs): Utilize TEEs to build a privacy environment and ensure fairness in transaction ordering.

2. Plugin System: Allows applications to build custom trading sorting logic to achieve complex sorting requirements.

The Practical Applications of BAM

1. Lending liquidation protection: prioritize the execution of additional collateral operations, followed by liquidation checks.

2. Atomic Trade Combinations: For decentralized exchanges, first update the oracle price, then execute trades that depend on that price. For contract exchanges, related derivatives can also be settled within the same time window.

3. Price fluctuation protection: Detect abnormal large orders, split them into smaller chunks for batch execution, allowing the market time to react and avoiding a death spiral caused by cascading liquidations or arbitrage.

4. Market Maker Protection: In the event of emergencies, allow for order cancellation, oracle price updates, and re-listing within milliseconds to prevent malicious arbitrage and reduce price discrepancies.

With the deployment of BAM, the trading experience on Solana will be significantly improved, getting closer to the experience of centralized exchanges. BAM brings verifiability, privacy protection, and programmability to Solana's trading processing flow, enabling developers to build more complex financial infrastructure and driving innovation in the Solana ecosystem.