← All articles

What Emerged from the Blockspace Forum Workshop in Cannes

@0x3hu79
@0x3hu79
April 5, 2026 · Market Structure
#PBS#block-building#relays#block-merging#sub-slots#preconfirmations

On April 1st, ~50 people gathered at the Hotel Le Majestic in Cannes for the Blockspace Forum Workshop, a side event during EthCC 2026. The room included validators, relay operators, block builders, searchers, wallet teams, OFA providers, rollup operators, and researchers. Just a full day of guided technical discussion about what’s broken in Ethereum’s block building pipeline and what to do about it.

I was there and this is my attempt to distill what emerged.

The workshop was framed around the four problem areas identified in the “Observation on Ethereum’s Blockspace Market” paper published in December 2025: economics, robustness, performance, and services. But the discussions quickly moved from problem taxonomy to concrete mechanism design. Three ideas dominated the day: relay block merging, sub-slot execution, and multi-relay coordination.

Relay Block Merging: The Idea That Gained the Most Traction

The single concept that received the most sustained attention was relay block merging - the idea that relays can improve blocks after the builder auction by appending non-contentious transactions from losing builders onto the winning block.

How it works

Today, when a builder wins the relay auction, its block goes to the proposer as-is. Transactions that only existed in losing builders’ blocks simply wait for the next slot. But the relay sees flow from all builders. Some of those unincluded transactions have zero state contention with the winning block - simple transfers, non-overlapping contract calls, and similar.

The merging proposal: take the winning block, identify non-contentious transactions from contributing builders, and append them. The merged block is only delivered if its total value exceeds the latest PBS block - so the guarantee is that the proposer never gets less than they would have without merging.

The value split

The initial design distributes the merging surplus four ways: the winning builder (who provided the base block), the contributing builder (whose transactions were appended), the proposer, and the relay (who performed the merge). Each party’s payoff becomes their PBS payoff plus a share of the surplus - strictly non-negative.

What the numbers look like

Simulations presented at the workshop showed that roughly 96% of non-contentious transactions could be successfully merged. The additional value captured was estimated conservatively at 3-7% of total block MEV, with one analysis using a major builder’s flow suggesting up to 20% in some configurations (though that’s an upper bound given that builder’s unusually broad flow access).

Beyond appending: prepending as an extension

The workshop also explored extending merging beyond bottom-of-block appends to include prepending — adding transactions to the top of the block. This unlocks use cases like ad hoc liquidity pricing through oracle updates, where fresher on-chain prices improve trade outcomes for users and liquidity providers. Prepending is more complex than appending (it can interact with the winning block’s execution) but was identified as a natural next step.

Design tensions that surfaced

Several hard questions came up:

What if a less valuable base block allows more merging? Consider a scenario where Builder A has the highest base block value, but Builder B’s block, while lower-valued, would allow significantly more transactions to be merged on top - producing a higher total. The current design always merges into the highest base block, specifically to prevent builders from submitting intentionally small blocks to game the merge. The room acknowledged this leaves some value on the table but agreed the anti-gaming property is more important.

Does merging turn relays into builders? Several participants raised this concern. If the relay is constructing the final block (even just by appending), it’s doing builder-like work. The response was to keep merging rules deterministic and simple - the relay should enhance blocks, not compete with builders on sophisticated construction.

Latency cost. Merging takes time. Even one millisecond means the base block is slightly stale relative to the latest PBS bid. For latency-sensitive flow (particularly CEX-DEX arbitrage), this matters. The design includes an opt-out: the winning builder can decline merging for specific blocks. But if too many builders opt out, the system doesn’t work. The room didn’t fully resolve this.

Feedback to builders. An idea that kept resurfacing: what if the relay communicated information back to builders during block construction? This could enable more valuable blocks, but adds latency and complexity. One participant framed it as the relay becoming a “heavy point” - the more sophisticated merging becomes, the more the relay resembles a centralized builder. The tension between sophistication and simplicity was acknowledged but not resolved.

Pre-Confirmations: An Elegant Piggyback

One of the day’s more elegant insights was that relay block merging naturally enables inclusion pre-confirmations without requiring builder integration.

Today, if a proposer has committed to including a pre-confirmed transaction, but the winning builder’s block doesn’t contain it, the relay’s only option is to reject the block. With merging, there’s a second option: append the pre-confirmed transaction onto the winning block.

This means relays can offer inclusion pre-confirmations by default. The cold start problem - where every builder needs to integrate pre-confirmation logic before the service is viable - simply goes away. Three to five relays adopt merging, and suddenly every block they process supports inclusion pre-confirmations.

Teams working on pre-confirmation protocols (such as ETHGas’s mev-commit) were part of the discussion, and the interaction between their commitment systems and relay merging was explored in depth. The key insight: pre-confirmations are essentially constraints, and relays can share constraints with each other at slot start without affecting the auction.

Sub-Slot Execution: Faster Without Forking

A second major thread explored giving users faster execution feedback without changing Ethereum’s 12-second slot time at the protocol level.

The approach

The TOOL network (by NuConstruct) presented a system where proposers opt in (via a one-line MEV-Boost config change) to have their slots divided into sub-slots - periods of roughly 200 milliseconds to one second. After each sub-slot, a partial state transition is shared, allowing subsequent participants to build on updated state rather than the stale state from 12 seconds ago.

The distinction from pre-confirmations was emphasized: these are “early execution confirmations” - as the state transitions happen, users get confirmation. It’s not a forward-looking guarantee (“your tx will be in a future block”) but a real-time one (“your tx just executed in this sub-slot”).

The CEX-DEX research

Supporting research was presented showing that shorter sub-slots don’t necessarily increase individual trader profits - the delta per trade stays roughly the same. But trading volume increases significantly because shorter forecast windows reduce variance. Traders are more willing to participate when they’re forecasting across one second rather than twelve.

The implication for block value: more trades means more total fees, even if per-trade profits are flat. The research simulated multiple competing agents across different sub-slot configurations and found that aggregate block value increases with shorter sub-slots, primarily driven by volume.

The proposer game theory

A creative design choice: proposers don’t see the real block value from sub-slotted blocks. This prevents them from comparing TOOL blocks against PBS blocks just-in-time and cherry-picking. Instead, proposers make a longer-term decision - opt in based on historical average rewards or opt out. The blinding makes just-in-time switching unprofitable.

Open questions

The hardest question the room wrestled with: how do sub-slots interact with the traditional PBS pipeline? Several scenarios were explored:

  1. Sub-slotted blocks compete head-to-head with PBS blocks at slot end - winner takes all
  2. Sub-slots can be “reorg’d” if the total sub-slot value is less than a competing PBS block
  3. Non-contentious transactions are merged on top of sub-slots (combining both approaches)
  4. Proposers set a global constraint: all blocks for their slot must be sub-slotted

No consensus emerged. The fundamental tension is that sub-slots are most valuable for contentious state (that’s where composability matters), while relay merging only works for non-contentious state. Reconciling the two is an open design problem.

Multi-Relay Coordination: What Can Be Shared

The afternoon session explored what relays can share with each other without compromising their competitive positions.

Items identified for sharing

Network infrastructure

A discussion on relay-to-relay communication led to a presentation by Optimum on Random Linear Network Coding (RLNC), a technique from information theory that allows decentralized data propagation to achieve the same throughput as a centralized system - even under Byzantine attacks.

The key property: coded packets are “fungible.” Unlike traditional sharding where you need specific missing pieces, any coded packet helps any recipient get to full decoding faster. Every node in the network re-encodes and re-broadcasts, so redundancy and resilience are baked in without coordination overhead.

Performance numbers shared: approximately 120-150 milliseconds for a 30KB payload propagated globally (US to EU to Asia), with near-zero overhead from coding headers. The approach was running on testnets with results matching initial benchmarks.

For the blockspace pipeline, this could significantly reduce latency variance between geographic clusters - one of the key performance problems identified in the original paper.

Shared Block Building: BuilderNet’s Approach

The BuilderNet project (operated by Flashbots, Beaver Builder, and Nethermind) presented their TEE-based shared building system.

The architecture

Multiple operators run the same builder code inside Trusted Execution Environments. TEEs allow verification of what code ran and what data was input, enabling order flow sharing with privacy guarantees. Users can send transactions knowing they won’t be frontrun - the TEE enforces that only valid operations (like backruns) are performed on shared data.

Value distribution

BuilderNet has a refund mechanism: after each block, a simulation calculates the marginal value contribution of each order flow source. The surplus above these contributions is kept by the system; the rest is redistributed.

The broader value distribution question - how to reward infrastructure operators, not just order flow contributors - remains unsolved. It was explicitly acknowledged that specialized parties need to capture value for the services they provide, or the system won’t sustain itself. But no one in the room had a satisfying programmatic mechanism for this.

SUAVE clarification

For those tracking the Flashbots ecosystem: SUAVE was described as the long-term vision, not a separate product. BuilderNet is one instantiation. The relationship was compared to how “world computer” is Ethereum’s aspiration, while the beacon chain is the current implementation.

The Meta-Themes

Stepping back from the specifics, several themes ran through the entire day:

The relay’s role is expanding

Across every topic - merging, constraint sharing, sub-slot coordination, pre-confirmation enforcement - the relay is doing more than trusted escrow. It’s becoming an active participant in block construction. This is a significant shift. The relay was designed to be a neutral intermediary; now it’s being asked to enhance blocks, coordinate across instances, and enforce commitments. Whether this expanded role is compatible with the relay’s current economics (which are unsustainable, as the original paper noted) is an open and urgent question.

Non-contentious vs. contentious: the great divide

Almost every design discussion hit the same fork: mechanisms that work beautifully for non-contentious state (simple transfers, independent contract calls) break down for contentious state (DEX arbitrage, liquidations). Relay merging works for non-contentious. Sub-slots are most valuable for contentious. Getting both to coexist in one pipeline is the central design challenge going forward.

From exclusive flow to coordination layer

Perhaps the most significant shift I observed: the competitive frontier is moving. Today, builders compete primarily on exclusive order flow. The mechanisms discussed at this workshop - merging, sub-slots, shared building - all point toward a future where competitive advantage comes from participating in the coordination layer. Being in the room, shaping the designs, and operating the infrastructure that implements them.

This doesn’t mean exclusive flow disappears overnight. But the direction is clear: the ecosystem is building toward a world where the “winning block” is assembled by multiple parties, value is distributed programmatically, and the builder’s monopoly on block construction is decomposed into specialized roles.

Governance is the elephant in the room

Multiple participants explicitly wanted to “stay away from governance.” But every design discussion implicitly required it: who sets the merging rules? Who decides sub-slot parameters? Who determines value splits? The workshop operated on goodwill and shared interest. Scaling that to production will require some form of decision-making structure - and nobody has a good answer for what that looks like.

What Block Builders Should Take Away

Relay block merging is coming to production soon. It’s already on testnets. When it ships, even losing builders generate revenue through contributed transactions. This changes the economics of block building: you don’t need to win the auction to earn from your flow.

Sub-slot adoption is a proposer-side decision that will happen gradually. Builders should be prepared to construct blocks in sub-slot-compatible formats when proposers opt in. Early operational experience is valuable.

Pre-confirmations are becoming a relay-level feature. Builders won’t need to implement pre-confirmation logic if relays handle it through merging. But builders who understand the constraints will build better blocks.

The “contributing builder” role is new and real. Today, if you lose the auction, your transactions wait. Tomorrow, your non-contentious transactions can be merged into the winning block, and you get paid for the contribution. This is a meaningful change to the builder business model.

Value distribution is the unsolved problem. Every project in the room acknowledged this. Whoever develops a fair, verifiable, programmatic mechanism for distributing value across the block construction pipeline will have significant influence over the next market structure.

Sources

Event:

Background paper:

Projects discussed:

Further reading: