Multi-Party Block Construction (MPBC) on Ethereum Explained

TL;DR

• MPBC lets 2 or more builders contribute transactions to 1 Ethereum block. Each eligible transaction gets more than 1 route into a block.
• An operator appends eligible transactions from other builders to the highest-bid block.
• A multi-party block reaches the proposer only when it outbids the best single-party bid and its base builder still leads.
• Builders share 50% of the added surplus, and the operator and proposer receive 25% each.
• MPBC is an out-of-protocol change that leaves Ethereum consensus rules unchanged.
• Validators already connected to the 3 launch operators receive multi-party bids with their current setup.
• Institutional stakers can review relay lists and operator due diligence with their provider.
• Launch support covered 85%+ of the transaction pipeline and 90%+ of connected validators. About 3% of blocks were multi-party in the first 24 hours.
• Everstake is among 17 validators named in the Blockspace Forum launch announcement.

What Is Multi-Party Block Construction (MPBC)?

Multi-party block construction is a mechanism that lets more than 1 party contribute transactions to the same Ethereum block. 

Its goal is to give each transaction more than 1 route into a block, through any participating builder that holds it.

The design defines these key roles:

• Base builder: the builder whose highest-bid single-party block serves as the starting point.
• Contributing builders: builders whose transactions are appended to the base block.
• Operator: the party that merges eligible contributions and submits the higher-paying block to the proposer.
• Proposer: the validator that signs the highest-paying block header it receives.

The design is additive: operators append transactions to the winning block and keep its original contents in place.

MPBC runs out of protocol, in software operated by builders and relays around Ethereum‘s core rules. The Blockspace Forum compares it to a pipeline upgrade that leaves Ethereum consensus rules unchanged.

How Ethereum Block Construction Works Today

Today, 1 winning builder assembles each block delivered through a relay. The proposer signs the block header with the highest bid, a summary that shows the payment and hides the transactions.

According to the Blockspace Forum over 90% of blocks are built through single-party PBS.

Proposer-builder separation (PBS), builders, relays, and MEV-Boost

PBS moves block assembly from validators to specialized builders. Most validators connect to relays through sidecar software such as MEV-Boost or Commit-Boost, which picks the highest bid.

Each slot follows a fixed sequence:

1. Builders assemble full blocks from the transactions and bundles they can access.
2. Builders submit those blocks with bids to relays.
3. Relays validate the blocks and pass the highest bid header to the proposer.
4. The proposer signs the header, and the relay releases the payload.

Relays act as trusted escrow in today’s PBS: they hold the full block until the proposer signs its header. This step stops a proposer from reading the transactions and republishing the block as its own.

Enshrined proposer-builder separation (ePBS, EIP-7732) moves that handoff into the protocol through the Glamsterdam upgrade.

Why a single winning builder determines the block’s transaction set

The auction is winner-take-all, so a block contains only transactions the winning builder could see and chose to include. A transaction sent privately to a losing builder waits for a later slot, even when the winning block has unused capacity.

Private transactions go straight to a chosen builder and skip the public mempool, often to keep trade details hidden until inclusion, leading to 3 outcomes:

• transactions spilling over into later slots,
• users overbidding defensively to secure inclusion,
• a concentrated builder market shaped by winner-take-all economics.

How MPBC Works: From Base Block to Multi-Party Block

MPBC adds a merge step between the builder auction and the proposer. Operators add eligible transactions from other builders to the top-bid block, then deliver whichever version pays the proposer more.

Selecting the base block

The operator starts from the highest-bid single-party block it holds, called the base block. Builders opt each submission into MPBC by setting a merge type (the x-merge-type header over HTTP), and declare in accompanying merging data whether the block can serve as a base and which transactions other blocks may absorb.

To opt in, a builder registers a reserve wallet with each operator and funds it. Those reserves pay the shares owed to other parties when the builder’s block serves as a base.

Adding contributions from other builders

For each opted-in builder, the operator identifies eligible transactions missing from the base block. Service transactions, such as proposer commitments, go first, followed by other transactions that raise block value.

Proposer commitments are promises a validator made in advance, such as a preconfirmation that a specific transaction will land in its block.

The first version covers self-contained transactions that execute correctly when appended to the bottom of a block:

• transfers,
• blobs,
• self-contained transaction bundles.

Trades on the same DEX pool fall outside this scope, because each trade changes the price the next one receives.

When 2 builders submit the same transaction, the operator credits that transaction’s share to the builder that submitted the higher-value block. Ties go to the builder that submitted the transaction first.

Re-simulating the block and validating execution

The operator re-executes the merged block and filters out appended transactions that would revert, unless their builder marked them as allowed to revert. Transactions that would revert are filtered out before the block moves forward.

Appended transactions leave the base block’s execution commitments intact, such as a trade settling at its expected price. If merging a required service transaction would alter them, the operator falls back to the next-highest single-party block.

The operator then calculates the surplus the added transactions bring, mostly through their priority fees. It appends distribution transactions that pay each party its share inside the same block.

Comparing the merged block with the best single-party bid

Builder bids keep arriving during the merge, so the top single-party bid can change. At delivery time, the operator first checks which builder holds the latest top bid.

If another builder now leads, the operator delivers that builder’s single-party block. If the base builder still leads, the multi-party block goes out only when it pays more than both bids.

An example from Blockspace Forum documentation:

1. Builder A leads with a 1.00 ETH bid, and its block becomes the base.
2. The operator appends transactions, and the multi-party block pays 1.05 ETH.
3. If Builder A still leads at 1.03 ETH over Builder B at 1.02 ETH, the 1.05 ETH multi-party block goes out.
4. If Builder B leads at 1.04 ETH instead, Builder B’s single-party block goes out.

As a result, the builder leading the auction at delivery always wins, and MPBC can only enlarge that builder’s block.

Delivering the winning block to the proposer

The operator sends the selected header through the same endpoint the proposer already queries. The proposer signs the highest-paying header across all its connected operators and relays.

From the proposer’s side, a multi-party block arrives as an ordinary bid.

What MPBC Changes for Ethereum’s Blockspace

Blockspace is the capacity of each block, measured in gas. MPBC lets a block carry transactions known to any participating builder, so more of that capacity gets used each slot.

The design changes 4 things for blockspace:

• More inclusion paths: a transaction can land through the base builder or any contributing builder.
• Higher blockspace utilization: unused gas in a winning block can absorb eligible transactions held by losing builders.
• Access for builders that lose the auction: a builder that loses the slot can still have its transactions included.
• Lower inclusion latency: transactions wait less, because those that would roll into later slots can land in the current one.

Does MPBC Improve Censorship Resistance?

MPBC improves censorship resistance by adding inclusion paths for eligible transactions. Censorship resistance is the ability of a transaction to reach the chain when some parties try to exclude it.

A transaction excluded by the base builder can still land if a contributing builder holds it and an operator appends it. As a result, more independent parties must exclude a transaction for it to miss a slot.

The mechanism has 4 limits:

• Operators are trusted with the entire block, as relays are today.
• Only eligible transaction types can be appended, so contested-state transactions still depend on the base builder.
• A transaction must reach at least 1 participating builder to receive an extra inclusion path.
• Transactions offered for merging must comply with the proposer’s filtering preferences. Dedicated endpoints still serve OFAC-compliant blocks, which exclude addresses on the US Treasury sanctions list.

Protocol-enforced inclusion for public mempool transactions is the role of FOCIL (EIP-7805), planned for Hegotá. Under FOCIL, 16 validators per slot list transactions that the next block must include.

Who Benefits From MPBC and How Does the Economics Work?

Each party in the supply chain receives part of the surplus a multi-party block creates over the base block. The Blockspace Forum defines that surplus as the multi-party block’s value minus the single-party block’s value.

The current rule divides the surplus evenly, 25% each, among 4 parties:

• the base builder,
• the contributing builder,
• the MPBC operator,
• the proposer.

The payout settles inside the multi-party block. Added priority fees, the tips users attach to transactions, go to the base builder’s fee address.

Operators then add transactions that pay the other 3 shares from the base builder’s reserves. Distribution gas costs come out of the surplus, and performance-based operator compensation on the roadmap can change the shares.

Builders and contributing builders

Contributing builders receive a share for transactions they add, even when they lose the slot auction. The Blockspace Forum describes MPBC as permissionless for builders.

Operators and proposers

Operators keep offering relay services such as bid cancellations and block propagation.

Proposers receive the base builder’s bid, plus the 25% proposer share when the delivered block is multi-party. Value that MPBC adds inside 1 slot is distinct from cross-slot MEV, which spans consecutive blocks.

What changes for validators and users

Proposers already connected to a participating operator’s endpoint receive multi-party bids automatically. Validators running distributed validator technology (DVT) face no extra requirements.

DVT spreads 1 validator’s duties across a cluster of nodes run by different operators.

Everstake’s Ethereum validators operate within the same relay-based supply chain that MPBC extends.

Institutional stakers can review 5 areas with their staking provider:

• Relay lists: confirm whether the provider’s MEV-Boost or Commit-Boost relay list includes a participating operator.
• Operator due diligence: operators are trusted parties, so they belong in counterparty and vendor reviews.
• Filtering policies: relay choices determine which inclusion paths and filtering rules apply to a validator’s blocks.
• Reporting: operators expose a data API with original and new block values and each party’s share, which supports reconciliation.
• Incident handling: if a multi-party block is invalid, the proposer is credited the slot’s value. Optimistic relays already compensate proposers this way today.

MPBC vs. PBS, ePBS, and FOCIL

MPBC extends the out-of-protocol builder market, while ePBS and FOCIL change Ethereum consensus rules through hard forks. The Blockspace Forum designed MPBC to run alongside both.

Feature	PBS (MEV-Boost)	MPBC	ePBS (EIP-7732)	FOCIL (EIP-7805)
Where it runs	Out of protocol	Out of protocol	In protocol	In protocol
Hard fork required	No	No	Yes, Glamsterdam	Yes, Hegotá
Builders per block	1	1 base builder plus contributors	1	1, bound by inclusion lists
Main purpose	Outsource block building	Add transactions from other builders	Trustless proposer-builder handoff	Protocol-enforced transaction inclusion
Trusted intermediary	Relay	Operator	Relay escrow role moves into the protocol	Committee of 16 validators per slot
Status	Live since 2022	Mainnet since September 16, 2026	Live on Sepolia since Oct 6, 2026; mainnet targeted for Q4 2026, no date set.	Planned for Hegotá, targeting 2027

ePBS moves the relay escrow role into the protocol. Operators can then register as staked entities, locking collateral that backs their payment to the proposer.

Operators remain optional and see use only when they deliver the highest bid.

No mainnet date is set yet for enshrined proposer-builder separation in Glamsterdam. FOCIL in the Hegotá upgrade is planned as the consensus-layer headliner of the fork after Glamsterdam.

MPBC Mainnet Launch and Early Results

MPBC went live on Ethereum mainnet on September 16, 2026, coordinated by the Blockspace Forum. The initial operators were:

• Aestus,
• Titan,
• Ultra Sound.

The launch announcement names 17 supporting validators, including Everstake. The transaction pipeline means the builders and relays that route transactions into blocks. Connected validators are those linked to relays through MEV-Boost or Commit-Boost.

The Blockspace Forum defines both denominators. The MPBC live metrics page tracks multi-party block counts and how the added surplus is distributed.

Everstake measured MPBC across its own Ethereum validator set and recorded 203 merged blocks out of 6,148 proposed. That is a 3.30% adoption rate, about 1.7x the 1.90% network average.

According to our data, the 0.0356 ETH total is the highest MPBC value captured by any major validator operator so far (early Oct 2026). The 203 merged blocks came through all 3 launch operators:

• Aestus: 89 blocks,
• Ultra Sound: 62 blocks,
• Titan: 52 blocks.

MPBC is additive, so Everstake delegators keep their current setup. The 2,002 added transactions landed in blocks that Everstake validators were already proposing.

Note: MPBC results change daily.

Limitations and What’s Next for MPBC

The first MPBC version carries 6 main constraints:

• Re-simulation cost: every merge requires re-executing the block within the slot deadline.
• Latency: merging adds work before delivery, and a higher bid from another builder discards the merged block.
• Operator coordination: operators share data with each other, including temporary bans on builders that sent faulty blocks, which requires mutual trust.
• Transaction eligibility: trades competing for the same state, such as swaps in 1 DEX pool, stay with the base builder.
• Adoption: proposers outside participating operators’ endpoints receive no multi-party bids.
• Builder reserves: base builders must keep reserves funded to pay the other parties’ shares.

The Blockspace Forum roadmap lists 4 next steps:

• an improved proposer interface with streaming bids, which reach validators faster,
• per-transaction tracing for originators and builders,
• performance-based compensation for operators,
• a V2, planned from Q4 2026 to Q1 2027, that targets contested-state transactions and oracle price updates.

Everstake follows MPBC development as part of the rollout coalition and provides staking infrastructure, having operated Ethereum validators from before the merge.

FAQ

Is MPBC an Ethereum hard fork?

No, MPBC is an out-of-protocol change defined by 4 software interfaces in the Blockspace Forum specifications. The 3 launch operators are encouraged to run their own implementations, which lowers the risk of correlated outages.

Can anyone run an MPBC operator?

Yes, the operator role is permissionless, and the Blockspace Forum points to an open-source reference implementation called Helix by Gattaca. As with relays since the 2022 Merge, a new operator needs trust from validators and builders before receiving blocks.

Institutional stakers can ask Everstake or another provider which operators its validators connect to.

Will MPBC still be needed after ePBS?

Yes, the Blockspace Forum expects operators to persist after ePBS as optional services that raise block value. Under EIP-7732, operators can bid as staked entities or connect outside the protocol with bids above any builder’s locked stake.

Does MPBC change validator timing games?

No, validator timing games, where proposers delay header requests to collect higher bids, leave MPBC unaffected. Multi-party blocks are built continuously across each 12-second slot, so a late header request still receives the winning block.

What happens if an MPBC operator goes offline?

Before signing, a proposer’s sidecar uses the best header from the operators that responded, as it does with relays today. After signing, any of the 3 operators can serve the block, because operators share payloads before the proposer signs.

Can users send transactions directly to an MPBC operator?

No, operators accept blocks only through the builder interface, so users send transactions to builders or the public mempool.