Community Trust ScoreVerified
Solana’s push to clean up its transaction ordering hit a wall. A draft proposal meant to let validators reject badly ordered blocks was closed September 25 without merging, and the debate it kicked off isn’t close to settled.
The proposal, formally called SIMD-0649, had a pretty straightforward goal on paper: force block producers to arrange transactions within each batch by fee priority, highest to lowest. Not a radical idea. Fee priority ordering is basically how most people assume blockchains already work. But Solana’s architecture is different enough that getting there requires a formal rule — and apparently, getting that rule right is harder than it sounds.
How SIMD-0649 Actually Worked
Under the draft, Solana’s block producers — called leaders — would keep their existing power to pick which transactions go into a block and how those transactions get grouped into batches. The rule wouldn’t touch that. What it would do is make the order inside each batch inspectable and enforceable. Transactions would need to appear in non-increasing priority order, though transactions sharing the same priority score could land anywhere within the batch.
Priority score itself gets calculated by dividing the reward to the leader by the transaction’s cost. That calculation folds in both the priority fee and the unburned base fee. So it’s not just about who paid the most in raw terms — it’s a ratio, weighted against what the transaction actually costs the network to process.
And then there’s the batch size rule. Each batch would need to span at least two forward error correction sets — that’s a minimum of 64 data shreds — except for the very last batch in a block. The logic: if you let leaders create tiny batches, they can game the ordering check by isolating transactions they want to favor into their own small container, where there’s nothing else to compare against.
Why Reviewers Pushed Back
The concerns that killed the merge aren’t small. Reviewers flagged that leaders could still exploit the batch closure process itself to dodge the rule’s intent. Close a batch at the right moment, and you’ve effectively separated competing transactions without technically breaking the ordering requirement. The proposal doesn’t solve that.
It also doesn’t touch internal fee payments. A leader could theoretically favor their own transactions by paying fees to themselves internally, and SIMD-0649 wouldn’t catch it. That’s a gap, and critics noticed.
Latency came up too. Enforcing a minimum batch size means leaders can’t broadcast a block until they’ve accumulated enough transactions to hit the 64-shred floor. At low throughput — when the network isn’t busy — that wait could delay block broadcast meaningfully. Validators would process transactions as they arrive and then invalidate the block if a later ordering check fails. That’s not a clean flow.
None of these are hypothetical edge cases. They’re structural vulnerabilities in the draft as written.
What’s Missing From the Data
Maybe the biggest problem: nobody actually knows how often current batch sizes would fail the proposed minimum. The draft doesn’t quantify it. There’s no empirical data on how leaders are currently grouping transactions, how small those batches typically run, or how frequently the ordering check would trigger a rejection under real network conditions.
Without that, the whole proposal is kind of theoretical. You can’t assess whether the rule changes anything in practice if you don’t know what practice currently looks like. Stakeholders are being asked to accept a rule whose effect on execution predictability is, by the draft’s own admission, speculative.
That uncertainty matters a lot for traders and protocols building on Solana. Predictable transaction ordering is basically the foundation of fair execution — especially for anything involving time-sensitive trades or arbitrage. If the rule doesn’t actually deliver that, it’s not clear what it delivers.
The Solana community still needs input from client developers specifically. And it needs real batch-size data before any revised version of this rule can be evaluated honestly. The closure of SIMD-0649 wasn’t a rejection of the idea — it was a signal that the idea needs more work, more evidence, and probably a different approach to the batch-closure problem.
Whether a revised draft comes back with those fixes is unclear. No timeline was given when the proposal was closed September 25.
Hub: Solana price, news, and analysis
Frequently Asked Questions
What was SIMD-0649 trying to fix on Solana?
SIMD-0649 aimed to enforce fee-priority ordering within transaction batches, letting validators reject blocks where transactions weren’t arranged from highest to lowest priority score.
Why was SIMD-0649 closed without merging?
The proposal was closed September 25 after reviewers raised concerns about leaders exploiting batch closures, unaddressed internal fee payments, potential latency at low throughput, and a lack of empirical data on current batch sizes.
Why It Matters
The failure to advance the SIMD-0649 proposal highlights ongoing challenges within the Solana ecosystem regarding transaction efficiency and validator governance. As transaction ordering impacts user experience and overall network performance, this stall could hinder Solana's ability to attract and retain users in a competitive blockchain landscape where efficient transaction processing is paramount. The unresolved debates surrounding this issue also reflect broader tensions in the crypto community about consensus mechanisms and the balance of power among validators.
