The priority score is based on the reward a leader receives for including a transaction divided by its requested cost under the pre-execution cost model. The draft specifies an integer calculation, with a multiplier and a one-unit guard in the denominator, so clients would have to compute the same result. Under the fee rules described in the proposal, the reward includes the priority fee and the unburned portion of the base fee. The score is therefore more specific than a simple ranking by the fee a user names.
That change would give an observer a testable answer to one question: among non-exempt transactions that a leader placed in the same batch, was the recorded order consistent with the proposed score? The author argues that a common check would make ordering easier to inspect across different validator clients and schedulers. The proposal does not establish whether a transaction should have been included in the first place.
Where Solana leaders retain discretion
The draft’s non-goals leave leaders free to select transactions, defer one to a later batch and choose batch boundaries. Those choices can determine whether two competing transactions ever face the same ordering test. A high-priority transaction in a later batch would not be moved ahead of a lower-priority one in an earlier batch simply because its score is higher. Within-batch ordering is thus a narrower property than slot-wide ordering or a guarantee of best execution.
The Solana proposal tries to prevent the most obvious way to empty the rule of meaning: making batches so small that there is almost nothing to compare. It would require each batch except the final one to span at least two forward error correction, or FEC, sets, groupings of the data packets called shreds that make up a block. Under the fixed-size FEC rule on which the draft depends, that means at least 64 data shreds. The final batch would still face the ordering check but would be exempt from the size minimum because a slot can end before it fills.
That minimum does not remove all discretion. In a Sept. 23 review, a reviewer argued that a leader could still close a batch when it was advantageous to separate conflicting transactions, and asked for present-day batch-size data broken down by scheduler, client and market conditions. The review also sought a sensitivity test for different minimum sizes. Those are objections to the rule’s practical reach, not evidence that a leader has already used this tactic on mainnet.
The draft says Agave and Firedancer aim for batches of about two FEC sets, but neither the proposal nor the review supplies a measured distribution showing how often current leaders produce smaller batches. Without that evidence, the effect of the minimum on ordinary block production cannot be quantified. It may close a simple loophole, but the public record does not establish how much behavior it would change.
An August discussion raised a related latency concern: a check that had to wait for an entire batch could interfere with Firedancer’s practice of replaying partially received data. The revised draft permits validators to compare and execute transactions as they arrive, then invalidate the block if a later comparison fails. It also acknowledges that making a leader wait to reach the two-FEC-set minimum could add broadcast delay at low throughput. The sources do not measure that delay.
SIMD-0649 also would not stop a leader from favoring its own transactions by paying priority fees to itself. The draft says those fees return to the leader, while the burned share of the base fee remains a cost. That is another reason the proposed ordering test should not be read as a guarantee against preferential treatment, MEV or slippage.
The Sept. 25 closure followed a call for more discussion and support from client developers. If a revised Solana rule advances, its value to users will turn on how often meaningful competing transactions share a batch and whether the minimum batch size changes leader behavior. The public proposal specifies a way to audit their relative order, but the missing batch data leaves its effect on actual execution predictability unresolved.
