Solana’s transaction ordering proposal stalls after pull request closes without merging

A Solana proposal meant to make in-block transaction ordering auditable has stalled, leaving traders without a new guarantee on how their orders are sequenced. The pull request behind it closed without merging on Sept. 25 (Friday), after reviewers asked for data the proposal’s authors did not supply.

• SIMD-0649 would let validators reject blocks when transactions inside one batch are recorded out of fee-priority order.
• The pull request closed Sept. 25 without merging, leaving the ordering rule undecided for now.
• Block leaders would still choose which transactions to include and how to divide them into batches.

• Sept 25 date the SIMD-0649 pull request closed without merging
• Sept 23 date a reviewer asked for real world batch size data
• 64 minimum data shreds a batch must span under the draft
• 2 FEC forward error correction sets Agave and Firedancer target per batch

A Solana proposal designed to make transaction ordering inside blocks auditable stalled this week after its authors withdrew it from active review, according to CryptoSlate. The SIMD-0649 pull request closed on Sept. 25 without merging, following calls for further discussion and sign-off from client developers. The proposal would not decide which transactions make it into a block. It would only make the order of transactions inside a single completed batch checkable after the fact.

SIMD-0649 closes Sept. 25 without settling the ordering rule

Under the draft, a block producer, known as the leader, would still choose which transactions to include and how to split them into batches. The new element was a consensus check: a replaying validator would compare recorded transaction priorities within each batch and treat an out-of-order sequence as an invalid block. That check would apply per batch, not across an entire slot, so it stops short of one priority queue governing everything a leader produces.

Equal-priority transactions could still appear in either order, and simple vote transactions were exempt from the rule.

The priority score behind the check, laid out in the draft proposal document, divides the reward a leader collects for including a transaction by its requested cost under Solana’s pre-execution cost model. That reward includes the priority fee a user pays plus the unburned share of the base fee, calculated as an integer with a multiplier and a one-unit guard in the denominator so different validator clients compute an identical result. The score is therefore more specific than simply ranking transactions by the fee a user names.

Leaders keep control over batch size and which transactions get in

The draft’s stated non-goals leave leaders free to select transactions, delay one into a later batch, and set batch boundaries however they choose. A transaction with a higher priority score sitting in a later batch would not jump ahead of a lower-scored transaction placed in an earlier one. That makes within-batch ordering a narrower guarantee than slot-wide ordering or any promise of best execution for traders.

To stop leaders from neutering the rule by making batches trivially small, the draft requires every batch except the final one to span at least two forward error correction sets, or at least 64 data shreds, the packet groupings that make up a block. The last batch in a slot is exempt from that size floor because a slot can end before it fills. The proposal also does not address a leader paying priority fees to itself, since the draft confirms those fees return to the leader while the burned portion of the base fee stays a cost, meaning the check offers no protection against self-dealing or MEV.

Sept. 23 review flags missing batch-size evidence

In a review dated Sept. 23 (Wednesday), a reviewer argued a leader could still close a batch early whenever it was advantageous to separate conflicting transactions, and asked for present-day batch-size data broken down by scheduler, client and market conditions, along with a sensitivity test for alternative minimum sizes. The draft states Agave and Firedancer both target batches of roughly two FEC sets, but neither the proposal nor the review includes a measured distribution of how often current leaders already produce smaller batches. Without that data, the practical effect of the proposed minimum on ordinary block production cannot be quantified.

A separate August discussion raised a latency concern tied to Firedancer’s practice of replaying partially received data before a batch completes. The revised draft would let validators compare and execute transactions as they arrive, then invalidate the block later if the comparison fails, though the sources do not measure how much delay the two-FEC-set minimum could add at low throughput.

The BlockWest read. Market makers and algorithmic traders positioning around Solana’s recent 300ms and 250ms latency upgrades should not treat SIMD-0649 as a fairness backstop. Leaders can still delay, split or route around competing orders through batch boundaries and self-directed fee capture. Firms building execution strategies on Solana are effectively pricing in leader discretion that no pending proposal currently removes.

The proposal’s next move depends on whether its authors resubmit with the batch-size and sensitivity data the Sept. 23 review requested, and whether Agave and Firedancer developers commit to supporting a revised version before any new SIMD returns for a vote.

BlockWest is a news publication. Nothing here is investment advice. Read our disclaimer and editorial policy.