Mempool, Block Production, and Order Flow

Understanding MEV requires a working mental model of how a transaction goes from a user's wallet to an executed block. The picture has changed substantially since 2020, and many older mental models (miner-controlled inclusion, simple first-seen ordering) no longer apply on post-Merge Ethereum.

The Lifecycle of a Public Transaction

[wallet]
   │ signs and broadcasts
   ▼
[public mempool (gossip layer)]
   │ propagates to peers, including searchers
   ▼
[searchers]
   │ build bundles that include or exploit the tx
   ▼
[block builders]
   │ assemble blocks to maximize value
   ▼
[relays]                  ← MEV-Boost
   │ forward blocks to validators
   ▼
[validator (proposer)]
   │ signs the highest-value block
   ▼
[block included on-chain]

A transaction submitted via a standard wallet RPC enters the public mempool, where it is visible to every node connected to the gossip network — including specialized searcher nodes whose entire job is to scan for profitable opportunities. Searchers do not include the user's transaction themselves; they construct bundles (ordered sequences of transactions) that pair the user's transaction with their own, and submit those bundles to block builders. Builders compete to construct the most profitable block. Builders forward their winning candidate blocks to relays, which forward to validators, who sign whichever block pays them the most. This is the MEV-Boost architecture that handles a large majority of Ethereum blocks since The Merge.

The key observation: the user does not control the order of their transaction relative to other transactions. Anyone watching the mempool can construct a transaction that gets ordered before or after the user's, with payment to the builder/validator that ensures it does.

What Searchers See

A searcher with a mempool subscription sees, in real time:

• Every pending transaction's calldata, gas price, gas limit, nonce, and sender.
• The function selector being called and (because contracts are public) the function being called.
• The decoded parameters of the call.
• Any state-changing implications: which pool will be touched, which token will move, by how much, at what slippage.

The searcher can then:

• Simulate the transaction's effect against the current state (using an EVM fork in microseconds).
• Identify whether the resulting state change creates a profitable opportunity (price moved enough to arbitrage another venue, a price oracle moved enough to liquidate a position, an AMM ratio shifted enough to sandwich).
• Construct a bundle that captures the value, and submit it to multiple builders simultaneously.

This entire pipeline runs in milliseconds. The user has no way to react.

Block Building, Builders, and Relays

In post-Merge Ethereum:

• Validators propose blocks but typically outsource the construction to builders, because builders specialize in extracting maximum value.
• Builders assemble blocks from public mempool transactions plus private order flow (bundles from searchers, direct submissions from wallets via Flashbots Protect / MEV-Share, etc.).
• Relays sit between builders and validators, applying validator policies (some validators refuse OFAC-sanctioned addresses; some accept all builders; etc.).
• MEV-Boost is the validator-side software that participates in this auction.

The market is concentrated: a handful of builders (rsync-builder, Titan, Beaver, Flashbots, BloXroute, ...) win most blocks; relay choice affects censorship-resistance and value capture.

For audit purposes, the relevant facts are:

• A transaction's ordering, not just its inclusion, can be bought.
• A transaction's exclusion from a block can also be effectively bought (by submitting bundles that don't include it).
• An MEV-aware adversary has substantial leverage over user transactions submitted to the public mempool.

Private Order Flow

A growing fraction of Ethereum transactions never touch the public mempool. They are submitted directly to specific builders or to private RPCs that forward them only to selected builders. Mechanisms include:

• Flashbots Protect: A drop-in RPC that submits user transactions privately to Flashbots and other compliant builders. The transaction is hidden from public searchers until it lands in a block (or expires). Defends against sandwich attacks and front-running.
• MEV-Share: A protocol that lets users selectively share parts of their transaction with searchers (e.g., the fact that a large swap is coming, without revealing the exact parameters), in exchange for a share of the MEV captured. The user's outcome is improved relative to public-mempool submission.
• MEV-Blocker: A similar service offered by BloXroute and used as the default RPC by many wallets.

For audited contracts, the implication is that the user's choice of submission channel is part of their MEV exposure. A contract design that requires public-mempool submission to function (because, e.g., a transaction must be observable before being executable) is structurally worse than one that works equally well via private channels.

What Auditors Should Internalize

When reviewing a contract:

• Assume any pending transaction is publicly visible. Anything that depends on calldata being secret until inclusion is broken by default.
• Assume an adversary can place a transaction immediately before or after any user transaction. Anything that depends on a specific ordering of transactions in the same block needs an explicit mechanism (commit-reveal, atomic transactions, MEV-aware design).
• Assume oracle updates and price changes can be sandwiched. Anything that observes a price and acts on it can be exploited by moving the price within the same block.
• Assume "first to call wins" is a competitive auction. Anything where the first caller earns a reward will be raced by searchers, with the actual gas paid to the validator approaching the reward.

These assumptions are not paranoid; they are the default operating environment for Ethereum L1 in 2026, and increasingly true on L2s as their sequencing decentralizes.