Balancing Transaction Speed and Value Creation on Solana

Solana is known for its fast transaction speeds and high transaction volumes, but does this mean it has achieved perfection? As we closely examine these transactions, a key question arises: are these transactions all creating actual value?

In fact, a large number of transactions on Solana do not stem from real trading demand. A significant portion comes from high-frequency arbitrageurs who exploit millisecond information asymmetries to make profits. These so-called "toxic traders" use their technological advantages to prioritize their transactions by increasing Gas fees when market makers are about to withdraw their orders, thus completing arbitrage and causing losses for the market makers. To compensate for these losses, market makers have to widen the bid-ask spread, ultimately passing these additional costs onto ordinary users.

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

How to filter out toxic trades to better protect liquidity?

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

Specifically, in Solana's consensus mechanism, transactions within each time period (Slot) are sorted according to the paid priority Gas fees, with the highest bidding transactions executed first. This auction mechanism occurs every 400 milliseconds. During this process, market makers need to frequently adjust their quotes, including canceling and re-listing orders, to adapt to changes in market prices.

Arbitrageurs, especially high-frequency traders, constantly monitor price discrepancies and execute trades immediately upon discovering opportunities. They can ensure that trades are completed before market makers withdraw their orders by paying higher fees, which often leads to market makers incurring losses.

For order book decentralized exchanges (DEX), the ideal trading order should be: as prices fluctuate, all cancellation operations should be executed first, followed by new orders, and finally the transactions. However, Solana's current consensus mechanism cannot achieve this on a micro level.

The same problem exists at the oracle pricing level. Ideally, the oracle prices should be updated first, and then transactions that depend on those prices should be executed. However, in the current 400 milliseconds interval, the market may experience significant volatility, causing transactions to still be executed at the original prices.

For lending agreements, the optimal sequence of operations should be to first supplement the margin and then proceed to liquidation.

Therefore, Solana needs a mechanism that allows different protocols to prioritize transactions according to their respective needs. This is the concept of Application-Controlled Execution (ACE) that Solana has always emphasized.

To address these issues, Solana proposed the BAM (Block Assembly Market) solution.

BAM: Solana's New Answer

BAM has built a sorting layer, also known as a preprocessing layer, between the application layer and the mainnet on Solana. It utilizes Trusted Execution Environments (TEEs) to create a privacy sandbox, where transactions are sorted based on predefined rules or the First In First Out (FIFO) principle.

This innovation aims to better serve protocols such as order books, perpetual contract exchanges, and dark pools.

Comparison of Traditional Trading Processing and BAM Model in Solana

To better understand how BAM builds a sorting layer between Solana applications and the mainnet, we can compare the traditional Solana transaction process with the process after adopting BAM:

Traditional Solana transaction process:

1. The user confirms the transaction in the wallet
2. Transaction sent to RPC node
3. RPC sends the transaction to the current period's Solana mainnet Leader node.
4. The Leader collects transactions from the transaction pool, sorts them, packages them into blocks, and broadcasts.
5. Other nodes vote

The trading process after adopting BAM:

1. The user confirms the transaction in the wallet.
2. Transaction sent to RPC node
3. Transactions are forwarded to the BAM network and sorted in the TEE environment. During this period, 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. The leader includes BAM packets when collecting transactions, packages them into blocks, and broadcasts.
6. Other nodes vote

It is worth noting that BAM does not conflict with the consensus process of the Solana mainnet, but rather serves as an optional feature. BAM does not run directly on the Solana mainnet, but instead completes transaction sorting "off-chain" in advance, packaging the transactions before submitting them to the Solana mainnet.

BAM's Trading Order 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 sort according to the First In, First Out (FIFO) principle.

The core features of the BAM model include:

1. Trusted Execution Environments (TEEs): Utilizing TEEs to build a privacy environment for transaction ordering, ensuring fairness.

2. Plugin System: Through the plugin system, BAM allows applications to build custom transaction sorting logic. This custom sorting is based on predefined rules rather than arbitrary sorting by nodes. The plugin system aims to implement complex transaction sorting while maintaining the security guarantees of the TEE environment. Currently, this system is still in the early development stage.

Practical Applications of BAM

The actual applications of BAM include:

1. Loan Liquidation Protection: For lending agreements, upon detecting liquidation risk, priority is given to performing additional collateral operations before conducting liquidation checks.

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

3. Price fluctuation protection: For DEX, detect abnormally large orders, split them into smaller transactions to be executed in batches, giving the market enough reaction time to avoid death spirals caused by cascading liquidations or arbitrage.

4. Market Maker Protection: In the event of a sudden incident, operations such as order cancellation, oracle price updates, and market maker re-listing can be completed within milliseconds to avoid malicious arbitrage and reduce the price spread.

With the deployment of BAM, the trading experience on Solana is expected to improve significantly, 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 flow of Solana. This enables developers to build central limit order books, perpetual contract exchanges, dark pools, and other financial infrastructures that require ordering control, deterministic execution, and privacy protection, thus driving the innovative development of the Solana ecosystem.