A proposed Solana consensus rule designed to establish fairer transaction ordering stalled after the SIMD-0649 pull request was closed on Sept. 25 without being merged into the code base. The draft leaves the broader question of validator ordering discretion open for further developer discussion rather than enacting a mandatory slot-wide execution queue.
How SIMD-0649 Enforced Batch-Level Priority Rules
Under the draft specification, Solana block producers—known as leaders—retain the right to select which transactions to include and how to divide them into batch entries. However, SIMD-0649 proposed a consensus check requiring non-exempt transactions inside each finished batch to appear in non-increasing priority order. Replaying validators would audit this sequence and declare an entire block invalid if a priority violation occurred.
The calculated priority score uses an integer formula that divides the leader reward—consisting of the priority fee plus the unburned portion of the base fee—by the transaction's requested cost under the pre-execution model. Simple vote transactions were exempt from this rule, and equal-priority transactions could be ordered in any arrangement. Similar to technical protocol updates seen across other major blockchains, such as when Bitcoin proposal BIP138 was merged, core developers require extensive consensus before altering block validation rules.
Key Takeaways
- SIMD-0649 closed on Sept. 25 without merging, delaying strict within-batch transaction ordering rules for Solana.
- The draft required non-final batches to contain at least two FEC sets (64 data shreds) to prevent leaders from bypassing rules via micro-batches.
- Leaders could still favor their own transactions because priority fees are returned to the block producer, while only the burned base fee acts as a hard cost.
- Clients like Agave and Firedancer target batch sizes of approximately two FEC sets, though full network batch distribution metrics remain unmeasured.
Leader Discretion and Minimum Batch Constraints
To prevent leaders from undermining the rule by creating tiny batches, SIMD-0649 mandated that every batch except the final one must span at least two forward error correction (FEC) sets, representing at least 64 data shreds. The final batch in a slot remained exempt because block production can end before filling a complete set.
Despite this minimum threshold, developer feedback raised concerns about lingering loopholes. In a Sept. 23 review, a reviewer noted that leaders could still strategically close batches to split conflicting trades across batch boundaries. Furthermore, because leaders receive their own priority fees back—paying only the burned share of the base fee—the rule could not stop block producers from prioritizing their own trades. Developer discussions in August also highlighted latency concerns for high-performance clients like Firedancer, which rely on streaming partially received data. Efforts to refine trade routing rules come as alternative networks also explore sub-second transaction sequencing, as seen when Google Cloud joined Puffer for 50-millisecond preconfirmations on Ethereum.
Why It Matters
The stall of SIMD-0649 highlights the fundamental difficulty in curbing Maximal Extractable Value (MEV) and transaction front-running at the consensus level without compromising network throughput. While the proposal offered a clear audit mechanism for completed batches, it failed to solve slot-wide transaction filtering or self-preferencing by leaders. For traders and decentralized finance users, trade execution on Solana will continue to depend heavily on individual validator scheduling algorithms rather than an inspectable protocol-wide rule.
