Priority fee based transaction ordering

[shallowValue]

Did you check the documentation and specs?

• Yes

Was there anything unclear or missing?

I was looking for the exact logic used by the sequencer to order transactions within a block. Unfortunately, I'm still unable to reconcile the behavior I experienced with the docs or the code.
I checked:

• Optimism official docs (priority fee section)
• the recent blog about the staked-based priority ordering experiments
• ethereum-optimism/op-geth miner/payload-building/ordering code

Did you check for duplicate questions?

• Yes

Similar Questions or Issues Found

This was helpful but I was still unable to understand and reconcile the behavior I observed:

#171

Please select the type of request

• Bug Report
• Feature Request

Steps to Reproduce

The docs state:

“The OP Mainnet sequencer will prioritize transactions with a higher priority fee and execute them before any transactions with a lower priority fee.”

However, I saw an OP block where type-2 user transactions were not strictly ordered by effective priority fee per gas. In the same block, a transaction with a lower effective tip per gas was executed earlier than another transaction with a significantly higher effective tip per gas (different senders, no nonce constraints for either sender; I'm ignoring the index-0 system/deposit tx).

I read through ethereum-optimism/op-geth miner code and I understand that for txpool-selected txs, ordering is based on:

• effectiveTipPerGas = min(GasTipCap, GasFeeCap - BaseFee) (per gas),
• with a heap comparator sorting by this value (time only used as a tie-break) with nonce-ordering per account

I also saw that payload building can run multiple build iterations (buildPayload loop), but each iteration seems to rebuild a full candidate block and Payload.update() replaces the whole candidate (not append-only).

Given the above, how is it possible that a block was mined with a lower effective priority fee (tip per gas) transaction ordered ahead of a higher one?
Ignoring system/deposit txs and any explicit priority/forced/local handling: should two regular txpool txs be strictly ordered by effective tip per gas? If not, what’s the actual ordering rule used today (or the best code pointer/spec to rely on)?

Expected vs. Actual Behaviour

Expected: within a block, higher effectiveTipPerGas executes before lower effectiveTipPerGas (for different senders, no nonce constraints).
Actual: observed inversions (lower effectiveTipPerGas tx executed earlier than higher one) among normal type-2 txs.

Software Versions

No response

Operating System

No response

Hardware Resources

No response

Configuration Files, Startup Flags & Environment Variables

No response

Error Messages / Logs

No response

Feature Description

No response

Purpose and Benefits

No response

Relevant Context or Examples

No response