Solana proposal to enforce fee order in entry batches goes back to discussion
Serguey Asael Shinder2 min readA proposal to make transaction ordering inside Solana blocks partly enforceable by consensus has been sent back for more discussion. SIMD-0649, opened on 21 September by Max Resnick, turned an August discussion into a formal proposal: within each entry batch, transactions would have to appear in non-increasing priority order, and a block violating that would be invalid. On 25 September the pull request was closed without merging, with the note: "Closing pending more discussion. We need more ACKs by client devs here."
The design, as described in the proposal, is narrower than "priority ordering for the whole block". Solana records transactions in entries grouped into batches. Validators replaying a block would check that, within each batch, non-exempt transactions are ordered by a defined priority score, and would reject the block if not; equal-priority transactions could appear in either order, and simple vote transactions would be exempt. The score is based on the reward a leader receives for including the transaction divided by its requested cost, computed as an integer so all clients get the same answer. To stop leaders from emptying the rule by making batches tiny, every batch except the last would have to span at least two forward-error-correction sets.
What the proposal leaves to the leader is as important. The block producer would still choose which transactions to include, where batches begin and end, and which transactions to defer to a later batch. A high-priority transaction in a later batch would not jump ahead of a lower-priority one in an earlier batch.
What it means
The argument for the rule is inspectability: a common check would let anyone verify that a leader ordered transactions consistently within a batch, regardless of which validator client or scheduler it runs. The limitation is that inclusion and batching decisions, where much of the value in ordering lies, stay with the leader.
Closing the pull request is procedural rather than a rejection. Consensus changes on Solana need agreement from the teams building its validator clients, and the maintainers are asking for that before the proposal can advance.