Block Builder

A builder aggregates transactions from multiple sources to maximize potential revenue. This includes:

• Public Mempool: The default, open pool of pending transactions.
• Private Order Flow: Direct deals with users or applications (e.g., via MEV-Boost relays) for exclusive access to high-value transactions.
• Cross-Chain Data: Monitoring related chains (like L2s) for arbitrage opportunities. Superior sourcing provides a larger, higher-quality transaction set for optimization.

The builder's core function is to order transactions within a block to extract maximum value, known as Maximal Extractable Value (MEV). This involves:

• Arbitrage: Reordering DEX swaps to capture price differences.
• Liquidations: Prioritizing liquidation transactions for fees.
• Frontrunning/Backrunning: Strategically placing transactions relative to anticipated user actions. Builders use sophisticated algorithms to solve this complex optimization problem, often simulating thousands of potential block layouts.

Builders compete in a sealed-bid auction to have their block accepted. They submit a block bid—a cryptographically committed promise of the block's contents and the payment to the validator—to a relay. Key aspects:

• Commit-Reveal Scheme: The builder commits to a block hash and bid value; the full block is revealed only after the validator selects it.
• Payment to Proposer: The bid is typically the priority fee (tip) from transactions plus a direct transfer from the builder's profits, paid to the validator for inclusion.

In Ethereum's Proposer-Builder Separation (PBS) model, builders do not communicate directly with validators. They rely on a relay, a trusted intermediary that:

• Hosts the Auction: Receives and validates bids from multiple builders.
• Ensures Censorship Resistance: Checks blocks for compliance with OFAC sanctions lists (a contentious role).
• Guarantees Delivery: Ensures the winning builder reveals its full block to the validator. Relays like Flashbots Protect, BloXroute, and Titan are critical infrastructure in this ecosystem.

Before submitting a bid, a builder must simulate the execution of its proposed block to ensure it is valid and profitable. This process:

• Prevents Invalid Bids: Checks for failed transactions, incorrect state changes, or exceeding gas limits.
• Estimates Profit: Accurately calculates the total MEV and fees extractable from the proposed ordering.
• Requires High Performance: Must be executed in milliseconds to compete in the high-frequency block auction. Failed simulations result in slashed bids or exclusion.

Winning the block auction is a race measured in milliseconds. A builder's success depends on low-latency infrastructure:

• Geographic Proximity: Servers located near major relays and validator pools.
• High-Performance Hardware: Optimized for rapid transaction processing and state simulation.
• Network Connectivity: Redundant, high-bandwidth connections to multiple mempools and relays. Latency advantages can determine which builder's bid is received and considered first by a relay.

A relay is a trusted intermediary that sits between searchers/builders and validators. Its primary functions are:

• Receiving blocks: Accepting block bids from multiple builders.
• Enforcing rules: Validating blocks for correctness (e.g., no MEV theft, valid signatures).
• Running an auction: Hosting a first-price sealed-bid auction where builders compete.
• Delivering the winner: Sending the highest-paying, valid block to the winning validator proposer.

Relays like Flashbots SUAVE, BloXroute, and Titan are critical infrastructure for censorship resistance and block diversity.

Builders compete in a first-price auction to have their block accepted by the validator. Their profit comes from maximizing Maximal Extractable Value (MEV). Key strategies include:

• Arbitrage Bundles: Capturing price differences across DEXs.
• Liquidations: Executing undercollateralized loan positions.
• Frontrunning & Backrunning: Strategically ordering transactions around large swaps.
• OFAC Compliance: Some builders may choose to censor transactions from sanctioned addresses to comply with regulations, a major topic in decentralization debates.

PBS is a design paradigm that separates the roles of block building (complex, resource-intensive) from block proposing (simple, consensus-critical).

• Builder Role: Specializes in creating high-value blocks using sophisticated algorithms and private transaction pools (mempools).
• Proposer Role: The validator simply chooses the highest-paying valid block from the relay.

This separation aims to democratize access to block production and reduce the centralizing pressure of MEV on validators. Ethereum's roadmap formalizes PBS through ePBS (enshrined PBS).

Several entities dominate the block builder landscape, operating sophisticated infrastructure:

• Flashbots Builder: The original and one of the largest, part of the SUAVE ecosystem.
• rsync-builder: A major builder known for high performance and reliability.
• Titan Builder: Associated with the Titan relay, emphasizing robust delivery.
• bloXroute Max Profit Builder: From the bloXroute network, focusing on MEV optimization.

These builders typically command over 90% of Ethereum block space, highlighting the concentration in this layer.

Searchers are independent agents who identify profitable MEV opportunities. They submit transaction bundles to builders, not directly to the public mempool. The relationship is symbiotic:

• Searchers provide the "raw material" (profitable bundles).
• Builders aggregate, simulate, and optimize these bundles into a complete, valid block.
• Payment Flow: The builder pays the searcher a portion of the MEV profit (minus a fee) by including their bundle, and then the builder's total block bid goes to the proposer.

The builder market is highly concentrated, posing risks:

• Censorship: A few dominant builders could refuse to include certain transactions.
• Collusion: Builders could form cartels to lower bids paid to proposers.
• Failure Risk: Reliance on a few infrastructure points creates systemic fragility.

Proposed solutions include:

• Enshrined PBS (ePBS): Building PBS directly into the protocol.
• Builder Override Mechanisms: Allowing proposers to modify or reject builder blocks under specific conditions.
• Decentralized Builder Networks: Efforts to create permissionless, open builder networks.

Block builders have privileged access to the mempool and can reorder, include, or exclude transactions to capture Maximal Extractable Value (MEV). This creates a profit incentive for sophisticated, centralized builders with advanced algorithms, leading to a concentration of block production power. The most profitable builders can outbid others, creating a feedback loop that centralizes the builder market.

A dominant block builder can censor transactions by refusing to include them in blocks. This poses a significant risk to network neutrality and can be used for regulatory compliance or targeted attacks. Solutions like crLists (censorship-resistant lists) and proposer-builder separation (PBS) aim to mitigate this by giving validators (proposers) a way to force the inclusion of certain transactions.

PBS is a design paradigm that formally separates the role of the block proposer (validator) from the block builder. It aims to:

• Reduce centralization pressures on validators by outsourcing complex block construction.
• Democratize MEV by creating a competitive builder market.
• Enhance censorship resistance through cryptographic commitments. In PBS, builders bid for block space in a builder market, and the proposer simply selects the most profitable header.

A small number of dominant block builders can form cartels to:

• Fix bidding prices in the builder market.
• Exclude competing builders.
• Enforce transaction censorship policies across the network. This undermines the competitive market PBS intends to create and can lead to systemic risks if the cartel controls a supermajority of block production.

In PBS implementations, relays are trusted intermediaries that receive blocks from builders and forward them to proposers. They prevent proposers from stealing block contents. However, reliance on a few major relays (like the Flashbots Relay) creates a central point of failure and censorship. If a relay goes offline or becomes malicious, it can disrupt block production for a large portion of the network.

The ecosystem is developing protocols to counter centralization:

• Enshrined PBS: Building separation directly into the protocol consensus to eliminate trusted relays.
• SUAVE: A decentralized block builder and MEV marketplace.
• Threshold Cryptography: Using distributed key generation to decentralize trust in relays.
• Permissionless Builder Requirements: Ensuring builders cannot be easily excluded from the market.