Transaction Ordering Policy

A core requirement where the final ordering of transactions must be deterministically reproducible by any honest node given the same mempool state. This prevents forks and ensures network consensus. Without it, validators could produce conflicting blocks from the same transaction set.

• Example: In Ethereum's Gas Price Auction, the canonical order is determined by sorting transactions by descending gasPrice and then by nonce.

Policies define how resistant the system is to transaction censorship or frontrunning. A fair policy minimizes the ability for powerful actors (like block proposers or MEV searchers) to arbitrarily exclude or reorder transactions for profit.

• Time Boost: Some policies include a time-based priority boost to prevent indefinite exclusion.
• Commit-Reveal Schemes: Used to hide transaction content until ordering is decided, mitigating frontrunning.

The efficiency of the ordering algorithm directly impacts transactions per second (TPS) and confirmation latency. Parallelizable policies (e.g., ordering by account shards) enable higher throughput. The policy also defines the finality time—how quickly users can trust an order is settled.

• Bottleneck: A complex, global sorting rule can become a throughput bottleneck for the sequencer.

The ordering policy is the primary source of MEV. It determines the surface area for value extraction through arbitrage, liquidations, and sandwich attacks. Policies can be designed to mitigate MEV (e.g., fair ordering) or explicitly auction it off (e.g., PGA - Priority Gas Auctions).

• MEV-Boost: Ethereum's marketplace where block proposers sell their ordering rights to specialized searchers.

Specifies who controls the ordering function. This ranges from permissionless validator sets (decentralized) to a single sequencer (centralized, common in L2 rollups). The policy defines the trust assumptions: users must trust the sequencer to follow the published rules.

• Decentralized Sequencer Sets: Multiple entities take turns ordering, reducing single points of failure and censorship.
• Proposer-Builder Separation (PBS): Separates the entity that chooses the block contents from the entity that proposes it.

For systems with a designated sequencer (like many rollups), the policy may offer soft commitments or pre-confirmations to users before transactions are posted to L1. The security of these pre-confirms depends on the sequencer's bonding/slashing conditions and the challenge period for disputing incorrect orders.

Transactions are ordered strictly by the time they are received by the network node or sequencer. This is the simplest policy, often used as a baseline.

• Key Feature: Minimizes centralization of ordering power.
• Drawback: Highly vulnerable to frontrunning and time-bandit attacks, as the public mempool order is predictable.
• Example: The base Ethereum mempool nominally uses FCFS, though miners/validators can reorder transactions, making the practical policy more complex.

A market-driven policy where users explicitly bid (via transaction fees) for priority positioning within a block. Order is determined by descending fee price.

• Key Feature: Creates a transparent, auction-based market for block space.
• Mechanism: Users submit transactions with a maxPriorityFee or similar; the block builder orders by the highest effective fee paid.
• Drawback: Can lead to fee inflation and MEV extraction, as searchers outbid each other to secure profitable positions.

A variant where users submit a bid (fee) without seeing others' bids. The block builder sees all bids and orders transactions accordingly, with the highest bidders winning the best positions.

• Key Feature: Reduces some real-time bidding wars compared to open PGAs.
• Context: This is often the practical model used by Ethereum block builders after EIP-1559, where the priority fee is the sealed bid.
• Consideration: Can still result in overpayment as bidders lack perfect information.

A policy enforced by a centralized or decentralized sequencer designed to mitigate malicious ordering. It uses criteria like transaction receipt time or cryptographic proofs to establish a fair order.

• Goal: Prevent frontrunning and sandwich attacks against ordinary users.
• Implementation: May use a first-seen rule with commit-reveal schemes or threshold encryption to hide transaction content until ordering is decided.
• Example: Flashbots SUAVE aims to provide a decentralized network for fair ordering commitments.

Transactions are placed into a time-based queue (like FIFO) based on a cryptographically verifiable timestamp, often provided by a trusted sequencer or a decentralized time oracle.

• Key Feature: Provides fairness and predictability for users, as order is not for sale.
• Requirement: Depends on a secure and reliable timestamping mechanism, which can be a centralization vector.
• Use Case: Common in high-throughput centralized sequencers for rollups, where the operator defines the order.

The block builder (proposer) actively reorders transactions to extract Maximum Extractable Value (MEV), such as arbitrage or liquidations. The policy is to maximize builder revenue.

• Reality: This is the de facto policy on many chains, as builders run MEV-Boost or similar software.
• Process: Searchers submit bundles of transactions to builders; the builder selects and orders bundles to maximize their profit.
• Impact: Creates a specialized market for block space but can degrade experience for non-MEV transactions.

The simplest ordering policy where transactions are processed in the order they are received by the network node. This is the default, naive approach used by many base-layer blockchains like Bitcoin and Ethereum's execution clients before block building.

• Key Feature: Provides a baseline of fairness and predictability.
• Limitation: Highly vulnerable to Maximum Extractable Value (MEV) exploitation, as the public mempool allows sophisticated actors to front-run or sandwich user transactions.

A market-driven ordering policy where validators or block builders accept transactions with the highest gas fees, often from searchers competing in real-time to have their arbitrage or liquidation bundles included. This is a de facto standard on Ethereum.

• Mechanism: Searchers bid via transaction gas prices, and the builder selects the most profitable sequence.
• Consequence: Leads to MEV extraction, network congestion, and increased costs for regular users. Tools like Flashbots' MEV-Boost formalize this auction process.

Centralized or decentralized sequencers in Layer 2 rollups (e.g., Optimism, Arbitrum, Starknet) enforce a specific ordering policy before submitting batches to Layer 1.

• Typical Policy: Uses a first-come, first-served queue based on when the sequencer receives the transaction, often providing fast pre-confirmations.
• Goal: To offer a fair, low-cost user experience while mitigating L1-level MEV. Some networks are exploring decentralized sequencer sets and time-boosting mechanisms for fairness.

Some decentralized applications implement their own ordering logic on top of the base layer's policy to protect their users.

• Example: A DEX may use a batch auction for its liquidity pools, where all trades in a block are settled at the same clearing price, eliminating sandwich attacks.
• Another Example: CowSwap uses batch auctions with uniform clearing prices and off-chain order matching (CoW Protocol) to provide MEV-protected trades.

An architectural design (formally proposed for Ethereum) that separates the roles of block proposer (validator) and block builder. Builders compete to create the most profitable block bundle via an auction.

• Impact on Ordering: The builder, who wins the auction, has full control over transaction ordering within their block. This professionalizes and centralizes ordering decisions.
• Goal: To democratize MEV profits and prevent validator centralization. MEV-Boost is an in-practice implementation of PBS.

The simplest ordering policy where transactions are processed in the order they are received by the network. While intuitive, it is highly vulnerable to network-level manipulation, as an attacker with better connectivity can ensure their transaction is seen first. This creates a latency race and is the primary enabler for front-running and sandwich attacks in decentralized finance.

A market-driven ordering mechanism where users compete by bidding transaction fees (gas price) to have their transaction included earlier in a block. The highest bidder wins the top position. This is the de facto policy on networks like Ethereum. While it creates a clear economic incentive for validators, it can lead to inefficient fee markets and disadvantages users unwilling to pay exorbitant priority fees.

A class of solutions designed to provide fair transaction ordering by mitigating the advantages of network position. An FSS node or network receives transactions, orders them using a deterministic rule (e.g., by timestamp from a trusted time source), and then submits the ordered batch to the blockchain. This aims to prevent front-running and MEV extraction by malicious validators or sophisticated bots.

The chosen ordering policy directly creates Maximal Extractable Value (MEV) opportunities. Validators (or sequencers) who control block production can reorder, insert, or censor transactions to extract value. Policies that centralize ordering power (e.g., a single sequencer) introduce trust assumptions and censorship risks. Decentralized sequencing and proposer-builder separation (PBS) are architectural responses to mitigate these risks.

A critical security property impacted by ordering. A malicious validator could censor transactions by refusing to include them. Robust networks require mechanisms like credible neutrality and inclusion lists to ensure all valid transactions have a probabilistic guarantee of being processed. The ordering policy must balance efficiency with the ability to resist targeted exclusion of users or applications.

User-facing mechanisms to influence ordering. A time-boost function (used by networks like Solana) allows a transaction to pay an extra fee to reduce its latency penalty, blending FCFS and PGA. Private mempools (or channels) allow users to submit transactions directly to a validator, hiding them from the public mempool to prevent front-running, though this increases reliance on the validator's honesty.