Fast, Big… But “Good”?

Solana is already fast and already processes enormous volumes. Yet is that truly “enough”?

When we examine those transactions, one question keeps surfacing: are they actually creating value?

A large share of Solana’s throughput is not organic demand but high-frequency arbitrageurs exploiting millisecond information gaps. These “toxic takers” leverage technical latency advantages to front-run market makers. Just before a maker cancels an order, the toxic taker hikes the gas, slips in front, pockets the spread, and leaves the maker with losses. Makers respond by widening their bid-ask spreads. In the end, the average user foots the bill.

Solana has long dreamed of an on-chain central-limit order book (CLOB) that could replace centralized exchanges. Toxic flow is now the main obstacle. The new challenge is stark: volume ≠ liquidity. A healthy market needs better trades, not merely more trades.

The Root of the Problem: Periodic Gas Auctions

Under Solana’s current consensus, each 400 ms slot ranks transactions by priority fee. Whoever pays the most jumps the queue. Makers must constantly cancel and re-quote as prices move; takers—especially latency arbitrageurs—simply monitor for mismatches, outbid, and snipe. Makers are “sniped” repeatedly, bleed out, and widen spreads to survive.

An ideal CLOB DEX would reorder micro-events as follows:

1. Process all cancellations.

2. Process new limit orders.

3. Only then execute matches.

Solana’s base layer cannot enforce this sequence in a single slot. The same issue plagues oracles (price updates should precede price-dependent trades) and lending protocols (margin top-ups should precede liquidations).

What is needed is Application-Controlled Execution (ACE)—the ability for each protocol to define its own canonical ordering. Solana’s answer is BAM: the Block-Assembly Marketplace.

BAM in One Sentence

BAM inserts a preprocessing layer—effectively an ordering layer—between Solana applications and the mainnet. Using Trusted Execution Environments (TEEs) as private sandboxes, it re-sequences transactions according to rules chosen by the application—most simply, FIFO (first-in, first-out).

This serves CLOBs, perpetual exchanges, dark pools, and any protocol that needs deterministic, fair sequencing without leaking strategy.

Side-by-Side Flow

Regular Solana Flow

1. User signs in wallet.

2. RPC node receives tx.

3. RPC forwards to the current slot’s Leader.

4. Leader sorts mempool, builds block, broadcasts.

5. Validators vote.

With BAM

1. User signs.

2. RPC receives tx.

3. Tx is routed to the BAM network; inside a TEE it is reordered (FIFO or custom). Plug-ins may inject extra instructions—e.g., oracle updates—then generate a proof.

4. The sealed bundle is delivered to the Leader.

5. Leader includes the bundle, builds block, broadcasts.

6. Validators vote.

BAM is optional, off-chain, non-consensus-breaking. It pre-sorts, bundles, and hands a ready-made package to the existing Solana validator set.

Three Operational Modes

1. Vanilla Solana – default behavior.

2. Block-Engine mode – Jito’s MEV auction.

3. BAM mode – validators enforce strict FIFO ordering.

BAM Mode: The Nuts and Bolts

• TEEs for Privacy & Fairness
  Intel SGX-style enclaves keep transaction data opaque until sequencing is complete, eliminating front-running.

• Plug-in System for Custom Logic
  Developers can embed domain-specific rules (cancel-before-place-before-match, oracle-update-before-trade, margin-top-up-before-liquidation) while preserving TEE security guarantees. The plug-in framework is still early-stage.

Concrete Wins

1. Lending Liquidation Protection
   Detect under-collateralization → inject margin top-up → only then check for liquidation.

2. Atomic Transaction Composability
   Update oracle price → execute spot trade → settle perp PnL in one coherent atomic batch.

3. Volatility Shielding
   Spot an outsized market order → split it into smaller tranches over micro-slots to avoid cascade liquidations.

4. Maker Protection
   Sudden news hits → millisecond-level cancellations, oracle refresh, fresh quotes—no toxic sniping, tighter spreads.

Timeline & Impact

BAM was slated for a late-July launch. Once live, Solana UX will edge closer to CEX-grade precision without sacrificing decentralization.

In short, BAM injects verifiability, privacy, and programmability into Solana’s settlement pipeline. Developers can now build CLOBs, perpetual DEXs, dark pools, and any infrastructure that demands controlled sequencing, deterministic execution, and strategic privacy—unlocking the next wave of innovation on Solana.

Fast, Big… But “Good”?

Solana is already fast and already processes enormous volumes. Yet is that truly “enough”?

When we examine those transactions, one question keeps surfacing: are they actually creating value?

A large share of Solana’s throughput is not organic demand but high-frequency arbitrageurs exploiting millisecond information gaps. These “toxic takers” leverage technical latency advantages to front-run market makers. Just before a maker cancels an order, the toxic taker hikes the gas, slips in front, pockets the spread, and leaves the maker with losses. Makers respond by widening their bid-ask spreads. In the end, the average user foots the bill.

Solana has long dreamed of an on-chain central-limit order book (CLOB) that could replace centralized exchanges. Toxic flow is now the main obstacle. The new challenge is stark: volume ≠ liquidity. A healthy market needs better trades, not merely more trades.

The Root of the Problem: Periodic Gas Auctions

Under Solana’s current consensus, each 400 ms slot ranks transactions by priority fee. Whoever pays the most jumps the queue. Makers must constantly cancel and re-quote as prices move; takers—especially latency arbitrageurs—simply monitor for mismatches, outbid, and snipe. Makers are “sniped” repeatedly, bleed out, and widen spreads to survive.

An ideal CLOB DEX would reorder micro-events as follows:

1. Process all cancellations.

2. Process new limit orders.

3. Only then execute matches.

Solana’s base layer cannot enforce this sequence in a single slot. The same issue plagues oracles (price updates should precede price-dependent trades) and lending protocols (margin top-ups should precede liquidations).

What is needed is Application-Controlled Execution (ACE)—the ability for each protocol to define its own canonical ordering. Solana’s answer is BAM: the Block-Assembly Marketplace.

BAM in One Sentence

BAM inserts a preprocessing layer—effectively an ordering layer—between Solana applications and the mainnet. Using Trusted Execution Environments (TEEs) as private sandboxes, it re-sequences transactions according to rules chosen by the application—most simply, FIFO (first-in, first-out).

This serves CLOBs, perpetual exchanges, dark pools, and any protocol that needs deterministic, fair sequencing without leaking strategy.

Side-by-Side Flow

Regular Solana Flow

1. User signs in wallet.

2. RPC node receives tx.

3. RPC forwards to the current slot’s Leader.

4. Leader sorts mempool, builds block, broadcasts.

5. Validators vote.

With BAM

1. User signs.

2. RPC receives tx.

3. Tx is routed to the BAM network; inside a TEE it is reordered (FIFO or custom). Plug-ins may inject extra instructions—e.g., oracle updates—then generate a proof.

4. The sealed bundle is delivered to the Leader.

5. Leader includes the bundle, builds block, broadcasts.

6. Validators vote.

BAM is optional, off-chain, non-consensus-breaking. It pre-sorts, bundles, and hands a ready-made package to the existing Solana validator set.

Three Operational Modes

1. Vanilla Solana – default behavior.

2. Block-Engine mode – Jito’s MEV auction.

3. BAM mode – validators enforce strict FIFO ordering.

BAM Mode: The Nuts and Bolts

• TEEs for Privacy & Fairness
  Intel SGX-style enclaves keep transaction data opaque until sequencing is complete, eliminating front-running.

• Plug-in System for Custom Logic
  Developers can embed domain-specific rules (cancel-before-place-before-match, oracle-update-before-trade, margin-top-up-before-liquidation) while preserving TEE security guarantees. The plug-in framework is still early-stage.

Concrete Wins

1. Lending Liquidation Protection
   Detect under-collateralization → inject margin top-up → only then check for liquidation.

2. Atomic Transaction Composability
   Update oracle price → execute spot trade → settle perp PnL in one coherent atomic batch.

3. Volatility Shielding
   Spot an outsized market order → split it into smaller tranches over micro-slots to avoid cascade liquidations.

4. Maker Protection
   Sudden news hits → millisecond-level cancellations, oracle refresh, fresh quotes—no toxic sniping, tighter spreads.

Timeline & Impact

BAM was slated for a late-July launch. Once live, Solana UX will edge closer to CEX-grade precision without sacrificing decentralization.

In short, BAM injects verifiability, privacy, and programmability into Solana’s settlement pipeline. Developers can now build CLOBs, perpetual DEXs, dark pools, and any infrastructure that demands controlled sequencing, deterministic execution, and strategic privacy—unlocking the next wave of innovation on Solana.