Solana's High-Speed Transactions: Success or Risks?

Solana is known for its fast transaction speeds and high transaction volumes, but does that mean it has reached perfection? Upon closer examination of 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 arbitrageurs exploiting millisecond information gaps to make profits. These so-called "toxic traders" leverage technical advantages to increase Gas fees just as market makers are about to withdraw their orders, ensuring their trades are prioritized for packaging, thus completing arbitrage and causing market makers to incur losses. To compensate for these losses, market makers are forced to widen the bid-ask spread, ultimately passing the extra costs onto ordinary users.

Solana has always harbored the dream of realizing an order book on-chain to replace centralized exchanges. However, the existence of "toxic traders" has become a major 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 filter out toxic trades to better protect liquidity?

In the current system, due to Solana's periodic auction mechanism for consensus, takers actually enjoy priority, which allows for malicious MEV (Maximum Extractable Value) to seriously affect the fairness of the market.

Specifically, in Solana's current consensus, transactions within each time slot are prioritized based on the paid Gas fees, with higher bidding transactions executed first. This auction occurs every 400 milliseconds. During this process, market makers need to frequently adjust their quotes, including canceling and re-listing orders, to adapt to market price changes. On the other hand, takers, especially high-frequency arbitrageurs, continuously monitor price differences and immediately execute when they spot an opportunity. As a result, arbitrageurs can pay higher fees to execute before a cancellation occurs, causing market makers to frequently incur losses.

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

Similarly, in terms of oracle pricing, the ideal scenario is to first update the oracle price and then execute trades that depend on that price. However, within the current 400 milliseconds interval, the market may experience severe fluctuations that could lead to trades being executed at the original price.

For lending protocols, the best practice is to supplement the margin before liquidation.

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

BAM: Solana's Innovative Solution

The Block Assembly Marketplace (BAM) is an innovative solution proposed by Solana to address these issues. BAM constructs a sorting layer, also known as a preprocessing layer, between the applications on the Solana chain and the mainnet.

BAM uses Trusted Execution Environments (TEEs) to build a privacy sandbox, where transactions are sorted according to predetermined sorting 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.

The Working Mechanism of BAM

The trading process of BAM is as follows:

1. The user confirms the transaction in the wallet.
2. Transaction sent to RPC node
3. Transactions are transferred to the BAM network and sorted in a TEE privacy environment.
4. Generate proof and submit the transaction data package to the Solana mainnet Leader node
5. The Leader node collects transactions that include BAM packets and packages them into blocks for broadcasting.
6. Other nodes vote

It is worth noting that BAM's consensus process does not conflict with the Solana mainnet, but is instead an optional feature. BAM does not run directly on the Solana mainnet, but instead completes transaction sorting "off-chain" beforehand, then packages the transactions before submitting them to the Solana mainnet.

Core Features of BAM

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

2. Plugin System: Through the plugin system, BAM allows applications to build custom trading sorting logic, achieving complex sorting while maintaining the security of the TEE environment.

3. Application Control Execution (ACE): Realizes the function of sorting transactions according to the needs of different protocols.

Practical Applications of BAM

1. Lending liquidation protection: Prioritize the execution of supplementary collateral operations before conducting liquidation checks.

2. Atomic transaction bundle: first update the oracle price, then execute the trades that depend on that price, and for contract DEX, related derivatives can also be settled simultaneously.

3. Price fluctuation protection: Detect abnormal large orders, split them into smaller chunks for batch execution, giving the market time to react, avoiding death spirals caused by successive liquidations or arbitrage.

4. Market Maker Protection: In the event of an emergency, allow order cancellation within milliseconds, update oracle prices, and re-list orders to prevent malicious arbitrage and reduce price spreads.

Conclusion

BAM brings verifiability, privacy protection, and programmability to the transaction processing flow of Solana, enabling developers to build more complex and secure financial infrastructures. With the deployment of BAM, the user experience of applications on the Solana mainnet will be closer to that of centralized exchanges, driving the innovative development of the Solana ecosystem.