Solana’s attempt to tighten transaction ordering within block batches has hit a pause, as the community-reviewed pull request was closed without being merged. The move leaves block-producer discretion largely untouched while keeping a narrower audit mechanism alive for future discussion.
Proposed ordering rule
The draft, identified as SIMD-0649, sought to let validators reject a block if the transactions inside a single batch were not recorded in descending fee-priority order. The priority score would be calculated from the leader’s reward – comprising the priority fee and the unburned portion of the base fee – divided by the transaction’s requested cost under Solana’s pre-execution cost model. The rule would apply only to non-exempt transactions within each batch, allowing equal-priority entries to appear in any sequence and exempting simple vote transactions.
Why the proposal stalled
The pull request was closed on Sept. 25 after a call for more input from client developers. Reviewers highlighted several practical concerns: the ability of leaders to manipulate batch boundaries, the lack of data on how often current leaders produce batches smaller than the required minimum, and potential latency impacts for validators that wait for a batch to reach the two-FEC-set size (at least 64 data shreds). Without empirical batch-size statistics, the community could not gauge how the rule would affect ordinary block production.
Limits of the draft’s scope
Even if adopted, the rule would not dictate which transactions a leader may include, nor would it move a high-priority transaction from a later batch ahead of a lower-priority one placed earlier. The check would merely verify that the order inside a completed batch matches the computed priority score; it would not reshuffle transactions after receipt. Moreover, the proposal does not prevent a leader from favoring its own transactions by paying itself priority fees, as those fees return to the leader while the burned portion of the base fee remains a cost.
Potential impact on traders and network stability
For traders, the draft would provide a measurable way to confirm whether a batch’s ordering aligns with fee-priority expectations, offering greater transparency for intra-batch execution. However, because leaders retain freedom to select and schedule transactions across batches, the rule does not guarantee best-execution outcomes across an entire slot. Critics also warned that enforcing a minimum batch size could introduce broadcast delays when network throughput is low, possibly affecting Solana’s advertised 250-300 ms latency advantage.
Next steps
The closure of SIMD-0649 signals that further discussion and data collection are needed before any ordering enforcement is implemented. Developers of major validators such as Agave and Firedancer, which aim for batches of roughly two FEC sets, may need to provide concrete batch-size metrics. Until then, Solana’s transaction-ordering landscape remains governed by existing leader discretion, with only a narrow audit path available for future refinement.
Why it matters
Transparent transaction ordering is a key factor for market participants seeking predictable execution and for the broader ecosystem’s resistance to miner-extractable value. By postponing the rule, Solana maintains flexibility for validators but also leaves open questions about fairness, latency, and network stability that could influence trader confidence and the chain’s competitive positioning against other high-throughput platforms.
