Solana rule to enforce fee-priority closes without merge

The SIMD-0649 pull request would have let validators mark a block invalid when transactions inside the same completed batch appeared out of fee-priority order. Maintainers closed the request without merging on Sept. 25, leaving the proposal under further discussion.

Under the draft, validators replaying a block would compare recorded priority scores for transactions inside each non-final batch. If the sequence violated a non-increasing priority rule for non-exempt transactions, the validator would treat the block as invalid. The rule would not reshuffle or add transactions. Leaders, the nodes that assemble blocks, would still decide which transactions to include and how to divide them into batches.

The draft defined the priority score as the leader reward for including a transaction divided by the transaction’s requested cost under the pre-execution cost model. The leader reward in the formula included the user priority fee plus the portion of the base fee that is not burned. The calculation uses integer arithmetic with a multiplier and a one-unit guard in the denominator. Transactions with equal scores could appear in either order. Simple vote transactions were exempt from the check.

The ordering check applied only within batches, not across an entire slot. To reduce trivial workarounds, the draft required every batch except the final one in a slot to span at least two forward error correction sets; under Solana’s fixed-size FEC rule that corresponds to at least 64 data shreds. The final batch would remain subject to the ordering check but would be exempt from the size minimum when a slot ends before it fills.

Reviewers asked for present-day batch-size statistics broken down by scheduler, client and market conditions. The proposal cited client implementations that target batches of about two FEC sets but did not include a measured distribution showing how often leaders currently produce smaller batches.

Engineers raised performance questions. Waiting for an entire batch could increase broadcast latency at low throughput and could affect implementations that replay partially received data. The draft was revised to allow validators to compare and execute transactions as they arrive and later declare a block invalid if a subsequent comparison fails, but it did not quantify potential delays.

The draft also would not stop a leader from favoring its own transactions by paying priority fees to itself, since the proposal assumes those fees return to the leader while the burned portion of the base fee remains a cost. Maintainers closed the pull request after calls for more discussion and wider client support; the within-batch ordering check remains available for future revision.