Solana’s plan for fairer trades stalls as block producers still choose which orders get in

A proposed Solana rule would let validators reject a block when transactions inside one entry batch are recorded out of fee-priority order. It would not decide which transactions make the block. The SIMD-0649 pull request closed on Sept. 25 without merging, leaving that narrower trade-off for further discussion rather than putting a new ordering rule into effect.

The distinction matters to traders trying to predict where an order will land. Under the draft, a block producer, known as the leader, would still choose which transactions to include and how to divide them into batches. The proposed consensus check would make the order of transactions within each completed batch inspectable and enforceable. It would not establish one priority queue for an entire slot.

Solana's ledger groups entries into batches. In the draft's design, non-exempt transactions in each batch would have to appear in non-increasing priority order. A validator replaying the block would compare their recorded priorities and treat a violation as an invalid block. It would not reshuffle transactions into the right sequence after receiving them. Equal-priority transactions could appear in either order, and simple vote transactions would be exempt.

The priority score is based on the reward a leader receives for including a transaction divided by its requested cost under the pre-execution cost model. The draft specifies an integer calculation, with a multiplier and a one-unit guard in the denominator, so clients would have to compute the same result. Under the fee rules described in the proposal, the reward includes the priority fee and the unburned portion of the base fee. The score is therefore more specific than a simple ranking by the fee a user names.

That change would give an observer a testable answer to one question: among non-exempt transactions that a leader placed in the same batch, was the recorded order consistent with the proposed score? The author argues that a common check would make ordering easier to inspect across different validator clients and schedulers. The proposal does not establish whether a transaction should have been included in the first place.

The draft's non-goals leave leaders free to select transactions, defer one to a later batch and choose batch boundaries. Those choices can determine whether two competing transactions ever face the same ordering test. A high-priority transaction in a later batch would not be moved ahead of a lower-priority one in an earlier batch simply because its score is higher. Within-batch ordering is thus a narrower property than slot-wide ordering or a guarantee of best execution.