Proposer-Builder Separation (PBS) Explained

Proposer-Builder Separation (PBS) is an Ethereum block-production design in which one participant proposes a block and another constructs it. The split matters because block construction has become a specialized market: builders combine transactions and searcher bundles to maximize value, while validators need a way to earn competitive rewards without running every piece of block-building infrastructure themselves. This explainer covers the problem PBS addresses, the current MEV-Boost architecture, the trade-offs of relay-based separation, and what protocol-native PBS would change.

What is Proposer-Builder Separation?

In a traditional block-production model, the validator that proposes a block also chooses the transactions, orders them, executes them, and signs the result. PBS separates those responsibilities:

• Builders collect transactions and bundles, simulate candidate blocks, and construct the most valuable valid execution payload.
• Proposers are the validators selected to propose the next block. They choose a builder bid and publish the block to the network.
• Relays connect builders and proposers in the current out-of-protocol design. A relay checks a builder’s payload, holds it behind a commitment, and forwards a bid before revealing the full block.

The Ethereum documentation on maximal extractable value describes why transaction ordering creates economic opportunities. PBS does not remove that value. Instead, it creates a market around block construction and gives the proposer a mechanism to select the most valuable valid offer without independently searching every transaction opportunity.

The separation is currently implemented primarily through MEV-Boost, rather than as a complete rule enforced by Ethereum consensus. The Flashbots MEV-Boost introduction documents this middleware-based model, while Flashbots provides the broader research and infrastructure context around MEV markets. See MEV-Boost and Ethereum block auctions for a practical view of the proposer-side auction and monitoring flow.

The Problem PBS Solves

Proof-of-stake validators have a limited time window to produce a block. If every validator must independently run sophisticated searcher, simulation, and optimization infrastructure, block production becomes expensive and operationally complex. The result can be a competitive disadvantage for solo stakers and a drift toward large operators with dedicated MEV teams.

There is also a direct incentive problem. A validator that sees a profitable transaction bundle while building locally may be tempted to copy it, reorder it, or delay other transactions. Searchers and builders need a way to submit valuable order flow without giving the proposer an opportunity to take the strategy before committing to a bid.

PBS addresses these pressures by turning block construction into a competitive service. Builders compete to offer a proposer a payment for the right to supply a block. The proposer can select the highest valid bid, while the builder takes responsibility for finding and assembling the transactions that make the block valuable. Competition can improve validator rewards and reduce the amount of specialized infrastructure each validator must operate.

This is not a guarantee of fairness. Builders can still censor transactions, concentrate market power, or prioritize profitable order flow. Relays can fail or impose policies. PBS changes where decisions and trust sit; it does not make transaction ordering neutral by itself.

How PBS Works

The current Ethereum flow is easiest to understand as a sequence of commitments:

1. Searchers identify opportunities and send transaction bundles to builders.
2. Builders combine bundles with public transactions and construct candidate execution payloads.
3. Each builder sends a bid describing the value it will pay and a block header or block hash committing to the payload.
4. A relay validates the builder’s submission and presents the proposer with bids from multiple builders.
5. The proposer chooses a bid and signs a blinded block. At this point, the proposer has committed to the selected payload without needing its complete transaction list.
6. The relay reveals the full execution payload. The proposer publishes the completed block, and other nodes verify it like any other block.

The important security property is the commitment before disclosure. A builder should not be able to change the payload after winning, and a proposer should not be able to inspect and steal a valuable bundle before choosing the bid. The relay is responsible for checking that the header corresponds to a valid payload and that the bid can be honored.

PBS therefore creates a supply chain with distinct responsibilities:

users and public mempool
          |
          v
searchers ---- private bundles ----> builders
                                      |
                                      | bid + committed payload
                                      v
                                  relays
                                      |
                                      | sealed bids
                                      v
                              proposer / validator
                                      |
                                      | signed block
                                      v
                              Ethereum network

This flow is related to, but different from, rollup sequencing. A rollup sequencer orders transactions for an execution environment before posting data or proofs to a settlement layer. PBS separates Ethereum base-layer block construction from block proposal. Both designs treat ordering as a specialized systems problem, but they operate at different layers.

Architecture and Key Components

Builders

Builders are specialized block producers. They receive public transactions, private order flow, and searcher bundles, then simulate combinations to construct a valid payload with a high total value. Their edge comes from infrastructure: low-latency networking, high-throughput simulation, access to order flow, and algorithms that evaluate many possible transaction orderings.

A builder’s bid is not simply a gas-price total. It represents the amount the builder can pay the proposer after accounting for transaction fees, bundle payments, execution costs, and the builder’s own margin. The builder must also produce a payload that passes execution and consensus validation.

Proposers

The proposer is the validator selected by proof-of-stake consensus for a slot. Its job in a PBS flow is to compare valid bids, select one according to its local policy, sign the corresponding block, and broadcast it within the slot deadline. If no builder bid is available or usable, the validator can fall back to building a block locally.

The proposer still carries important responsibilities. It must protect signing keys, enforce bid and payload checks, maintain reliable connectivity, and avoid missing the slot while waiting for an external builder or relay. Higher revenue is useful only if the added dependencies do not create unacceptable downtime or censorship exposure.

Relays

Relays are intermediaries in the out-of-protocol MEV-Boost design. They receive builder payloads, verify them, and send the proposer a signed bid and commitment. When the proposer selects the bid, the relay supplies the payload needed to complete the block.

This makes relays a meaningful trust and availability boundary. A relay may become unavailable, delay a response, censor a payload, or apply a policy that affects transaction inclusion. Validators commonly configure multiple relays to increase competition and reduce dependence on one operator, although relay diversity cannot eliminate every correlated failure.

Searchers and order flow

Searchers are not part of the consensus protocol, but they are central to the economics around PBS. They monitor state and pending transactions to find arbitrage, liquidations, backruns, and other opportunities. A searcher may send a bundle to one or more builders, with conditions that require transactions to execute in a particular order or all succeed together.

The market is therefore shaped by who can access order flow. Builders with better information or lower latency may win more auctions, which can improve bids in the short term but also encourage concentration over time.

PBS Design Trade-offs

“Enshrined PBS” refers to putting more of the separation directly into the Ethereum protocol. EIP-7732 is a standards proposal for enshrined proposer-builder separation. A proposal is not the same as a deployed network rule, so operators should distinguish the current MEV-Boost implementation from possible future consensus changes.

Real-World Uses

PBS is most visible in Ethereum validator operations and MEV markets. A validator can run a consensus client, an execution client, and MEV-Boost, then connect to several relays. When the validator is selected to propose, it can compare builder bids instead of relying only on the value it can discover locally.

The design is also useful for understanding validator economics. Builders can invest in high-performance simulation and private order flow once and compete for many proposal slots. Proposers can participate in that market without each becoming a professional trading or block-optimization operation. The resulting payments can increase validator rewards, but the distribution depends on builder competition, relay policies, and the quality of available order flow.

PBS also informs the design of rollups, appchains, and shared sequencing systems. These systems may use separate roles for ordering, execution, proving, and settlement. The precise trust model differs, but the same question appears repeatedly: which component chooses transactions, which component constructs the executable batch, and what prevents either one from changing the result after a commitment?

Getting Started: Evaluating a PBS Setup

A validator operator should treat MEV-Boost as production infrastructure, not as a single command that can be enabled without monitoring. Start by confirming that the consensus client, execution client, and MEV-Boost versions are compatible. Then configure multiple reputable relay endpoints and retain local block-building fallback.

A minimal installation and health-check sequence may look like this:

# Install or download the MEV-Boost release using your platform's package process.
mev-boost --version

# Confirm the local builder API is responding.
curl --fail http://127.0.0.1:18550/eth/v1/builder/status

# Inspect the available command-line options before configuring relays.
mev-boost --help

The exact relay list is network-specific and should be taken from current operator documentation. A production configuration should verify relay signatures, use the correct network flag, set a response timeout that leaves time for block publication, and avoid treating one relay as an availability guarantee.

Useful operational checks include:

• compare the number and value of received bids with locally built blocks;
• alert on relay timeouts, payload reveal failures, and missed slots;
• monitor whether one relay or builder dominates the validator’s selections;
• verify that the validator can produce a local block if external bids are unavailable;
• review relay policies and the effect they have on censorship and inclusion.

PBS is not a replacement for normal validator security. Keep signing keys isolated, patch clients through a controlled process, and test fallback behavior on a non-production network before changing mainnet settings.

Common Misconceptions

“PBS removes MEV.”

No. PBS organizes the market for block construction and changes who captures and distributes MEV. Arbitrage, liquidations, and ordering-dependent strategies still exist, and builders compete to capture their value.

“The proposer never sees the block.”

The proposer does not need to see the complete payload before committing to a bid, but the payload is revealed before the completed block is published and is verified by the proposer and the network. PBS limits premature access; it does not hide the final block.

“MEV-Boost is the same as enshrined PBS.”

MEV-Boost is an out-of-protocol middleware implementation that uses relays. Enshrined PBS would make more of the role separation and validation rules part of Ethereum consensus. The two approaches share goals but have different trust assumptions and upgrade paths.

“The highest bid should always be selected.”

The highest advertised value is useful only if the bid is valid, the payload can be revealed on time, and the relay and builder meet the operator’s policy requirements. A validator may prefer a slightly lower bid from a more reliable or acceptable source, depending on its configuration and risk model.

Related Articles

• MEV (Maximal Extractable Value) Systems
• Blockchain Consensus Mechanisms Explained
• Sequencers: How Rollups Order Transactions
• Shared Sequencers
• Modular Blockchains

PBS is best understood as an economic and operational boundary around block production. Builders specialize in finding and assembling value, proposers retain the right to publish a block, and relays coordinate the current handoff. The design can improve competition and validator participation, but it must be evaluated alongside relay concentration, censorship, latency, and the complexity introduced by moving block construction outside the proposer.