A Solana proposal to standardize transaction ordering within batches would require validators to check whether transactions follow fee priority, while leaving block producers free to choose which transactions to include and where batches begin and end. SIMD-0649’s pull request closed on Sept. 25, 2026, without being merged, so the rules have not taken effect. With no measured data on current batch sizes, it remains unclear whether the proposal would make transaction execution more predictable.
SIMD-0649 would check ordering within batches
Solana organizes block data into batches. Under the proposal, transactions in the same batch would have to be ordered from highest to lowest priority, apart from exempt transactions. Validators would check the recorded order when replaying a block and reject it as invalid if it did not comply, rather than reorder transactions after receiving it.
Transactions with equal priority could appear in any order, and simple vote transactions would be exempt. The proposed priority score would not simply reflect the fee entered by a user. It would divide the reward a block producer receives for including a transaction by the requested cost under the cost model before execution. The calculation would use a multiplier and denominator safeguards, with integer arithmetic intended to produce consistent results across clients.
Under the proposal’s fee rules, the reward would include the priority fee and the portion of the base fee that is not burned. If adopted, the rule would give observers a common way to check whether non-exempt transactions already placed in the same batch were ordered consistently. The proposal’s authors said this could help compare transaction ordering across validator clients and schedulers, but it would not determine whether a transaction should have been included in the block in the first place.
Block producers would retain control over inclusion and batch boundaries
The proposal would not establish a single priority queue for an entire slot. Block producers would still choose which transactions to include, defer transactions to later batches and set batch boundaries. As a result, competing transactions might not land in the same batch and therefore might not be compared under the ordering rule. A higher-priority transaction placed in a later batch would not automatically move ahead of transactions in an earlier one.
That leaves the proposal narrower than slot-wide ordering rules and does not guarantee optimal execution. It therefore sets a minimum batch size, intended to prevent block producers from weakening the checks by splitting batches into very small groups with fewer transactions to compare.
Each batch except the last would have to cover at least two forward error correction (FEC) sets. An FEC set consists of data shreds that make up block data; under the proposal’s fixed sizing rule, two sets amount to at least 64 data shreds. The final batch would still be subject to the ordering check, but would not have to meet the size minimum because a slot can end before the batch is full.
Missing batch-size data limits assessment of the proposal
A review comment on Sept. 23 noted that, even with a minimum size, a block producer could end a batch when doing so would help separate competing transactions. The reviewer asked for current batch-size data broken down by scheduler, client and market conditions, and suggested testing how different minimums affect outcomes. The comments questioned how much the rule might cover in practice; they did not indicate that block producers had used this approach on mainnet.
The proposal said Agave and Firedancer target batches of about two FEC sets, but neither the proposal nor the review comments provided a distribution of actual batch sizes produced today. That makes it difficult to quantify how the minimum would affect routine block production or how much it would constrain producers’ ability to adjust batch boundaries.
Latency and priority-fee concerns remain
A discussion in August raised a latency concern: if validators had to wait for a full batch before checking it, that could affect Firedancer’s ability to replay data as it arrives. A revised draft would allow validators to compare and execute transactions incrementally, rejecting the block if an ordering violation emerged later. But when transaction volume is low, requiring producers to wait until a batch reaches the two-FEC-set minimum could add broadcast latency. The available materials include no latency measurements.
The proposal would also not prevent a block producer from favoring its own transactions by paying itself a priority fee. SIMD-0649 notes that priority fees go to the block producer, while the burned portion of the base fee remains a cost. Batch-level ordering checks therefore would not, by themselves, prevent preferential treatment, maximum extractable value (MEV) or slippage.
SIMD-0649 closed on Sept. 25, with any further progress dependent on additional discussion and support from client developers. For traders, the key unknowns are how many genuinely competing transactions would land in the same batch and whether a minimum batch size would change producer behavior. Until those data are available, the proposal offers a way to verify relative ordering within a batch, but its effect on actual execution remains uncertain.