A Solana proposal that would let validators reject blocks with out-of-order transactions inside a batch closed without merging on Sept. 25. Block producers would still choose which transactions enter a block and where each batch begins and ends, leaving the rule's promise of fairer ordering narrower than it first appears.
Solana's SIMD-0649 pull request closed on Sept. 25 without merging, leaving a proposed fairness check for transaction ordering unresolved. The rule would have let validators reject a block when transactions inside one batch were recorded out of fee-priority order — but it would not decide which transactions make the block in the first place.
That 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 check would only make the order of transactions within each completed batch inspectable and enforceable, not establish one priority queue for an entire slot.
How the priority check would work
Solana's ledger groups entries into batches, and the draft would require non-exempt transactions in each batch to appear in non-increasing priority order. A validator replaying the block would compare recorded priorities and treat a violation as an invalid block, though it would not reshuffle transactions into the right sequence after receiving them.
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, using an integer calculation with a multiplier and a one-unit guard in the denominator. The reward includes the priority fee and the unburned portion of the base fee, so the score is more specific than a simple ranking by the fee a user names.
Where leaders retain discretion
The draft's non-goals leave leaders free to select transactions, defer one to a later batch, and choose batch boundaries. A high-priority transaction placed in a later batch would not be moved ahead of a lower-priority one in an earlier batch simply because its score is higher, so within-batch ordering is a narrower property than slot-wide ordering or a guarantee of best execution.
To prevent batches from being made too small to compare, the proposal would require each batch except the final one to span at least two forward error correction sets, or at least 64 data shreds under the fixed-size FEC rule the draft depends on. Still, 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.
Neither the proposal nor the review supplies a measured distribution showing how often current leaders produce smaller batches, even though the draft says Agave and Firedancer aim for batches of about two FEC sets. SIMD-0649 also would not stop a leader from favoring its own transactions by paying priority fees to itself, since those fees return to the leader while the burned share of the base fee remains a cost.
That Sept. 25 closure followed a call for more discussion and support from client developers. If a revised rule advances, its value to traders will turn on how often competing transactions share a batch — and the missing batch data leaves that question unresolved.
Source: CryptoSlate
Trading involves risk.
Risk Disclaimer
