A proposed rule for Solana transaction ordering, known as SIMD-0649, stalled on September 25, 2026, after its pull request closed without merging. This development means block producers, also called leaders, on the Solana network will maintain their full discretion over which transactions enter a block and how they are batched. CryptoSlate Editor-in-Chief Liam ‘Akiba’ Wright reported on this issue two days later.
The decision postpones efforts to implement a more predictable and auditable system for transaction sequencing within batches on the high-speed blockchain. While the proposal sought to enforce fee-priority ordering for certain transactions, its failure to advance leaves key aspects of transaction processing unchanged.
Solana transaction ordering and proposed fee-priority
It highlights the intricate balance between network performance and transparent execution in decentralized environments, a factor increasingly important as institutions explore tokenized US stocks and other blockchain-based financial products.
SIMD-0649 aimed to allow validators to reject blocks where transactions within a single batch were not arranged by fee-priority. The objective was to make the sequence of transactions within completed batches both inspectable and enforceable across the network. This would have provided a clearer audit trail for ordering.
Crucially, the proposal did not intend to dictate which transactions a leader should include in a block. Nor did it specify how those transactions should be divided into batches. Leaders would have retained their authority to select transactions and define batch boundaries, focusing the rule on internal batch consistency.
Under the draft, non-exempt transactions in each batch would need to appear in a non-increasing priority order. A validator replaying such a block would verify these priorities and invalidate any block found in violation. This mechanism would not reshuffle transactions into the correct sequence but would rather flag non-compliance directly.
The distinction matters to traders trying to predict where an order will land, ensuring a clearer standard for validation.
The priority score itself was a nuanced calculation, not simply a ranking by the fee paid. It factored in the reward a leader receives for including a transaction, divided by its requested compute cost. This calculation considered both the priority fee and the unburned portion of the base fee, requiring client consistency for accurate computation.
Block producers retain significant discretion
With SIMD-0649 stalled, Solana block producers continue to wield substantial control over transaction inclusion and ordering. They can still choose which transactions to accept, defer others to later batches, and set the precise boundaries for each batch. These powers allow leaders to influence whether competing transactions ever face the same ordering test.
For instance, a transaction with a higher priority score in a later batch wouldn’t automatically precede a lower-priority one in an earlier batch. The proposal did attempt to prevent leaders from creating excessively small batches to bypass the rule.
It would have required each batch, except the final one, to span at least two Forward Error Correction (FEC) sets, equating to a minimum of 64 data shreds.
However, the lack of comprehensive data on current batch sizes makes the actual impact of such a minimum uncertain. Reviewers had sought more detailed batch-size data, broken down by scheduler and client, to assess the rule’s practical reach. Without this evidence, it’s difficult to quantify how much leader behavior would truly change. Investors monitoring Solana price technical analysis should note these underlying protocol dynamics.
Furthermore, SIMD-0649 would not have prevented leaders from favoring their own transactions by self-assigning priority fees. These fees return to the leader, while the burned share of the base fee remains a cost. This nuance underscores that the proposed ordering test was not a guarantee against preferential treatment, Maximal Extractable Value (MEV), or slippage.
Broader context of MEV on Solana
Maximal Extractable Value (MEV) refers to the profit opportunities that block producers can capture by manipulating the ordering, inclusion, or exclusion of transactions. On Solana, MEV manifests differently than on Ethereum due to its unique architecture. Solana lacks a public mempool, and transactions go directly to the current leader.
MEV extraction on Solana is often described as a “latency contest,” where value is captured in microseconds between a state change and a competing transaction landing in the next slot. Common MEV strategies include arbitrage across decentralized exchanges, liquidations, and front-running. These tactics contribute to the complexity of ensuring fair execution.
Jito Labs has played a significant role in optimizing MEV extraction on Solana, releasing a validator client in August 2022. Jito’s bundling mechanism and auction-based marketplace have substantially increased validator revenue. By mid-2026, the Jito-Solana client runs under more than 95% of Solana’s active stake, highlighting its dominance in this sector.
The aggregate searcher profits captured through Jito bundles exceeded $480 million cumulatively as of Q2 2026, with monthly run-rates between $30 million and $50 million.
This activity highlights the ongoing importance of transparent execution in a market where specialized trading, like the ether futures trading volume on platforms such as Kalshi, often relies on predictable order flow. The Jito Foundation aims to ensure MEV is efficiently extracted and shared with stakers and validators.
This practice helps to increase Solana’s overall security and decentralization.
Technical hurdles and community feedback
The closure of SIMD-0649’s pull request on September 25, 2026, followed a call for more discussion and support from client developers. A primary concern was the lack of clear data regarding the rule’s practical impact on actual trading outcomes. Without measured distributions of current batch sizes, the effect of minimum batch requirements remained speculative.
Another significant technical hurdle involved potential interference with Firedancer, a validator client, and its practice of replaying partially received data. An August discussion raised latency concerns, suggesting that waiting for an entire batch for a check could disrupt this process.
While a revised draft permitted validators to execute transactions as they arrive and invalidate the block later, the extent of added broadcast delay at low throughput wasn’t measured.
The proposal’s stalling highlights the iterative nature of protocol development within the Solana ecosystem. While the goal was to enhance transparency in Solana transaction ordering, the community and developers signaled a need for further refinement and broader consensus. The Sept. 25 closure specifically followed a call for more discussion and support from client developers, underscoring the collaborative and cautious approach to significant protocol changes.
The ongoing dialogue underscores that even well-intentioned improvements require rigorous testing and clear evidence of their real-world benefits. The absence of specific batch data leaves the effect on execution predictability unresolved. Future iterations will likely need to address these practical concerns to gain wider acceptance and implementation.