Summary

Relay block merging allows relays to enhance the winning block by appending non-contentious transactions from losing builders, distributing the surplus among all contributing parties. As of April 2026 it is on testnets and approaching mainnet deployment. It is the most concretely developed proposal to emerge from the Blockspace Forum ecosystem and unlocks pre-confirmations as a relay-level feature.

How It Works

Today, when Builder A wins the relay auction, their block goes to the proposer as-is. Transactions that were only in losing builders’ blocks wait for the next slot.

With merging:

  1. Builder A wins the auction with the highest bid.
  2. The relay identifies transactions from losing builders B, C, … that have zero state contention with A’s block (simple transfers, non-overlapping contract calls).
  3. The relay appends these transactions to A’s block, creating a merged block.
  4. The merged block is only delivered if its total value > the original winning bid. The proposer is strictly non-negative relative to the unmerged outcome.

Value Split

The surplus (merged value − winning bid) is distributed among four parties:

PartyShare
Winning builderShare of surplus (base compensation preserved)
Contributing builderShare for their appended transactions
ProposerShare of surplus
RelayShare for performing the merge

Each party receives their original PBS payoff plus a non-negative surplus share.

Prepending

Beyond bottom-of-block appending, prepending adds transactions to the top of the winning block. Primary use case: ad hoc oracle updates that improve liquidity pricing for subsequent trades. More complex than appending because prepended transactions can interact with the winning block’s execution. Identified as the natural next step but not yet in the initial design.

Empirical Numbers

From simulations presented at the Blockspace Forum Workshop (Cannes, April 2026):

  • ~96% of non-contentious transactions can be successfully merged
  • Additional captured value: conservatively 3–7% of total block MEV
  • Upper bound (using one major builder’s unusually broad flow): ~20%

Design Tensions

Anti-Gaming Property vs. Value Maximization

A less-valuable base block might allow more transactions to be merged, yielding a higher total. The design always merges into the highest base block to prevent builders from submitting intentionally small blocks. This leaves some value on the table but is judged necessary to prevent gaming.

Relay-as-Builder Concern

If the relay is constructing the final block (even just appending), it is doing builder-like work. The resolution: keep merging rules deterministic and simple. The relay enhances blocks; it does not compete with builders on sophisticated construction. The more sophisticated merging becomes, the more it resembles a centralized builder — a tension the community acknowledges but has not resolved.

Latency Cost

Merging takes time. Even 1ms means the base block is slightly stale relative to the latest PBS bid. For latency-sensitive flow (CEX-DEX arb), this matters. The design includes an opt-out: the winning builder can decline merging for specific blocks. If too many builders opt out, the system doesn’t work. (Unresolved.)

Builder Feedback

Relays communicating information back to builders during block construction could enable more valuable blocks but adds latency and complexity. Framed as the relay becoming a “heavy point.” Not resolved.

Pre-Confirmation Synergy

Merging naturally enables inclusion pre-confirmations without builder integration:

  • Today, if a proposer has committed to include a pre-confirmed transaction and the winning builder’s block doesn’t contain it, the relay’s only option is to reject the block.
  • With merging, the relay can append the pre-confirmed transaction onto the winning block.
  • The cold-start problem (every builder must integrate pre-conf logic before the service is viable) disappears.
  • Three to five relays adopting merging → every block they process supports inclusion pre-confirmations.

This was noted as one of the more elegant insights at the Cannes workshop.

Relationship to Sub-Slot Execution

Sub-slots are most valuable for contentious state (where ordering/composability matters). Merging only works for non-contentious state. Reconciling both in one pipeline — having a merged block that also contains sub-slot execution results — is an open design problem.

Status (April 2026)

  • On testnets, matching initial benchmarks
  • Approaching mainnet deployment
  • Implementation driven by relay operators coordinating at Blockspace Forum

Key Sources

  • What Emerged from the Blockspace Forum Workshop in Cannes (Apr 2026) — primary source; all mechanics, numbers, and tensions
  • Three Years of PBS (Dec 2025) — structural gap context motivating merging