Mempool Reordering and Censorship

The mempool is often treated as a queue. It is not. It is a competitive arena where block builders, validators, and network adversaries race to control ordering. This note covers the attacks we look for when reviewing the transaction propagation layer of a Layer-1 protocol.

Basic reordering

A validator with proposer rights can order transactions arbitrarily within a block. If the protocol does not enforce a deterministic order — such as a canonical ordering by hash or arrival time — the proposer can:

• Insert their own transactions ahead of profitable ones.
• Delay transactions that would close a liquidation or arbitrage opportunity.
• Bundle related transactions to capture value that rightfully belongs to users.

Even without direct profit, the ability to reorder breaks the implicit promise that the mempool is fair.

Fee manipulation

Fee-based mempools introduce a bidding war. A sophisticated attacker can:

• Front-run by observing a pending transaction and submitting the same transaction with a higher fee.
• Back-run by placing a transaction immediately after a target transaction to capture its side effects.
• Spam the mempool with low-value transactions to raise the fee floor and price out honest users.
• Pretend to be a builder and collect bundles without committing to include them, gaining free order-flow intelligence.

Network-layer censorship

An attacker that controls enough P2P relays can selectively delay or drop transactions from specific senders or to specific contracts. This is not a consensus failure; it is a liveness failure for the affected users. Detection is difficult because the transaction may simply appear to have low priority rather than having been blocked.

We test for this by running a “censorship oracle”: a set of geographically distributed senders submit identical transactions to the network and report inclusion times. A statistically significant deviation in inclusion latency for one sender or contract type is evidence of censorship.

Block builder interfaces

Modern protocols separate block builders from block proposers. The interface between them is a new attack surface. We review:

• Bundle validity rules. Can a builder force a proposer to include an invalid bundle, or exclude a valid one?
• Payment enforcement. Are builder payments conditional on inclusion, or can they be extracted without committing?
• Privacy leakage. Does the builder learn about pending transactions before the proposer does?
• Timeout games. Can a proposer wait until the last millisecond to reveal its choice, disadvantaging builders?

Mitigations

• Canonical ordering. A deterministic, hard-to-game ordering rule removes a large class of reordering attacks.
• Encrypted mempools. Encrypting transactions until they are included prevents front-running based on transaction content. The trade-off is latency and complexity in decryption.
• Fair ordering protocols. Commit-reveal or threshold decryption schemes can enforce a fair sequence.
• Inclusion lists. Requiring the proposer to include a baseline set of user transactions limits censorship.
• Monitoring and slashing. Penalise proposers and builders that consistently deviate from expected inclusion patterns.

Closing note

Mempool attacks are profitable even when the protocol is perfectly correct. The incentives are the bug. A security review that ignores the mempool is like a bank audit that never checks the lobby.