Solana’s transaction ordering proposal stalls without client approvals needed to merge
Solana’s SIMD-0649 proposal, which would have forced block producers to record transactions in strict fee-priority order within each entry batch, closed on Sept. 25 without merging, leaving leaders free to pick which trades enter a block and when a batch ends. For market makers and high-frequency desks routing volume through Solana, the stalled fix means execution order remains a matter of validator discretion rather than a code-enforced, auditable queue.
- The SIMD-0649 pull request closed Sept. 25 pending more client-developer approvals, per the GitHub thread.
- The draft requires every non-final entry batch to span at least two forward error correction sets, or 64 data shreds.
- A Sept. 23 reviewer argued a leader could still close a batch strategically to separate conflicting transactions, undercutting the rule.
- Sept. 25 date SIMD-0649 closed without merging into Solana’s codebase
- 64 minimum data shreds required per non-final entry batch
- 2 FEC sets Agave and Firedancer already target per batch today
The proposal would not decide which transactions a block producer, known as the leader, chooses to include. It would only make the order of transactions inside a completed batch inspectable and enforceable against a fee-based priority score. A validator replaying the block would compare recorded priorities and reject the block as invalid if a non-exempt transaction appeared out of sequence.
SIMD-0649 Needs More Acks From Anza and Firedancer
The pull request required at least one approval from an Anza team member and one from a Firedancer developer. Neither threshold was met by Sept. 25, and the author closed the request “pending more discussion” and asked for “more ACKs by client devs,” according to the document.
The draft grew out of an August discussion on Solana’s GitHub. That thread turned informal debate into a formal specification defining priority as the leader’s reward per unit of requested execution cost.
The reward calculation folds in both the priority fee a user names and the unburned portion of the base fee, using an integer formula with a multiplier and a one-unit guard in the denominator. That makes the enforceable score narrower than a simple fee ranking, and it means the same replay math must produce identical results across every client.
Leaders Retain Full Discretion Over Batch Boundaries
The proposal’s stated non-goals leave leaders free to select which transactions to include, defer any transaction to a later batch, and choose where one batch ends and the next begins. A high-priority transaction placed in a later batch would not be moved ahead of a lower-priority one sitting in an earlier batch, even though its score is higher.
Within-batch ordering is therefore narrower than slot-wide ordering or any guarantee of best execution.
SIMD-0649 also does nothing to stop a leader from paying priority fees to itself. The document confirms those fees return to the leader while only the burned share of the base fee is a real cost, so the rule cannot be read as protection against preferential treatment, MEV or slippage.
The two-FEC-set minimum, or 64 data shreds, targets the most obvious workaround: shrinking batches until there is nothing left to compare.
But the Sept. 23 reviewer noted that a leader “could still close a batch when it was advantageous to separate conflicting transactions,” and asked the author for present-day batch-size data broken down by scheduler, client and market conditions, plus a sensitivity test for alternate minimums.
The document says Agave and Firedancer already target roughly two FEC sets per batch, but neither the proposal nor the review supplies a measured distribution showing how often real batches fall short of that today, leaving the rule’s practical bite unquantified. That gap is the material open question the record does not resolve.
Firedancer’s Partial-Data Replay Raises a Latency Trade-Off
The August discussion flagged a separate concern: a validity check that had to wait for a whole batch could interfere with Firedancer’s practice of replaying data as it arrives. The revised draft lets validators compare and execute transactions as received, then invalidate the block later if a comparison fails, avoiding a hard stall.
The document also concedes that forcing a leader to reach the two-FEC-set minimum could add broadcast delay when throughput is low. Neither the discussion nor the pull request measures how large that delay would be.
The CCS read. The unresolved question here is not fairness on paper but who bears execution risk in practice. Institutional desks trading Solana perpetuals or spot pairs still cannot treat batch placement as neutral, since a leader can defer or split transactions before any ordering check applies. Until someone publishes batch-size data across schedulers, order-routing risk on Solana stays a discretionary cost, not a measured one, a gap regulators tracking market structure may eventually probe.
The pull request remains closed, and the author has signaled it will return only once more Anza and Firedancer developers register approval on the underlying draft specification. Whether a revised version ships with the requested batch-size distribution is the next thing to watch in Solana’s client-developer discussions.
Original reporting: cryptoslate.com
