Glossary

Transaction Ordering

Transaction ordering determines the sequence in which transactions are included in a block, directly affecting MEV extraction opportunities.

Key Takeaways

What Is Transaction Ordering?

Transaction ordering refers to the process by which miners (in proof-of-work systems) or validators (in proof-of-stake systems) select and sequence transactions for inclusion in a block. When users broadcast transactions to the network, those transactions enter the mempool: a waiting area of unconfirmed transactions. The block producer then decides which transactions to include, and in what order, when constructing the next block.

This process may sound like a mundane implementation detail, but it has enormous economic implications. In systems with stateful smart contracts like Ethereum, the position of a transaction relative to others can change its execution outcome entirely. A swap that would succeed at one position in a block might fail or return fewer tokens at another. This creates a market for transaction positioning that has generated billions of dollars in extracted value since 2020.

How It Works

Bitcoin: Fee Rate Priority

Bitcoin nodes order transactions by fee rate, measured in satoshis per virtual byte (sat/vB). Miners aim to maximize revenue per unit of block space, so they prioritize transactions that pay the highest fee rate rather than the highest total fee. A small transaction paying 50 sat/vB will be included before a large transaction paying 10 sat/vB because it generates more revenue per byte consumed.

Historically, Bitcoin Core maintained two separate orderings: descendant feerate (looking forward to child transactions) and ancestor feerate (looking backward to parent transactions). Miners selected transactions using ancestor feerate sorting, but this dual system created misalignments that left an estimated 2-5% of potential mining revenue uncaptured.

Bitcoin Core v31.0 introduced cluster mempool, the largest mempool architecture overhaul in 15 years. This system groups connected unconfirmed transactions into clusters and subdivides them into chunks sorted by feerate. Transactions are now ordered based on the feerate at which their entire chunk is expected to be mined, replacing the legacy ancestor/descendant approach. Default policy limits clusters to 64 transactions and 101 kB of virtual size.

# Bitcoin transaction fee rate calculation
# fee_rate = transaction_fee / virtual_size

# Example: 250 vbyte transaction with 5,000 sat fee
fee_rate = 5000 / 250  # = 20 sat/vB

# Miners sort by fee_rate descending
# Higher fee_rate → earlier inclusion in the block

Ethereum: Base Fee + Priority Fee

Before EIP-1559 (August 2021), Ethereum used a simple first-price auction: users bid a single gas price, and miners selected the highest-paying transactions. This led to unpredictable, often excessive gas fees during congestion.

EIP-1559 replaced this with a two-component fee model. Each block has a protocol-determined baseFeePerGas that adjusts algorithmically: it increases by up to 12.5% when blocks are full (30 million gas) and decreases by up to 12.5% when blocks are empty, targeting 50% capacity (15 million gas). The base fee is burned, not paid to validators.

Users also set a maxPriorityFeePerGas (the tip) paid directly to validators as an incentive. Validators order transactions by effective priority fee descending, since the base fee is identical for all transactions in a given block. Higher tips get earlier inclusion.

// Ethereum EIP-1559 fee calculation
// effectiveFee = min(maxFeePerGas, baseFee + maxPriorityFee)
// validatorTip = effectiveFee - baseFee

// Example transaction parameters
maxFeePerGas: 30 gwei
maxPriorityFeePerGas: 2 gwei
baseFeePerGas: 25 gwei  // protocol-determined

// Effective fee: min(30, 25 + 2) = 27 gwei
// Validator receives: 27 - 25 = 2 gwei (the tip)
// 25 gwei per gas is burned

Why Transaction Ordering Creates MEV

Maximal extractable value (MEV) exists because the sequence in which transactions execute affects their outcomes. On Ethereum, where smart contracts maintain shared state, reordering transactions around a target can generate risk-free profit for the entity controlling the ordering. Cumulative MEV extraction across all chains has exceeded $7.2 billion since 2020.

Front-Running

A front-runner detects a pending transaction in the mempool (for example, a large DEX swap) and places their own transaction ahead of it. The front-runner's transaction executes first, moving the price, and the victim's transaction executes at a worse rate.

Sandwich Attacks

A sandwich attack combines front-running and back-running. The attacker places a buy order before the victim's swap (raising the price), then a sell order immediately after (profiting from the inflated price). The victim receives fewer tokens due to excess slippage. In 2025, sandwich attacks constituted over 51% of total MEV volume on Ethereum.

Back-Running and Arbitrage

Back-running places a transaction immediately after a target transaction. This is common in arbitrage: after a large swap moves the price on one DEX, a bot arbitrages the difference across exchanges. Unlike front-running, back-running can be beneficial to the network by correcting price discrepancies.

Solutions and Mitigations

Flashbots and Sealed-Bid Auctions

Flashbots introduced a first-price sealed-bid auction for transaction ordering on Ethereum. Instead of broadcasting transactions to the public mempool, searchers submit private transaction bundles to block builders via the eth_sendBundle RPC endpoint. Bundles execute atomically: either all transactions succeed, or none are included.

Searchers express bids through direct ETH transfers to the block's coinbase address, enabling conditional compensation where users only pay if transactions succeed. This eliminates the "dark forest" problem of front-running in the public mempool, as transactions remain unseen until included in a block.

Proposer-Builder Separation

Proposer-builder separation (PBS) splits the validator's role into two specialized functions. Builders collect transactions and construct the most profitable block, while proposers (validators) select the highest-value block header without seeing its contents. This separation prevents validators from directly manipulating transaction order for personal gain.

The current implementation uses MEV-Boost, an out-of-protocol middleware that over 90% of Ethereum validators run. MEV-Boost adds an estimated 10-30% to base validator rewards. However, block building has become concentrated: a small number of builders dominate the market, raising centralization concerns.

EIP-7732 (enshrined PBS) aims to bring PBS directly into Ethereum's consensus protocol, eliminating the dependency on third-party relays. It is scheduled for inclusion in Ethereum's Glamsterdam upgrade.

Fair Ordering Protocols

Fair ordering protocols aim to remove ordering manipulation entirely through cryptographic techniques. Chainlink's Fair Sequencing Services (FSS) uses threshold encryption: users submit encrypted transactions to an oracle network, which orders them by arrival time without seeing their contents. Only after ordering consensus is reached are transactions collectively decrypted.

Shutter Network deployed the first live threshold-encrypted mempool on Gnosis Chain mainnet. Users encrypt transactions with a distributed public key, block proposers order the ciphertexts without knowing their contents, and a committee of "Keypers" publishes decryption shares after block finalization.

Bitcoin vs. Ethereum: MEV Exposure

Bitcoin has significantly less MEV exposure than Ethereum for several structural reasons. Bitcoin's scripting language is intentionally limited to basic operations like value transfers, signature validation, and hashlocks. It does not support the complex stateful smart contracts that enable DEX trading, lending, and liquidation on Ethereum.

The UTXO model is also inherently more order-independent than Ethereum's account model. Each Bitcoin transaction consumes specific unspent outputs, so reordering simple transfers generally does not change their results. In Ethereum's account model, transactions have sequential nonces, and state changes compound across transactions: the order directly affects execution outcomes.

That said, newer Bitcoin protocols like Ordinals and Runes have introduced limited MEV vectors, including inscription sniping and PSBT swap front-running on marketplaces. Layer 2 networks built on Bitcoin may also face ordering-related MEV challenges as they grow in complexity. For a deeper analysis, see the Bitcoin L2 MEV extraction analysis.

Use Cases

  • Fee market efficiency: ordering by fee rate ensures that users who value timely confirmation most can secure priority inclusion, creating a functioning market for block space
  • Arbitrage and price discovery: back-running enables arbitrage bots to correct price discrepancies across DEXes, improving market efficiency for all participants
  • Private transaction submission: sealed-bid auctions allow users to submit transactions without exposing them to the public mempool, protecting against front-running
  • Validator revenue: MEV-aware ordering increases validator rewards, contributing to the economic security of proof-of-stake networks
  • Layer 2 sequencing: rollup sequencers must implement their own transaction ordering policies, with some exploring fair ordering and encrypted mempools to mitigate sequencer-extractable MEV

Risks and Considerations

Centralization of Block Building

Specialized block building creates economies of scale: builders with more private order flow and better MEV extraction algorithms produce more valuable blocks, attracting more flow. This positive feedback loop can concentrate block building among a small number of entities, undermining the decentralization that blockchains are designed to provide.

User Harm from MEV Extraction

Sandwich attacks and front-running directly harm users through worse execution prices. While MEV protection tools (private RPCs, MEV-aware wallets) have reduced the impact on Ethereum, with monthly sandwich attack value declining roughly 75% between late 2024 and late 2025, less sophisticated users remain vulnerable.

Censorship Risk

When a small number of builders construct most blocks, they gain the ability to censor specific transactions. Proposals like FOCIL (EIP-7805) address this by giving multiple validators a role in identifying transactions that a builder must include, but censorship resistance remains an active area of research.

Cross-Chain and Layer 2 Complexity

As activity moves to Layer 2 networks, transaction ordering challenges multiply. Rollup sequencers control ordering on their chains, and cross-rollup MEV creates new attack vectors. Understanding transaction ordering on fee markets and mempool architectures is increasingly important for both users and protocol designers.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.