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

[artofbitcoin]

What you observed is expected on OP Mainnet today, and the reason is that the block isn't built by the op-geth miner loop you read.

OP Mainnet blocks are built with Flashblocks. The sequencer runs op-rbuilder (a reth-based builder) behind rollup-boost, and it emits each 2-second block as a series of ~250 ms sub-blocks ("flashblocks"). Each flashblock is committed (and streamed as a preconfirmation) as soon as it is built, and later flashblocks only append to it (Optimism: Flashblocks on OP Mainnet, rollup-boost flashblocks spec).

So priority-fee ordering is applied per flashblock, not across the whole block. Within one flashblock, pool transactions are still selected by effective tip per gas (min(maxPriorityFeePerGas, maxFeePerGas - baseFee)) with per-sender nonce order, as you expected. But a transaction that reaches the sequencer after an earlier flashblock has been sealed can only go into a later flashblock, even if its tip is much higher than transactions already committed. The Base docs, which use the same design, spell this out: transactions are ordered by fee at the time of selection, and "a late-arriving high-fee transaction may appear after an already-committed lower-fee transaction" (Base: Block Building).

That matches your observation: an inversion between two unrelated type-2 transactions means the higher-tip one arrived after the flashblock containing the lower-tip one was sealed.

Practical consequences:

• A higher tip buys you priority only against transactions competing for the same flashblock (~250 ms window), not against everything in the 2 s block.
• To be early in a block, arrival time at the sequencer matters as much as the tip.
• The "higher priority fee executes first" statement in the docs is accurate within a flashblock; across flashblock boundaries it is not a guarantee.

If you want to confirm it on your example, subscribe to a Flashblocks-aware endpoint and record which flashblock index each of the two transactions first appeared in: the lower-tip one should be in an earlier flashblock than the higher-tip one.