The Transaction Pipeline

In PBS 101 we introduced proposer-builder separation and the key participants: validators, builders, searchers, and relays. Here we look at how they connect into an end-to-end pipeline, the out-of-protocol infrastructure that turns a transaction into a block.

The chain runs: Users -> Private RPCs -> OFAs -> Searchers -> Builders -> Relays -> Proposers.

When you send a transaction, your wallet routes it through a private RPC for privacy rather than broadcasting it to the public mempool. The private RPC forwards it to an order flow auction (OFA), which runs a competitive auction among searchers for the right to interact with your transaction, returning a share of the auction proceeds back to you. The winning searchers bundle your transaction with others and send the result to builders, who assemble a complete block. Builders submit their blocks to relays, which run an open auction on behalf of proposers. The proposer selects the highest bid, signs a commitment, and the block becomes part of the chain.

This pipeline is not part of the Ethereum protocol. It runs entirely out-of-protocol.

Sidecars

Consensus clients (Lighthouse, Prysm, Teku, Nimbus, Lodestar) are responsible for Ethereum’s core safety: proposing blocks, attesting, and enforcing fork-choice rules. These codebases need to stay focused and conservative. Every new feature adds risk.

But validators increasingly need to interact with services outside the protocol: block auctions, commitment protocols, key management systems. Rather than embedding all of this into the consensus client, the work is pushed to a sidecar: middleware that runs alongside the consensus client, extending what a validator can do without modifying the client itself.

MEV-Boost, built by Flashbots and shipped alongside Ethereum’s transition to proof of stake in September 2022, was the first sidecar. Within 60 days of the Merge, over 90% of validators had adopted it. Today, more than 90% of Ethereum blocks flow through this PBS framework.

Here is how the sidecar mediates the block auction during a slot:

  1. Builders submit their blocks to relays throughout the slot.
  2. When the consensus client needs a block, it calls the sidecar.
  3. The sidecar queries all its registered relays for their current best bid.
  4. Each relay responds with a block header and a bid amount.
  5. The sidecar selects the highest bid and returns that header to the consensus client.
  6. The consensus client signs the header (committing to the block) and broadcasts it.
  7. The relay sees the signed commitment and releases the full block to the network.

The validator never sees the block contents before signing. They see the bid amount and the block header, but not the transactions inside. The consensus client does not know or care that its blocks come from a relay auction rather than local construction. It just asks for a block and gets one.

The Proposer’s Problem

The current pipeline works, but it came with a fundamental tradeoff: proposers gave up all agency over their blocks.

Before PBS, validators built their own blocks. They chose which transactions to include, in what order. They had full control. After adopting the block auction, validators became price-takers. They see a bid amount and a header, sign it, and move on. They cannot inspect what is inside. They cannot require that certain transactions be included. They cannot express any preferences about block contents at all.

For a simple block auction, this is fine. The validator’s only goal is to select the highest bid. But as Ethereum evolves, validators may want to do more:

  • Inclusion preferences. A proposer might want to ensure that certain transactions are included in their block, even if a builder would prefer to exclude them. This is a censorship-resistance mechanism.
  • Preconfirmations. A proposer could issue a signed promise to a user that their transaction will be included in the next block, reducing effective confirmation time from 12 seconds to milliseconds.
  • Constraints on builders. A proposer might accept a builder’s block only if it meets certain criteria, like including an inclusion list or respecting a particular transaction ordering.
  • Delegated services. A proposer could delegate specific duties (like issuing preconfirmations) to a specialized operator, while retaining ultimate control over the block.

None of these are possible with the current auction software. It gives the proposer exactly one choice: which bid to accept. Everything else is the builder’s decision.

This is the proposer agency problem, and it is what motivated the next generation of sidecar infrastructure.

Commit-Boost: A Sidecar for Proposer Commitments

Commit-Boost extends the sidecar pattern into a modular framework, already adopted by above 40% of validators as their PBS sidecar. Instead of a single-purpose sidecar that only runs block auctions, Commit-Boost makes each proposer service a pluggable module.

The core idea: validators should be able to make commitments, not just accept bids.

Commit-Boost has three layers:

PBS module. This replaces MEV-Boost for relay interaction. It speaks the same Builder API that consensus clients already use, so from the client’s perspective, switching from MEV-Boost to Commit-Boost is seamless. The PBS module handles relay registration, header requests, and payload retrieval.

Signer module. This manages all signing operations with strict isolation. Modules never hold validator keys directly. When a commitment module needs a signature (for example, to sign a preconfirmation promise), it sends a request to the signer module, which enforces policy. The signer can restrict which message types each module is authorized to sign, preventing a buggy preconfirmation module from accidentally producing a block proposal signature that could cause slashing.

For commitment protocols that require additional collateral, Commit-Boost supports proxy keys: BLS keys derived from the validator’s master key. Commitment protocols see a valid identity, but compromise of a proxy key does not endanger the validator’s 32 ETH stake.

Module system. Developers write commitment modules as Docker containers that communicate with Commit-Boost through its API. Each module runs in its own isolated container. A preconfirmation module cannot read the PBS module’s relay credentials or access validator keys. This isolation is the security boundary.

The architecture means that new proposer services can plug in without validators deploying additional sidecars. One sidecar, one configuration, multiple commitment protocols.

The Auction in Detail

The block auction is not a single moment. It is a continuous process that runs throughout the slot.

At the start of a slot, builders begin constructing blocks. As new transactions arrive in private channels and the mempool, builders update their blocks and resubmit to relays with higher bids. The relay tracks the current best bid from each builder.

Builders can see the top bid at any relay they are connected to. This makes the auction competitive and transparent among builders. A builder trailing the current leader can choose to bid higher, optimize their block, or concede the slot.

The proposer does not commit immediately. They wait as long as they safely can before requesting the current best bid from relays. The later they wait, the higher the bid tends to be, because builders have had more time to discover transactions and build more optimized blocks.

This creates a tension called timing games. Waiting longer optimizes the block, but it also leaves less time for the block to propagate across the network. If the block arrives too late, attesters may not see it in time, and the proposer risks missing their slot entirely.

In practice, most blocks arrive well before the 4-second mark. Ethereum’s consensus rules treat that point as a soft deadline: blocks arriving after it are increasingly likely to be reorged as attesters may not see them in time. This creates a natural boundary on how long proposers can safely delay.

Timing games are not equally accessible to all validators. Large staking operations with fast network connections and relay co-location can push the deadline further than solo validators running from home. This is one of the ways the current pipeline creates subtle centralization pressure on the validator set. The performance dynamics of the auction are explored in detail in our Wait post.

Optimistic Relaying

In the standard relay flow described above, the relay fully validates every builder block before forwarding the bid to the proposer. This means simulating execution to confirm the block is valid and pays the claimed bid. Simulation is expensive and adds latency to the pipeline.

Optimistic relaying relaxes this requirement. Instead of validating every block upfront, the relay forwards the builder’s bid to the proposer immediately and validates the block in the background (or skips full validation entirely for builders with sufficient collateral). If the block turns out to be invalid, the builder’s collateral covers the proposer’s loss.

This tradeoff moves validation cost from the critical path to a collateral-backed guarantee. Builders who want optimistic treatment must post collateral with the relay, effectively putting up a deposit that says: “if my block is invalid, pay the proposer from my deposit.”

Optimistic relaying reduces end-to-end latency, which benefits proposers (they get bids faster) and builders (their bids are more likely to arrive before the proposer commits).

Market Structure

The pipeline’s dynamics have evolved significantly over three years of production.

For a deeper look at these trends, the Blockspace Forum series covers the structural gaps in detail: economics, robustness, and performance. Community-built dashboards and tools provide live data on relay performance, builder activity, and validator behavior.

What Comes Next

The pipeline you just learned about is what runs today. PBS 301 covers the research directions that aim to address its limitations: enshrined PBS, preconfirmations, inclusion lists, multi-party block construction, and the broader push to give proposers more control over the blocks they produce.