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.

The Solana proposal tries to prevent the most obvious way to empty the rule of meaning: making batches so small that there is almost nothing to compare. It would require each batch except the final one to span at least two forward error correction, or FEC, sets, groupings of the data packets called shreds that make up a block. Under the fixed-size FEC rule on which the draft depends, that means at least 64 data shreds. The final batch would still face the ordering check but would be exempt from the size minimum because a slot can end before it fills.

That minimum does not remove all discretion. In a Sept. 23 review , a reviewer argued that a leader could still close a batch when it was advantageous to separate conflicting transactions, and asked for present-day batch-size data broken down by scheduler, client and market conditions. The review also sought a sensitivity test for different minimum sizes. Those are objections to the rule's practical reach, not evidence that a leader has already used this tactic on mainnet.