A proposed Solana rule designed to police transaction ordering within batches has stalled. The SIMD-0649 pull request closed on September 25 without merging, leaving unresolved questions about how the blockchain will address ordering fairness.
The draft proposal would allow validators to reject blocks when transactions within a batch are recorded out of fee-priority order. However, it would not give validators power to decide which transactions enter a block at all. Block producers, known as leaders, would retain full discretion over transaction selection and batch boundaries.
What the proposal would and would not do
Under the draft design, non-exempt transactions in each batch would have to appear in non-increasing priority order. A validator replaying the block would compare recorded priorities against a calculated priority score and treat violations as invalid blocks. 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 proposal does not establish whether a transaction should have been included in the first place, nor would it create a single priority queue for an entire slot. Instead, it would provide an inspectable, enforceable ordering only among transactions the leader places in the same batch.
Leaders' retained discretion
Block producers would still choose which transactions to include, defer transactions to later batches, and set batch boundaries. These choices determine whether competing transactions 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, regardless of its priority score.
To prevent leaders from circumventing the rule by creating tiny batches, the draft requires each batch except the final one to span at least 64 data shreds. However, a September 23 review raised concerns that leaders could still strategically close batches to separate conflicting transactions.
Unresolved questions
The review requested present-day batch-size data broken down by scheduler, client, and market conditions, as well as sensitivity tests for different minimum sizes. The proposal does not supply measured distributions showing how often current leaders produce smaller batches. Without this evidence, the effect of the minimum on ordinary block production cannot be quantified.
An August discussion also raised a latency concern: batch-size minimums could add broadcast delay at low throughput, though the public record does not measure that delay.
The proposal explicitly does not prevent leaders from favoring their own transactions by paying priority fees to themselves. This and other retained leader discretions mean the proposed ordering test should not be read as a guarantee against preferential treatment or maximum extractable value concerns.
If a revised rule advances, its practical value will depend on how often meaningful competing transactions share a batch and whether minimum batch sizes change leader behavior in practice.
