How to Implement a Proposer-Builder Separation (PBS) Framework

Proposer-Builder Separation (PBS) is a blockchain architecture that decouples the role of block proposer from block builder to enhance decentralization and censorship resistance. In a PBS framework, specialized builders compete in an open market to construct the most valuable blocks, while validators (proposers) simply select the most profitable header. This separation mitigates centralization risks like MEV extraction by individual validators and creates a more specialized, competitive ecosystem. The primary goal is to prevent the consolidation of block production power, a critical concern for networks like Ethereum post-Merge.

Implementing PBS requires designing three core components. First, a builder network where entities construct blocks by aggregating transactions and MEV opportunities. Second, a relay—a trusted intermediary that receives blocks from builders, validates them, and forwards headers to proposers. Third, the proposer software itself, which must be modified to receive block headers from a relay instead of constructing blocks locally. The communication between these components typically uses a standard API, with Ethereum's current implementation relying on the builder-specs repository for specifications.

The builder's role is to create the most valuable block possible. This involves running a MEV-Boost-compatible client, sourcing transactions from the public mempool and private order flows (e.g., via Flashbots), and optimizing for maximum total value. Builders submit their complete blocks to a relay. The relay performs critical duties: it attests to the block's validity, ensures payment to the proposer is available, and maintains a cancellation list to prevent certain transactions from being included. Proposers run modified consensus clients that connect to one or more relays to receive block header bids.

For a practical implementation, a proposer would configure software like Lighthouse or Teku to connect to a relay using the Ethereum Builder API. The key step is setting the --builder and --builder-relay flags to enable external block production. Builders, on the other hand, implement the builder API endpoint and integrate with an execution client (like Geth) and an MEV strategy engine. Code examples for a simple builder might involve constructing a block payload using the Engine API and submitting it via a POST request to a relay's /relay/v1/builder/blocks endpoint.

Key design considerations include trust assumptions about the relay, builder reputation systems, and censorship resistance. While relays are currently trusted not to censor or steal blocks, longer-term solutions like enshrined PBS aim to minimize this trust. Implementing a local block-building fallback is also crucial for network health, ensuring the proposer can produce a block if the relay fails. Monitoring metrics like bid acceptance rate, relay latency, and builder market share is essential for maintaining a robust and decentralized PBS ecosystem.

The first prerequisite is a robust relay. This is a trusted, neutral service that sits between builders and proposers. Its primary functions are to receive sealed bids from builders, run a fair auction, and deliver the winning block header to the selected proposer. The relay must be built with high availability and censorship resistance in mind. For implementation, you can study the open-source code of established relays like the Flashbots Relay or the bloxroute Gateway. These handle critical tasks like validating builder signatures, checking block validity, and ensuring timely delivery.

You also need a builder ecosystem. Builders are specialized entities that construct full blocks by sourcing transactions from the mempool and private order flow. To implement a builder, you'll need deep expertise in MEV (Maximal Extractable Value) strategies, transaction simulation, and block gas optimization. Builders typically run modified Ethereum clients like mev-geth or mev-boost-compatible software. They submit bids to the relay, which include a block header and a commitment to pay the proposer. The builder's software must handle complex tasks like bundle merging and backrunning arbitrage opportunities.

The proposer side requires integration with consensus client software. Proposers (validators) must run middleware that connects their validator client to the relay. For Ethereum, this is the mev-boost software. It allows a validator to outsource block building by receiving a header from the relay, verifying the associated payment, and signing it. Implementing this requires configuring your validator to point to one or more trusted relays and understanding the signing process for ExecutionPayloadHeader objects. The security of the proposer's private key is paramount throughout this process.

A critical, often overlooked prerequisite is a clear legal and operational framework. PBS involves transferring significant value (block rewards and MEV) through external channels. You must establish transparent operational procedures, define slashing conditions for relay or builder misbehavior, and create a robust governance model for upgrading the system. This includes planning for in-protocol PBS (e.g., Ethereum's ePBS roadmap) and ensuring your current implementation is adaptable to future protocol changes without disrupting the validator set.

Finally, comprehensive monitoring and analytics are non-negotiable. You need systems to track key metrics: relay latency, builder market share, bid censorship rates, and validator participation. Tools like the Flashbots MEV-Boost Dashboard or building custom metrics with Prometheus and Grafana are essential. This data is crucial for detecting network attacks, ensuring the health of the auction, and providing transparency to participants about the fairness and efficiency of the PBS ecosystem you are implementing.

Proposer-Builder Separation (PBS) is a trust-minimizing architecture that decouples block production from block proposal on Ethereum. In this model, specialized block builders compete to construct the most valuable blocks, while validators (proposers) simply select the highest-bidder's block via a trusted relay. This separation mitigates centralization risks and MEV extraction by validators, creating a more specialized and competitive market. The core components are the builder, which creates blocks and submits bids, and the proposer, which signs a header commitment for the winning bid.

To implement a PBS framework, you must first understand the builder API specification. Builders construct blocks by bundling transactions, including private orderflow and MEV opportunities, and submit execution payloads with bids to relays. The key endpoint is getHeader, where the builder returns a SignedBuilderBid containing the block header, value, and a signature. Proposers interact via the Builder API on a relay, calling getHeader to receive the best bid and submitBlindedBlock to reveal and publish the full block. The communication flow is standardized in EIP-4337's bundler specification and the Flashbots MEV-Boost relay implementation.

A critical implementation step is integrating with a trusted relay, which acts as an intermediary to prevent proposers from stealing block content. Relays like Flashbots, BloXroute, and Agnostic validate builder submissions and attest to their availability. For a proposer, integration typically involves running MEV-Boost middleware alongside your consensus client. This software connects to multiple relays, auctions the block space, and forwards the winning blinded block to your execution client. Builders must implement the server-side Builder API, often using frameworks like mev-rs or mev-boost-rs, and develop strategies for sourcing and optimizing transaction flow to maximize bid value.

Builders generate revenue through Maximal Extractable Value (MEV). This involves identifying and capturing value from transaction ordering, such as arbitrage, liquidations, and NFT minting. Advanced builders use private mempools (e.g., Flashbots Protect, Taichi Network) to receive orderflow and sophisticated simulation engines to test bundle profitability without risking on-chain failure. A builder's competitive edge comes from its ability to source exclusive transactions and optimize gas usage to fit more value into a single block. The bid submitted to the relay is the total value (block reward + priority fees + MEV) the builder is willing to pay the proposer.

For proposers, implementing PBS is primarily about security and relay selection. You must configure MEV-Boost with a set of trusted, reputable relays to mitigate censorship and ensure block availability. The proposer's role is reduced to signing the header of the highest-value block, as they never see the transaction details until after commitment. This requires a validator client modification to support blinded blocks, which is now standard in clients like Teku, Lighthouse, and Prysm. Proposers should monitor relay performance and uptime, as a relay failure could result in a missed block proposal opportunity.

The future of PBS is enshrined in Ethereum's protocol with ePBS (enshrined Proposer-Builder Separation). Current implementations like MEV-Boost are considered "in-protocol PBS" and rely on external trust assumptions. ePBS aims to bake the separation and auction mechanism directly into the consensus layer, further reducing trust and complexity. Developers building today should design with this evolution in mind, ensuring their systems are adaptable to coming protocol changes. The core principles of specialized roles, competitive bidding, and trust-minimized relay logic will remain central to Ethereum's scaling and decentralization roadmap.

Proposer-Builder Separation (PBS) is a blockchain design pattern that decouples the roles of block proposal and block building. In a PBS framework, validators (proposers) outsource block construction to specialized actors called builders. Builders compete in a sealed-bid auction for the right to have their block included by the proposer. This separation addresses centralization risks in MEV extraction and creates a more efficient, competitive market for block space. Ethereum's adoption of PBS via mev-boost is the canonical example, but the principles apply to any chain seeking to manage MEV.

The core of a PBS implementation is the block auction mechanism. Proposers run a relay, which acts as a trusted intermediary. Builders submit complete, signed block headers (SignedBuilderBid) to the relay. The relay validates these bids—checking the builder's signature, the block's validity, and payment to the proposer—before forwarding them. The proposer selects the header with the highest bid, often just the highest value field denominated in the native token. This process must complete within the tight constraints of a slot (12 seconds on Ethereum), requiring highly optimized networking and validation logic.

Builders are the engine of the system. A builder's job is to construct the most valuable block possible by aggregating user transactions and MEV opportunities (like arbitrage or liquidations). They use sophisticated algorithms to search the mempool and private order flows. The builder's bid includes the block header and a commitment to pay the proposer. Implementation requires a secure signing setup, as the builder must sign the bid without knowing if they will win the auction. Code for a simple builder might involve listening for auction requests, constructing a block using an execution client's API, and submitting the bid to a known relay.

The relay must be implemented for security and neutrality. It attests to the validity of the builder's block body and ensures the proposer receives payment. A critical relay function is payload disclosure: after the proposer commits to a header, the relay must provide the corresponding full block body. Relays like the Flashbots Relay or boost-relay open-source software handle this, along with censorship resistance lists (crLists). When implementing a relay, data availability and DoS protection are primary concerns, as it becomes a critical, high-throughput piece of infrastructure.

For a proposer (validator) to participate, they must run client software that connects to one or more relays. The proposer's client receives bids via an API endpoint (e.g., GET /eth/v1/builder/header/{slot}/{parent_hash}/{pubkey}). It selects the most profitable valid header, signs it, and returns it to the relay. The subsequent block submission flow is crucial: the proposer receives the full block body from the relay and publishes it to the network. This requires integration between the validator client, the consensus client, and the relay network, typically managed by middleware like mev-boost.

Implementing PBS introduces new trust assumptions and complexities. Proposers must trust relays to deliver valid block bodies. The system can be made more trust-minimized with enshrined PBS at the protocol level, using cryptographic commitments. For a practical start, examine the mev-boost Go implementation, the flashbots/boost-geth builder, and the flashbots/mev-boost-relay codebases. Testing on a devnet or a testnet like Goerli is essential to validate the entire auction, bidding, and block propagation flow before mainnet deployment.

Proposer-Builder Separation (PBS) is a protocol design that decouples the roles of block proposal and block construction. In Ethereum's post-Merge landscape, validators (proposers) outsource block building to specialized entities called builders. Builders compete in a sealed-bid auction, submitting their most profitable block (the execution payload) and a bid to a trusted relay. The winning builder's payload is then proposed by the validator. This guide outlines the core components for implementing a competitive builder.

A builder's primary function is to construct the most valuable block possible from the mempool. The architecture typically involves: a Transaction Pool (mempool) listener, a Block Simulation Engine, a Bid Optimization algorithm, and a Relay Interface. The builder must connect to a high-performance Ethereum execution client (like Geth or Erigon) to access the state and simulate transactions. It listens for new transactions via a mempool API or a P2P network, constantly updating its local view of pending transactions.

The optimization engine is the builder's core. It must solve a complex problem: selecting a set of transactions that maximizes the total value to the builder, typically the sum of priority fees (tips), while respecting block gas limits and ensuring state transitions are valid. This involves running simulations to estimate gas usage and profitability. Advanced builders use sophisticated algorithms like knapsack solvers or greedy heuristics to construct blocks. The output is a complete ExecutionPayload, as defined in the Ethereum Engine API specification.

Once a block is built, the builder must submit it to one or more relays. The submission is a builder bid, containing the ExecutionPayload and a bid value (in wei) payable to the proposing validator. This is signed with the builder's private key. The bid is submitted via the relay's REST API using the eth_sendBuilderBid endpoint. Builders often connect to multiple relays (like Flashbots, bloXroute, Eden) to maximize their chances of winning auctions and to promote censorship resistance.

Implementing a builder requires careful handling of MEV (Maximal Extractable Value). Builders can extract value through arbitrage, liquidations, and NFT frontrunning by including proprietary bundles. These bundles, often received from searchers, contain transactions with conditional execution logic. The builder must integrate a bundle merging system to combine external bundles with the public mempool, ensuring no conflicts and maximizing overall revenue. Failing to handle MEV effectively will render a builder uncompetitive.

Key operational considerations include latency and reliability. The block construction and bidding process must complete within the ~12-second slot time. This demands low-latency infrastructure and efficient code. Builders must also manage their balance on the beacon chain to cover bid payments. Finally, staying compliant with evolving PBS standards, such as those proposed for ePBS (enshrined PBS), is crucial for long-term viability. The builder ecosystem is a high-stakes, performance-critical component of modern Ethereum.

Proposer-Builder Separation (PBS) is a critical architectural shift for Ethereum, designed to mitigate centralization risks in block production. The core concept separates the role of the block proposer (a validator) from the block builder (a specialized entity). Builders compete in a marketplace to create the most profitable block by including transactions and MEV, while proposers simply select the highest-value block header offered to them via a relay. This separation prevents validators from being forced to run complex, centralized MEV extraction operations, promoting a more decentralized and resilient network. The in-protocol version, ePBS, is planned for a future upgrade, but the current out-of-protocol model relies on the mev-boost middleware.

Implementing a PBS framework requires integrating three main components: a builder, a relay, and a proposer client. The builder is responsible for constructing execution payloads. It listens for transactions from the public mempool and private order flows, simulates execution, and creates optimized block bundles. These bundles are then submitted to one or more relays. The relay acts as a trusted intermediary, receiving blocks from builders, validating them (checking signatures, ensuring payment to the proposer), and maintaining a censorship-resistant marketplace. Proposers connect to relays via mev-boost to receive header bids.

For builders, the primary implementation task is creating software that interfaces with the relay API. A builder must generate a SignedBuilderBid, which includes the block header, execution payload, and a commitment to pay the proposer. The key endpoints are getHeader (for providing the bid to the relay) and submitBlindedBlock (for receiving the full block data after a bid is won). Builders often use sophisticated algorithms for transaction ordering and MEV extraction (e.g., arbitrage, liquidations) to maximize block value. Open-source references include the flashbots/builder and blockscout/builder implementations on GitHub.

Relay implementation is more complex due to its critical trust role. A relay must validate builder submissions to ensure correctness and safety before forwarding them to proposers. This includes verifying the builder's signature, ensuring the execution payload is valid, and confirming the promised payment to the proposer is included. Relays also must be highly available and resistant to censorship. The official specification is defined in the Builder API (REST) and Relay API (over HTTPS). The flashbots/mev-boost-relay repository provides a production-grade reference implementation, handling bid aggregation, data availability, and proposer registration.

Proposer integration is the most common use case, achieved through mev-boost. A validator operator runs mev-boost alongside their consensus and execution clients. mev-boost connects to a list of trusted relays (e.g., https://relay.flashbots.net). When it's the validator's turn to propose a block, mev-boost requests header bids from all connected relays, selects the one with the highest value, and forwards it to the validator client. If the bid is selected, mev-boost then requests the full block from the winning relay. Configuration involves setting the MEV_BOOST_RELAYS environment variable and ensuring proper JWT authentication between clients.

Key considerations for a production PBS implementation include relay trust assumptions, latency, and fallback mechanisms. Proposers must trust that relays will not censor transactions or deliver invalid blocks. Using multiple relays from different providers mitigates this risk. Network latency between the builder, relay, and proposer is crucial, as the entire bidding process must complete within the 12-second slot time. Builders and proposers should also implement fallback logic to propose a locally built block if mev-boost or relay connections fail, ensuring the validator does not miss a proposal opportunity and incur an inactivity penalty.

Proposer-Builder Separation (PBS) restructures the block production process in proof-of-stake (PoS) systems like Ethereum. It splits the role of the block proposer from the block builder. The proposer, a validator selected by the consensus protocol, is responsible for including the highest-value block they receive. The builder is a specialized entity that constructs blocks by aggregating transactions and extracting Maximal Extractable Value (MEV). This separation prevents validators from needing sophisticated MEV capabilities, reducing centralization pressures and creating a more competitive builder market.

The primary mechanism for implementing PBS is through a commit-reveal scheme using a builder marketplace. Builders compete in a sealed-bid auction for the right to have their block included. They send a SignedBuilderBid to a relay, which contains the block header and a commitment to pay the proposer. The proposer selects the most profitable bid and signs a SignedBlindedBeaconBlock, which is a block header without the transaction body. The builder then reveals the full block to the relay, which forwards it to the proposer for inclusion in the chain. This process is currently facilitated by MEV-Boost middleware for Ethereum validators.

Key Technical Components

To integrate PBS, you must implement or interface with several core systems. The Builder API allows builders to receive transaction flow and submit bids. The Relay acts as a trusted intermediary, receiving bids from builders and blinded blocks from proposers, ensuring data availability and censorship resistance. Validator client software must be modified to connect to relays and handle the new message types defined in Ethereum's Builder Spec (e.g., getHeader, getPayload). This requires updating the beacon node and validator client interaction.

Here is a simplified code snippet illustrating how a proposer client might interact with a relay to get a blinded block header:

pythonCopy
# Pseudocode for proposer-side header request
import requests

def fetch_best_header(relay_url, slot, parent_hash, pubkey):
    payload = {
        "slot": slot,
        "parent_hash": parent_hash,
        "pubkey": pubkey,
        "gas_limit": 30000000
    }
    response = requests.post(f"{relay_url}/eth/v1/builder/header", json=payload)
    if response.status_code == 200:
        signed_builder_bid = response.json()
        # Verify signature and evaluate value
        return signed_builder_bid
    return None

This function queries a relay for available block headers at a given slot, which the proposer then evaluates based on the attached execution payload value.

Implementing PBS introduces new security considerations. Proposers must trust relays not to censor transactions or provide invalid blocks. In-protocol PBS (e.g., via crLists or a direct inclusion list) is the long-term solution to minimize this trust. Builders must ensure their blocks are available, meaning the full transaction data is published. The integration also changes slashing conditions; proposers are slashed for signing conflicting blinded blocks, while builders risk losing their bid for non-compliance. Thorough testing on testnets like Holesky or Sepolia is essential before mainnet deployment.

The future of PBS is its formalization within the Ethereum protocol itself. Proposals like EIP-7547 (Inclusion Lists) and EIP-7251 (Increase Max Effective Balance) pave the way for enshrined PBS, where the auction and commitment logic is part of the consensus layer. This eliminates reliance on external relays, further enhancing decentralization and censorship resistance. For now, using the MEV-Boost software suite provides a practical path to participate in the PBS ecosystem, allowing validators to capture MEV rewards while contributing to a healthier network structure.

Implementing PBS fundamentally restructures block production. You have learned to architect the key roles: the block proposer (e.g., a validator) that selects the highest-value block header, and the block builder that constructs the full block content in a competitive, off-chain marketplace. The separation is enforced through a commit-reveal scheme using a builder API and a relay to prevent censorship and MEV extraction by proposers. Your implementation should use standardized interfaces like those defined by Ethereum's Builder API spec to ensure compatibility with the broader ecosystem.

For next steps, focus on testing and integration. Begin by running a local testnet with a modified consensus client (like Lighthouse or Prysm) configured to outsource block building. Use a development relay such as the one provided by Flashbots to simulate the builder marketplace. Monitor key metrics: bid inclusion rate, block value captured, and latency between bid receipt and block proposal. This testing phase is crucial for identifying bottlenecks in your builder's block construction algorithms or your proposer's bid evaluation logic.

To advance your implementation, explore active research areas. MEV-Boost is the live PBS implementation on Ethereum, and studying its open-source code is invaluable. Investigate builder reputation systems to mitigate trust assumptions in relays. Furthermore, consider the endgame of Enshrined PBS, where protocol-level commits replace external relays. Your foundational work now positions you to contribute to or adapt to these evolving standards, which are essential for the sustainable and fair operation of high-throughput blockchains.