← All articles

Relay Block Merging: How Losing Builders Still Get Paid

@0x3hu79
@0x3hu79
April 3, 2026 · Market Structure
#PBS#block-building#relays#block-merging#MEV#censorship-resistance

In Ethereum’s current PBS pipeline, there’s a binary outcome for builders: you win the relay auction and your block gets proposed, or you lose and your transactions wait for the next slot. All the work the losing builder did - sourcing order flow, constructing a block, bidding - produces zero value if someone else bids higher.

Relay block merging, specified by Michael and Kubi from Gattaca/Titan in June 2025, changes this. The mechanism lets relays take transactions from losing builders and append them to the bottom of the winning block - capturing value that would otherwise be stranded. The merged block is only delivered if it’s more valuable than the original PBS block, so there’s zero downside risk for the proposer.

This is a significant design. It solves relay economics (relays finally earn transparent revenue), improves censorship resistance (non-censoring relays can force filtered transactions back in), and creates a new revenue stream for builders who don’t win the auction. Here’s how it works.

The Two Problems

Exclusive order flow wastes value at the system level

Each builder sees only its own exclusive flow plus the public mempool. The winning builder constructs the block from this partial view. Transactions that existed only in losing builders’ blocks go unincluded - they spill into later slots, degrading user experience and reducing total blockspace utilization.

The winning block is the best any single builder could produce, but it’s not the best the system could produce if all flow were visible.

Relay idle time is wasted (or worse, exploited)

Between the auction closing and the block being delivered to the proposer, relays have idle time. Today, this time is sometimes used for “timing games” - strategic delays that extract value without improving the block. Relay block merging repurposes this window: instead of waiting, the relay uses those milliseconds to merge additional transactions.

Three Stages

Before the slot: builder opt-in

Builders who want to participate define two things for each block:

This gives builders full control over what gets shared. Nothing is taken without consent.

Stage 1: auction (unchanged)

The standard PBS auction runs exactly as today. Relays receive bids, the proposer calls getHeader, and the relay designates a winning block B_PBS. No changes to the auction mechanics.

Stage 2: merging (the new part)

For each opted-in builder that lost the auction, the relay:

  1. Identifies all transactions in their block that are absent from the winning block
  2. Filters out any transaction that’s part of a labeled bundle or excluded
  3. Appends the remaining transactions to the bottom of the winning block
  4. Filters out any that would revert when executed at the bottom

The result is a relay merged block B_RM.

The bottom-of-block placement is critical. Appended transactions execute after everything in the winning builder’s block. They can’t interfere with the winner’s execution guarantees - no reordering, no frontrunning, no state conflicts with the MEV-critical top of the block. The winning builder’s block is fully preserved as the base.

The relay can pre-sort non-overlapping transactions into a priority queue during the auction stage, so merging doesn’t require a full pass when the window opens.

Stage 3: delivery (sanity check)

Before delivering the merged block, the relay performs a final comparison:

delta_V = val(B_RM) - max(val(B_PBS), val(latest_PBS_bid))

If delta_V >= 0, deliver the merged block and split the surplus. If not, fall back to the most valuable PBS block - including any late-arriving bid that beat the merged block while merging was happening.

This is the zero-downside guarantee. The proposer never receives a less valuable block than they would have without merging. The system only improves outcomes.

Value Distribution

The merging surplus is simply:

V_merging = val(B_RM) - val(B_PBS)

This additional value needs to be shared among three parties: the relay (which did the merging work), the contributing builder(s) (whose transactions were appended), and the proposer (whose slot it is).

The paper proposes an initial model where the contributing builder captures 25% of the value of their contributed transactions, with the remainder split according to the relay’s distribution policy. The surplus is calculated per-transaction using the transaction’s priority fee - simple, fast, and independently verifiable by any builder against their own records.

Why priority fee and not a more sophisticated MEV calculation? Because the merging stage is append-only. Appended transactions are isolated from the winning block’s execution - there’s no complex MEV interaction to model. Keeping the calculation simple lowers barriers for new relays to participate and makes the system easily auditable.

When multiple builders contribute the same transaction, it’s attributed to the builder with the higher PBS auction bid. This preserves the incentive to bid competitively in the main auction.

Relay Competition Gets a New Dimension

Today, relays compete primarily on latency and trust. Relay block merging adds three new competitive axes:

  1. Transaction pool breadth: how many losing builders’ transactions does the relay see? More builder relationships = more transactions available to merge.
  2. Merging efficiency: how quickly and accurately can the relay identify non-conflicting transactions and append them? Better simulation = more merged per slot.
  3. Latency to attesters: larger merged blocks take longer to propagate. Relays closer to the attestation committee can produce bigger merged blocks within the same time budget.

This creates the relay business model that’s been missing. The relay earns a share of the surplus it creates. The more value it adds through merging, the more it earns. No more relying on donations, bid adjustments, or cross-subsidies.

The “Would Builders Try to Lose?” Question

This is the most interesting game theory question, raised in the discussion thread: if the losing builder gets 25% of the value of their contributed transactions, and the winning builder keeps very little (because auction competition pushes bids up), wouldn’t builders prefer to lose?

The answer is no, for several reinforcing reasons:

Winning gives top-of-block access. The winning builder gets first access to contentious state - the most valuable position in the block. MEV extraction, arbitrage, and liquidations all depend on being at the top. Merging only works for non-contentious bottom-of-block transactions. The highest-value flow can’t be merged.

Only the disjoint set is mergeable. If two builders both have the same transaction, only one copy makes it into the merged block. Only transactions unique to the losing builder - that also execute successfully at the bottom - generate surplus.

Underbidding is self-correcting. If a builder deliberately underbids, the winning builder faces less competition and captures a larger margin. This increases the opportunity cost of the underbidding strategy. The market self-corrects.

The incentive to lose is weakest when it matters most. During high-volatility periods (when block value peaks), top-of-block value scales with volatility. Winning becomes most valuable precisely when losing would be most tempting.

In practice: winning the auction will remain more profitable for the majority of a builder’s flow. Merging provides incremental revenue on the residual - meaningful, but not enough to flip the incentive structure.

Censorship Resistance

Today, if a censoring builder wins the auction, censored transactions wait until a non-censoring builder wins a future slot. The censoring builder has complete control over its winning blocks.

With relay block merging, a non-censoring relay can merge filtered transactions back into the block - even if the winning builder excluded them. The censoring builder’s block is the base, but the relay appends the censored transactions at the bottom.

This doesn’t fully eliminate censorship (the winning builder still controls the top of the block), but it strictly reduces inclusion delay for censored transactions. The upper bound drops from “however many slots until a non-censoring builder wins” to “however many slots until a non-censoring relay processes the block.” Since there are more non-censoring relays than non-censoring builders, this is a meaningful improvement.

Combined with relay inclusion lists (by the same authors), the picture gets stronger: rILs force specific transactions to be included, and merging adds additional transactions beyond the forced set. The two mechanisms are complementary.

The Anti-Gaming Constraint

One important design rule: relays must always merge into the winning PBS block, even if combining fragments of multiple losing blocks would produce a more valuable result.

Without this constraint, builders would be incentivized to submit many small blocks containing subsets of their best block - “building maximum legos” - hoping to have fragments assembled by the relay. This degrades overall block quality because builders would optimize for mergability over standalone block value.

The constraint keeps the incentive structure clean: win the auction with your best full block, or contribute individual transactions via merging. No gaming in between.

What Scales with Decentralization

There’s an elegant property buried in this design: the value of relay block merging increases as builder diversity increases.

In a world with two dominant builders who see most of the same flow, there’s little disjoint flow to merge - the surplus is small. In a world with ten builders, each with partially unique flow, the disjoint set grows and the merging surplus scales.

This means relay block merging creates a positive incentive for builder diversity. More builders = more fragmented flow = more merging surplus = more value for everyone. The mechanism rewards the ecosystem property (decentralization) that Ethereum wants to have.

For Block Builders

The “contributing builder” role is a new revenue line. Even when losing the auction, a builder’s non-contentious transactions can generate revenue via merging. The question isn’t “did I win?” anymore - it’s “what fraction of my flow is unique and non-contentious?”

Bundle labeling and exclusion logic need to be implemented. Builders must define which transactions are bundled (can’t be separated) and which are excluded from merging. Getting the labeling wrong - accidentally exposing a bundle to unbundling - has consequences.

The 25% contributing share is a starting point, not gospel. As the mechanism matures, this will evolve. Builders should have a view on what the right distribution model looks like and be ready to advocate for it.

Merging favors builders with diverse flow. If a builder’s exclusive flow is heavily MEV-focused and contentious, merging adds less (those transactions can’t be appended to the bottom). Builders with a mix of MEV and commodity flow benefit more - the commodity portion becomes a new income source.

Inter-relay sharing will expand the pool. The paper’s future direction envisions relays sharing mergeable transactions after the auction closes. When this happens, a builder’s transactions could end up merged into blocks on relays the builder doesn’t even submit to directly - expanding reach without additional integration.

Sources

Original proposal:

Related proposals by the same authors:

Related work: