Ethereum MPBC Goes Live on Mainnet: How Multi-Party Block Construction Extends PBS

Ethereum MPBC Goes Live on Mainnet: How Multi-Party Block Construction Extends PBS

Custom Image
On September 16, 2026, Ethereum’s out-of-protocol block construction pipeline took a concrete step forward when multi-party block construction, or MPBC, began operating on mainnet. Coordinated by the Blockspace Forum, the system allows more than one builder to contribute transactions to the same block while preserving the existing proposer-builder separation auction. Early data from the first 24 hours showed roughly 3 percent of blocks using the multi-party approach and more than 20,000 transactions included faster than they otherwise would have been. The design is strictly additive: no consensus changes, no hard fork, and no requirement for validators already connected to major relays to alter their configuration. Operators including Titan, Ultra Sound, and Aestus began serving multi-party blocks, with coverage reported at approximately 85 percent of builders and 90 percent of validators.
 
The approach is clear. MPBC extends the PBS model by creating additional inclusion paths within a single slot. A base block from the highest-bidding single builder can be improved by appending non-conflicting transactions from other opted-in builders. The resulting multi-party block is delivered only when it produces higher value than the best single-party alternative available at delivery time. This mechanism targets known structural gaps in the current pipeline, limited transaction visibility, winner-take-all dynamics, and weaker support for service transactions, while remaining fully compatible with upcoming protocol changes such as enshrined PBS and FOCIL.
 

How the Append-Only Model Works in Production

In the initial version of MPBC, the highest-bid single-party block serves as the base. Operators then identify eligible transactions submitted by other builders that do not conflict with the base block’s state or execution guarantees. These contributions are appended rather than interleaved or reordered. Service transactions such as proposer commitments that were missing from the base can also be added. Once the multi-party block is assembled, the operator re-simulates it to confirm validity and calculates the surplus value created by the additional transactions. Only if that multi-party block pays a higher bid than the best single-party block available at delivery time, and only if the base builder remains the same, is the multi-party header offered to the proposer. Documentation published by the Blockspace Forum details the exact merging and delivery stages, including the requirement that operators filter any transaction that would revert.
 
Early mainnet results reported some multi-party blocks carrying up to 810 additional transactions relative to the single-builder alternative, with gas usage increasing substantially in selected cases. The append-only constraint keeps the design simple and safe for the first production deployment while still unlocking measurable gains in blockspace utilization. Builders control participation through metadata flags submitted with each bid. A builder can mark a block as eligible to serve as a merge base or mark individual transactions as mergeable into other bases. Operators share payloads among themselves to improve propagation reliability. Value created by the added transactions is distributed according to a fixed initial rule: the surplus is split evenly among the base builder, the contributing builder, the operator, and the proposer. Priority fees continue to accrue to the base builder’s coinbase, and distribution payments are settled by appending transactions funded from reserves the base builder has placed with the operators. This arrangement gives smaller builders a path to earn revenue without winning the full auction while still preserving competitive bidding incentives for the base slot.
 

Early Mainnet Metrics and Observed Inclusion Gains

In the first full day of operation, approximately 3 percent of Ethereum blocks incorporated multi-party construction. Testing that began in late August had already demonstrated faster inclusion for more than 20,000 transactions. Live dashboards released alongside the launch track participation rates, surplus value, and the number of additional transactions landed per multi-party block. These figures remain modest because the system is new and builders are still opting in transaction by transaction, yet the direction is clear. Blocks that would previously have left certain transfers or blob transactions for later slots are now absorbing them when they increase overall value. The Blockspace Forum’s pre-launch dry-run data covering roughly 250,000 blocks suggested that a fully utilized V1 implementation could raise block value by as much as 4.15 percent when all eligible transactions are available for merging.
 
Actual mainnet performance will depend on how quickly more builders register Safe accounts with the operators and mark their flow as mergeable. The practical effect for users is shorter wait times during periods of elevated demand. Transactions that one builder filters or simply never sees can still reach the chain in the current slot through another builder’s contribution. This reduces the need for defensive overbidding and lowers the chance that a transaction spills into subsequent slots. Validators connected to the participating operators receive the higher of the multi-party or single-party bid automatically. No new software is required for the large majority of node operators already using PBS sidecars. The system therefore delivers immediate, if still partial, improvements in utilization without forcing a simultaneous upgrade across the entire validator set.
 

Operators Handling the Merge and Delivery Pipeline

Three operators, Titan, Ultra Sound, and Aestus, began serving multi-party blocks on launch day. Their endpoints integrate with the same registration flow validators already used for relays. Operators receive blocks and merge preferences from builders, perform the append-only construction, re-simulate the result, and compare it against the latest single-party high bid. Because operators share payloads with one another, a proposer that signs a header can still obtain the corresponding body from a different operator if the original becomes unreachable. This shared-payload design reduces the single-point-of-failure risk that has historically accompanied relay infrastructure. The operator role itself is permissionless; a public reference implementation exists, and any party can run the software. In practice, competitive performance and reliability will determine which operators attract sustained builder and proposer traffic.
 
Operators also handle the value-distribution transactions that settle the surplus shares. They maintain visibility into the reserves builders have deposited and ensure that distribution payments are correctly appended before the block is finalized for delivery. Future roadmap items include performance-based compensation for operators rather than the current fixed split. For the present, the fixed split provides a transparent starting point that all parties can verify on-chain. Validators running distributed validator technology face no additional requirements; they benefit from multi-party blocks as soon as their sidecar is pointed at the operator endpoints.
 

Censorship Resistance Through Multiple Inclusion Paths

Under pure single-builder PBS, the winning builder exercises complete discretion over which transactions enter the block. Filtered or simply unobserved transactions must wait for a later slot or a different builder. MPBC changes that dynamic by allowing contributing builders to append transactions the base builder omitted. A transaction that one builder declines can still appear if another builder submits it and the operator determines that appending it increases block value without violating the base block’s execution guarantees. The Blockspace Forum documentation explicitly lists improved censorship resistance as one of the design goals. The mechanism does not eliminate filtering, yet it multiplies the number of independent parties that must agree to exclude a transaction before it is permanently deferred.
 
This property complements rather than replaces other inclusion-list designs under discussion. FOCIL, expected in a later upgrade, will force a set of randomly selected attesters to insert a limited number of transactions that the protocol itself has observed. MPBC operates at the builder layer and therefore covers transactions that any participating builder has seen, including those that may never have reached the public mempool. Together, the two approaches create overlapping guarantees: protocol-level forced inclusion for a subset of transactions and market-driven multi-builder inclusion for a broader set. The combination raises the cost of sustained censorship without requiring changes to the consensus rules that govern block validity today.
 

Compatibility With Enshrined PBS and Future Protocol Upgrades

MPBC is designed to operate alongside enshrined proposer-builder separation. ePBS improves the trusted hand-off of blocks from builders to proposers by moving certain escrow functions into the protocol. MPBC continues to function because it does not rely on the intermediate relay escrow role for its core merging logic. Proposers remain free to select the highest-value bid regardless of whether that bid arrived through a traditional channel or through an MPBC operator. The Blockspace Forum states that the system is fully compatible with both trustless bids and peer-to-peer bidding paths. Shipping the out-of-protocol improvement at the same time the protocol itself is being upgraded creates an opportunity to replace certain public-good relay functions with competitively operated infrastructure that earns revenue proportional to the value it creates.
 
Looking further ahead, the same additive architecture is expected to remain compatible with FOCIL and with any subsequent expansion of inclusion lists. Because MPBC does not alter the validity conditions of a block, protocol changes that introduce new constraints can be absorbed by the operators when they re-simulate the multi-party result. The initial limitation to non-contentious transactions, simple transfers, and self-contained bundles keeps the first version conservative. Later versions outlined in the roadmap aim to expand the set of mergeable transaction types once the basic machinery has proven stable under mainnet load.
 

Revenue Opportunities for Smaller Builders

Builders that rarely win the full auction can still earn revenue by contributing transactions that are appended to higher-bid base blocks. The surplus created by those contributions is shared, giving the contributing builder a direct economic return. At the same time, a builder that does win the base slot benefits from any additional flow that other builders append, increasing the chance that its block remains the highest-value option at delivery time. Registration requires only that a builder open a Safe with each operator it wishes to use and deposit reserves that fund the distribution payments. Opt-in occurs on a per-submission basis through a simple header flag, so builders retain full control over which of their blocks and transactions participate.
 
This structure lowers the barrier for specialized or regional builders. A builder that focuses on a particular class of service transactions or on order flow from a specific geographic area can still monetize that flow even when it does not produce the globally highest bid. The overall effect is to dilute the winner-take-all pressure that has historically concentrated block construction among a small number of sophisticated entities. Whether the dilution is large enough to shift market structure will depend on how widely builders adopt the opt-in flags and how effectively operators compete on merge quality and reliability.
 

Impact on Transaction Latency and User Experience

When capacity is constrained, transactions that a single builder does not include spill into later slots. Users respond by overbidding to improve their chances of immediate inclusion. MPBC reduces both the spillover and the defensive bidding by expanding the set of transactions that can land in the current slot. During periods of price volatility or elevated network demand, the ability to absorb additional non-conflicting flow can materially shorten confirmation times. The early mainnet observation of more than 20,000 transactions included faster confirmations is consistent with this expectation.
 
Because the multi-party block is only delivered when it is more valuable, the mechanism does not force lower-value transactions into blocks at the expense of higher-value ones; it simply allows more high-value transactions to coexist. Service transactions that previously required explicit opt-in by the winning builder now have additional pathways. A proposer commitment that one builder omits can still be appended by another. This improves the reliability of preconfirmation and other emerging service markets without requiring every competitive builder to support every service protocol. Originators therefore face a more predictable inclusion environment even while the underlying auction remains competitive.
 

Technical Constraints of the First Production Version

The V1 implementation deliberately restricts merging to transactions that do not compete for the same contentious state. Simple transfers and self-contained bundles are supported; more complex interactions that could alter the execution guarantees of the base block are excluded. Operators must re-simulate every multi-party block because the state root changes when new transactions are appended. Invalid blocks are handled under the same optimistic-relay principles that already exist: the proposer is credited the value of the slot, and after ePBS an operator may also bid as a staked entity.
 
Builders and operators continue to rely on mutual trust for payload sharing, although future work may introduce economic or cryptographic mechanisms that reduce that trust surface. These constraints keep the first deployment within well-understood safety bounds. The Blockspace Forum has already indicated that a V2 later in 2026 is expected to expand the set of mergeable transaction types once operational experience has accumulated. Incremental upgrades will continue in parallel. The design therefore treats the mainnet launch as the beginning of an iterative process rather than a finished product.
 

Validator Integration and Operational Continuity

Most validators already connected to the largest relays begin receiving multi-party blocks without configuration changes. Adding the three operator endpoints to an existing sidecar relay list is sufficient. Preferences such as regional filtering or trusted-builder lists can still be expressed through the standard registration header. Timing games played by proposers do not interfere with MPBC construction; operators continuously improve the best available base block throughout the slot, and the proposer always receives the highest-value header available at the moment of request.
 
Infrastructure outages are mitigated by payload sharing among operators, so a signed header can still be fulfilled even if the original operator becomes temporarily unreachable. Distributed validator technology operators face no extra steps. The same holds for validators that continue to use optimistic relaying. Because multi-party blocks are fully simulated before delivery, the risk profile for proposers remains comparable to the risk profile they already accept under conventional PBS. The net result is an increase in expected bid value with minimal operational overhead.
 

MPBC and the Evolving Ethereum Builder Market

By creating revenue streams for contributors who do not win the base auction, MPBC alters the economic calculus that has driven concentration among builders. A builder no longer needs to capture the entire slot to capture value from its order flow. At the same time, the requirement that a multi-party block can only replace a top bid from the same base builder preserves the incentive to compete aggressively on the primary auction. Operators earn a share of the surplus they unlock, aligning their incentives with higher utilization rather than with pure escrow fees. Over time, competition among operators on merge quality, latency, and reliability is expected to drive further improvements in the pipeline.
 
The Blockspace Forum’s workshops in Buenos Aires and Cannes brought together teams representing more than 95 percent of out-of-protocol block production. That breadth of participation increases the likelihood that the design will continue to evolve with input from the parties that actually operate the infrastructure. Public documentation, live metrics dashboards, and an open reference implementation further reduce information asymmetry. The combination of economic incentives and transparent measurement provides a practical foundation for assessing whether the multi-party model can sustainably broaden participation.
 

Conclusion

The Blockspace Forum has stated that the current deployment is the first step. A V2 later this year is expected to support a wider range of transaction types beyond the non-contentious set permitted today. Performance-based compensation for operators is listed as a roadmap item that would replace the current fixed 25 percent split. Shared collateral arrangements among operators are under discussion to improve capital efficiency for builders. Incremental upgrades will continue in parallel with the larger protocol changes scheduled for Glamsterdam and subsequent forks.
 
Because the architecture remains additive, these improvements can be introduced without requiring simultaneous upgrades across the entire validator or builder set. The same documentation emphasizes ongoing collaboration with the broader Ethereum research community. Feedback channels remain open through the Forum’s website and public discussion venues. The mainnet launch therefore functions both as a production system and as a live test bed for the next round of refinements.
 

🔥 Beyond the Headlines: What KuCoin 5.0 Means for You

Market news moves fast — but where you act on it matters just as much. This October, KuCoin launches KuCoin 5.0, transforming KuCoin into a rebuilt platform. Here's what actually changes for you:
 
  • One account for everything. Older platforms split your money across separate "spot," "margin," and "futures" accounts and expected you to understand why. KuCoin 5.0's unified account removes that entirely — deposit once, and everything is simply there.
  • Stocks, indices, and commodities. KuCoin 5.0 expands beyond crypto into global markets. When crypto chops sideways and equities rally (or the reverse), you rotate in minutes instead of opening a brokerage account and waiting days for fiat rails.
  • Real-world assets (RWA). Tokenized exposure to traditional assets like commodities, right inside your crypto account. One of the fastest-growing segments in global finance is no longer reserved for institutions — you access it from the same balance you trade with.
  • Earn while you learn. Not ready to trade? KCUSD lets your stablecoins earn daily, auto-compounding interest. The lowest-stress way to put your idle deposit to work for 4% yield.
  • An AI assistant in plain language. Ask questions, get market context, understand what you're looking at — built into the platform, no jargon required.
  • An app that doesn't overwhelm. Faster, cleaner, and consistent — intuitive from the first tap, not after a tutorial.
  • Safety you can check, not just trust. A MiCAR-licensed EU entity, Proof of Reserves you can verify yourself, and internationally certified security (SOC 2 Type II, ISO 27001:2022).
 
Create your account in minutes — and start on the platform built for where crypto is going, not where it's been.
 

FAQs

How does multi-party block construction differ from the single-builder PBS model that has operated since the Merge?

In the established PBS pipeline, a single winning builder assembles the entire block and the proposer selects among competing bids. MPBC starts from that same highest-bid single-party block and allows other builders to append non-conflicting transactions that increase total value. The multi-party result is offered only when it exceeds the best single-party alternative available at delivery time. The underlying auction and proposer selection mechanism remains unchanged; the extension occurs entirely at the construction and operator layer.

What concrete benefits do ordinary users see from the mainnet activation?

Users experience shorter average inclusion times for transactions that would previously have been deferred when the winning builder lacked visibility into them or chose not to include them. During periods of high demand, the additional inclusion paths reduce the need for aggressive overbidding. Early mainnet data already recorded more than 20,000 transactions landing faster than they would have under pure single-builder construction. The effect is most noticeable for simple transfers and blob transactions that fit the current non-contentious eligibility rules.

Do validators need to install new software or change their existing PBS configuration?

The large majority of validators already connected to major relays begin receiving multi-party blocks automatically once the operator endpoints are added to their sidecar relay list. No client upgrades or consensus-layer changes are required. Preferences for filtering or trusted builders continue to be expressed through the same registration headers used today. Distributed validator technology setups require no additional steps beyond the standard endpoint configuration.

How is the extra value created by appended transactions shared among participants?

The surplus equal to the difference between the multi-party and single-party block value is split equally among the base builder, the contributing builder, the operator, and the proposer. Priority fees still flow to the base builder’s coinbase address. Distribution payments are settled by transactions appended to the multi-party block and funded from reserves the base builder has deposited with the operators. The gas cost of those distribution transactions is deducted from the surplus before the split is applied.
 

Disclaimer

The information provided on this page may originate from third-party sources and does not necessarily represent the views or opinions of KuCoin. This content is intended solely for general informational purposes and should not be considered financial, investment, or professional advice. KuCoin does not guarantee the accuracy, completeness, or reliability of the information, and is not responsible for any errors, omissions, or outcomes resulting from its use. Investing in digital assets carries inherent risks. Please carefully evaluate your risk tolerance and financial situation before making any investment decisions. For further details, please consult KuCoin’s Terms of Use and Risk Disclosure.