SIMD-0649 Closed Without Merging as Solana's Priority-Ordering Rule Waits on

SIMD-0649, a proposal to make fee-priority ordering a hard rule inside Solana blocks, was closed without being merged on 25 September 2026. Jacob Creech closed the pull request with a one-line explanation: "Closing pending more discussion #605. We need more ACKs by client devs here." The proposal is parked, and its author can revise and resubmit it once the teams that build Solana's validator software sign off.

The author is Max Resnick, whom CoinDesk's Consensus speaker page lists as Lead Economist at Anza. Resnick has argued that Solana's market structure should compete with traditional exchanges, a case he laid out on Lightspeed in June 2025. SIMD-0649 was a narrow first step in that direction.

What SIMD-0649 Proposed for Solana Transaction Ordering

SIMD-0649 would have required Solana leaders to record transactions in descending priority order within each entry batch, and made any block that broke the order invalid. An entry batch is one of the chunks a leader, the validator producing a block, streams to the rest of the network during its slot.

Priority is defined in the proposal text as the leader's reward from a transaction divided by the compute cost it requests (reward × 1,000,000 / (cost + 1)). In plain terms, a transaction paying more per unit of work goes first. Simple vote transactions are exempt and can sit anywhere. To stop leaders from dodging the check by cutting blocks into one-transaction batches, every batch except the last would have to span at least two FEC sets, the erasure-coded groups of data that Solana uses to spread blocks across the network. CryptoSlate's write-up of the closure puts that floor at 64 data shreds.

Leaders would keep control of which transactions to include and where to draw batch boundaries. The proposal lists its non-goals plainly: it does not constrain inclusion, does not impose ordering across a whole slot, does not stop a leader paying priority fees to itself, and does not address MEV or sandwich attacks.

Why Priority Ordering Matters for Solana Traders

The motivation is predictability. The proposal states that "at least 13 distinct scheduler implementations are active on mainnet today," each with its own logic for sequencing transactions. For a trader, that means the same fee can buy a different place in line depending on which leader holds the slot. Enforcing the order in replay, when every validator re-executes the block, would make "the rule hold for every client and every scheduler."

The priority fee is the main input to that ranking. Transactions on Solana paid between roughly 2,200 and 9,000 SOL a day in priority fees over the 30 days to 26 September 2026, according to Solana Compass network fee data.

An independent developer has already built peckorder, a tool that replays real blocks against the draft rule. In slot 450356456 it flagged 119 of 269 non-vote transactions as out of order, while noting that "nobody is breaking a rule today" because the SIMD is only a draft. In that block, the gap between current practice and the proposed standard was wide.

Jito JTO$0.337+2.5% is attacking the same problem from a different layer. Its Block Assembly Marketplace, explained by Helius, sequences transactions inside trusted execution environments and lets applications plug in their own ordering rules. We covered BAM in depth when Jito's Lucas Bruder walked through it. SIMD-0649 would instead write one ordering rule into block validity itself, applying to every client.

Reviewer Objections: Firedancer Replay and Batch Boundaries

The objections that stalled SIMD-0649 came from reviewers on GitHub, and they focus on whether the mechanism can enforce what it promises and what it costs client software.

The sharpest came from a reviewer posting as umbnat92 on 23 September 2026, who argued the rule is easy to sidestep because leaders still decide where batches end.

In the review, umbnat92 argued that priority only matters for conflicting transactions at execution time, so "a scheduler can order by whatever priority it wants provided that it close the entry batch when it is convenient to violate the order." The same review said that while the SIMD is clear about what it does not want to solve, "it's not clear what is its goal." The review also asked for data behind the two-FEC-set minimum: current batch sizes by scheduler, and how sensitive the outcome is to that number.

Earlier objections in Discussion #605, which Resnick opened on 20 August 2026, went to client architecture. A commenter posting as cavemanloverboy wrote that "all firedancer entries have a transaction batch of length 1," so the original rule would change nothing on Firedancer, and that the check would force replay to stall "until the whole batch is deserialized and checked," because Firedancer starts replaying partially received batches. The same commenter floated "only allowing one entry batch per 2 fec sets," close to the minimum the final PR adopted, but the replay-latency concern was still open when the PR closed. Another participant, HGuillemet, raised the practical dilemma of a high-priority transaction arriving mid-batch: close the batch early and pad the data, or make the transaction wait.

Next Steps: Client-Developer ACKs and a Possible Resubmission

SIMD-0649's path forward runs through Solana's client teams. The repository's merge bot listed at least one approval from an Anza team member and one from a Firedancer team member as required before PR #649 could merge, and Creech's closing note asks for more acknowledgements from client developers.

Discussion #605 is where the conversation continues, and no resubmission date has been announced. A revised SIMD-0649 would need to answer the batch-boundary escape route, quantify the replay cost for Firedancer's streaming design, and justify the batch-size floor with data. The more interesting question is whether a validity rule can deliver predictable ordering at all while leaders control batch boundaries, or whether that goal sits better with market designs like BAM or Resnick's longer-term work on multiple concurrent leaders.