Mempool Ordering

Overview

Mempool ordering determines which pending transactions receive attention first. Nodes may organize candidates by ancestor-adjusted fee rate, arrival, nonce dependencies, priority fees, bundles, or application-specific rules, while block producers can apply their own ordering.

The displayed order in a block explorer is not necessarily the order a producer will use. Private transactions and builder auctions can bypass the public view. Account-based chains must also respect nonce sequence and transaction validity. Users should set slippage, deadlines, and fees based on desired execution rather than relying on visible queue position. Protocols should document ordering powers and censorship controls. Payment systems need to reconcile the final block order because pre-confirmation ordering can change balances, contract outcomes, and conflicts before inclusion.

Mempool Ordering should be represented as a sequence of observable states rather than one success flag. Submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages. Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available. Operational systems need idempotent processing keyed to stable transaction and business identifiers.

Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps. These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Risk-control point: Mempool order is provisional and policy-dependent; only canonical block execution establishes the final transaction sequence and resulting state.