Consensus-Level MEV

The core mechanism enabling consensus-level MEV is the block proposer's right to determine the content of a new block. This includes the power to include, exclude, or reorder transactions. In Proof-of-Stake (PoS) systems, this right is assigned via a pseudo-random selection algorithm, making the proposer role a valuable, tradable asset. This is distinct from execution-level MEV, which focuses on ordering within a block's constraints.

A canonical example where a validator can reorg the chain to steal MEV. If a highly profitable arbitrage opportunity is included in a newly proposed block, a subsequent validator might intentionally fork the chain to create an alternative block that includes the same profitable transaction, capturing the value for themselves. This undermines chain finality and network security, demonstrating how MEV incentives can conflict with consensus stability.

A primary architectural solution designed to mitigate the centralizing forces of consensus-level MEV. PBS formally separates the roles of:

• Block Builder: Specialized entities that compete to construct the most profitable block content, including MEV.
• Block Proposer: The validator whose turn it is to propose a block, who simply selects the most valuable block from a public marketplace. This design aims to democratize access to MEV profits and reduce the incentive for validators to run sophisticated, centralized MEV operations.

A real-world, interim implementation of PBS used by Ethereum validators. MEV-Boost is middleware that allows a validator (proposer) to outsource block building to a competitive market. Relays are trusted intermediaries that receive blocks from builders and deliver them to proposers. This ecosystem enables validators to capture MEV rewards without being sophisticated builders themselves, though it introduces reliance on relay operators.

The planned protocol-level evolution of Proposer-Builder Separation, where the separation of roles is encoded directly into the blockchain's consensus protocol. ePBS aims to eliminate trust assumptions present in current middleware solutions (like MEV-Boost and relays), reduce latency, and provide stronger cryptographic guarantees about block validity and proposer payments. This is a long-term research and development goal for networks like Ethereum.

A critical distinction in the MEV landscape:

• Execution-Level MEV: Extracted by manipulating transaction order within a single block (e.g., frontrunning, backrunning, sandwich attacks). Handled by searchers and block builders.
• Consensus-Level MEV: Extracted by manipulating which block gets finalized or the block proposal process itself (e.g., time-bandit attacks, proposer rights). This directly involves validators and the consensus layer, posing a systemic risk to chain security and decentralization.

A reorg-based attack where a miner or validator intentionally rewrites blockchain history to capture MEV opportunities that existed in past blocks. The attacker mines a competing chain in secret, then releases it to orphan the canonical chain once their chain contains more profitable transactions (e.g., a large arbitrage). This undermines finality and user confidence.

• Mechanism: The attacker withholds a newly mined block, continues mining on top of it privately, and only broadcasts it if they can produce a longer chain that includes more valuable MEV.
• Impact: Creates chain instability and can revert user transactions that were previously considered confirmed.

Attacks that exploit the trust relationship or communication channels in Proposer-Builder Separation architectures, like Ethereum's post-merge design. While PBS aims to decentralize MEV, it creates new attack surfaces.

• Builder Censorship: A dominant builder can refuse to include certain transactions (e.g., OFAC-sanctioned addresses), enforcing transaction-level censorship.
• Out-of-Order Delivery: A malicious builder could send a block to the proposer at the last second, leaving no time for verification, potentially containing invalid transactions or stealing fees.
• MEV Theft: A malicious proposer could steal a block from a builder, view its profitable transaction ordering, and then re-mine it for themselves in a replay attack.

Attacks specific to Proof-of-Stake (PoS) systems where an attacker uses their staked capital to manipulate the leader election process or rewrite distant history.

• Stake-Grinding: An attacker uses computational power to influence or predict which validator will be the next block proposer, aiming to position themselves to propose blocks at times of high MEV opportunity.
• Long-Range Attack: An attacker acquires old validator private keys (e.g., from a past epoch) to create an alternative history of the chain from a point far in the past. This is mitigated by weak subjectivity checkpoints but remains a theoretical consensus-level threat.

An extreme attack where an attacker forces the reversal of a finalized block in a PoS system, which is designed to be irreversible. This requires coordinated action by a large portion (typically >33%) of the total staked ETH.

• Mechanism: A cartel of validators controlling a superminority of stake could intentionally vote to finalize two conflicting checkpoints, causing a finality stall. With control of >66% of stake, they could finalize an alternative chain, reverting transactions to capture massive, time-sensitive MEV.
• Barrier: Extremely costly due to the slashing penalties incurred by the attacking validators, making it economically irrational under normal conditions.

Vulnerabilities in the consensus client software (e.g., Prysm, Lighthouse, Teku) that can be exploited to disrupt block production or steal MEV. These are not theoretical protocol attacks but critical real-world risks.

• Example - The "Proposer Boost" Bug: A bug in an early Ethereum consensus client allowed a proposer to claim a higher reward for including an attestation, potentially disincentivizing honest block building.
• Impact: Such bugs can lead to chain splits, inactivity leaks, or allow a savvy attacker to gain an unfair advantage in block proposal, centralizing MEV capture.

The profitability of consensus-level MEV can incentivize validator centralization. Entities with large stakes can:

• Form proposer cartels to monopolize block proposals and extract MEV collaboratively.
• Outbid smaller validators for priority access to builder blocks, creating a wealth gap among validators.
• This undermines Proof-of-Stake security by increasing the economic incentive to control a supermajority of stake.

Validators with significant stake may attempt long-range reorganizations to rewrite history and capture massive, time-sensitive MEV (e.g., from an oracle update or large DEX trade). This attacks weak subjectivity and can lead to double-spends or settlement reversals on layer 2s, breaking fundamental security guarantees for users and applications.

The ecosystem is developing protocols to mitigate these risks:

• Enshrined PBS: Baking proposer-builder separation directly into the consensus protocol to reduce trust assumptions.
• Threshold Encryption: Using encrypted mempools (e.g., SUAVE) to hide transaction content until block publication, reducing frontrunning opportunities.
• Commit-Reveal Schemes: Hiding transaction details until they are committed to in a block.
• Fair Ordering Protocols: Consensus mechanisms that provide formal fairness guarantees against adversarial ordering.

A consensus architecture that decouples the roles of block building and block proposing. Block Builders compete to create the most profitable block, while Proposers (validators) simply select the highest-bidding header. This isolates validators from MEV extraction, reduces centralization pressure, and makes MEV revenue explicit and auction-based. A canonical example is Ethereum's implementation via MEV-Boost.

The evolution of PBS, where the separation of block building and proposing is formally encoded into the blockchain's consensus protocol itself, rather than being an off-protocol marketplace. This aims to provide stronger guarantees around censorship resistance, decentralization, and credible neutrality by removing reliance on external relay networks.

Consensus rules that mitigate MEV strategies relying on precise block timestamps. Examples include:

• Exponentially Weighted Moving Average (EWMA) Timestamps: Used by networks like Solana, this smooths timestamps to prevent validators from precisely controlling them for arbitrage.
• Bounded Timestamp Gaps: Protocols enforce strict limits on how much a block's timestamp can deviate from its predecessor, reducing the "time bandit" attack surface.

Reducing the time to finality—the point where a block is irreversible—directly shrinks the window for certain MEV attacks. Reorgs (chain reorganizations) are a primary vector for time-bandit and sandwich attacks. Protocols achieving finality in one slot (e.g., some Tendermint-based chains) or very quickly (e.g., Ethereum's single-slot finality roadmap) make these attacks economically non-viable.

Protocols that algorithmically define a fair transaction order to prevent frontrunning. Approaches include:

• Leaderless Consensus: In protocols like Avalanche, transactions are gossiped and voted on by all validators simultaneously, making it difficult for any single entity to control order.
• Deterministic Ordering Rules: Pre-defined rules (e.g., ordering by receive time or hash) that remove proposer discretion, though this can be challenging to implement without sacrificing performance.

A cryptographic approach where transactions are submitted to the mempool in an encrypted state. The encrypted transactions are included in a block proposal, and are only decrypted after the block is committed, using a threshold decryption scheme (e.g., requiring a committee of validators). This prevents searchers and builders from seeing transaction details in advance, neutralizing frontrunning and sandwich attacks at their source.

A protocol design that separates the roles of block building (selecting and ordering transactions) from block proposing (signing the block header). This is a primary architectural response to mitigate centralization risks from MEV. In PBS:

• Builders compete in a marketplace to create the most profitable block.
• Proposers (validators) simply choose the highest-paying block header.
• Enshrined PBS refers to implementing this separation directly in the consensus protocol, as opposed to a free-market implementation.

The dominant out-of-protocol implementation of Proposer-Builder Separation (PBS) on Ethereum. It is a middleware service that allows Ethereum validators (proposers) to outsource block construction to a competitive marketplace of specialized builders. Key aspects:

• Builders create full blocks and submit block bids to relays.
• Validators receive the header of the highest-bidding block via a relay.
• This allows validators to capture MEV rewards without needing sophisticated infrastructure, but introduces reliance on third-party relays and builders.

The competitive ecosystems where block builders source transactions and bid for the right to have their block included. This is the economic engine behind PBS designs.

• Transaction Flow: Searchers submit bundles of transactions to builders.
• Auction: Builders aggregate bundles, simulate outcomes, and submit a sealed bid to a relay or directly to the proposer.
• Payment: The winning builder's bid is paid to the block proposer. This creates a transparent market price for block space and MEV.

The integration of Proposer-Builder Separation directly into a blockchain's consensus protocol, as opposed to a voluntary, off-protocol middleware like MEV-Boost. Goals include:

• Reducing Trust Assumptions: Eliminating reliance on third-party relays.
• Censorship Resistance: Enforcing protocol-level rules for transaction inclusion.
• Efficiency: Potentially reducing latency and complexity.
• This is a major research direction for Ethereum post-merge, aiming to provide the benefits of PBS with stronger cryptographic and economic guarantees.

Protocol-level mechanisms designed to distribute the profits from MEV more evenly across all validators, rather than concentrating them on the proposer of a single lucky block. This mitigates validator reward variance and reduces centralization incentives.

• Examples: Proposer compensation from a common pool, or in-protocol payment of MEV rewards to future validators.
• Goal: To ensure the security and liveness of the consensus layer are not compromised by the "lottery" aspect of large MEV opportunities.

In consensus-level MEV, the physical constraints of network propagation become a critical attack vector and design consideration. Timing games occur when participants exploit differences in message arrival times.

• Examples: Latency arbitrage in PBS auctions, where a builder may delay sending a full block to gain an advantage.
• Impact: Can lead to centralization (proximity to relays) and network instability.
• Solutions: Protocols may enforce commit-reveal schemes or partial block reveals to neutralize latency advantages.