# MPBC Mechanism

MPBC has two stages, a merging stage where operators add transactions from multiple builders to a base block, and a delivery stage where they deliver the block winning the auction to the proposer.

The first version of MPBC is limited to transactions that do not compete for contentious state, such as simple transfers or self-contained transaction bundles. [Future versions](https://docs.blockspace.forum/mpbc/roadmap#v2-improvements) may expand this scope to include more complex transaction types.

## Merging

The merging stage commences whenever an operator has received blocks and transactions eligible for merging. To avoid burdening originators with unexpected latency or inclusion, builders decide which blocks can be extended, and which transactions can be added to other blocks. These flags are submitted with [the block's metadata](https://docs.blockspace.forum/mpbc/builders#getting-started).

Operators improve the value of the highest-bid single-party block, even if a combination of multiple other blocks could be more valuable. This prevents builders from spamming blocks containing subsets of the best block to improve their chances of inclusion.

Operators extend the base block by appending missing service transactions such as proposer commitments, followed by other eligible transactions that increase block value, and transactions that distribute the newly added surplus. They execute the following steps:

1. Operators identify constraints from the complete set of constraints $C$ that are absent in the highest-bid single-party block $B_{\text{SP}}$:

   $$
   C_{\text{missing}} = \{\, tx \in C \mid tx \notin B_{\text{SP}} \,\}
   $$

2. Operators attempt to merge these constraint transactions into $B_{\text{SP}}$. If this cannot be accomplished without changing the execution guarantees of $B_{\text{SP}}$, it is discarded, the second-highest-bid single-party block is designated $B_{\text{SP}}$, and the operator returns to step 1.

3. For the highest-bid opted-in block $B_i$ of each builder $i$, the operator identifies the eligible transactions absent in $B_{\text{SP}}$:

   $$
   Txns_{i/\text{SP}} = \{\, tx \in B_i \mid tx \notin B_{\text{SP}} \,\}
   $$

4. The operator merges from $Txns_{i/\text{SP}}$ into $B_{\text{SP}}$, filtering out any transactions that would revert, creating the multi-party block $B_{\text{MP}}$.

5. The operator calculates the surplus of the multi-party block $B_{\text{MP}}$ and appends any distribution transactions.

[Figure: The block leading the auction becomes the base block, and the operator checks that it pays the proposer what it claims. The operator reserves gas at the end for the distribution transaction, simulates contributing builders' transactions against the base, appends the most valuable until the block is full, and fills the reserved gas last.]

## Delivery

The delivery stage commences when an operator has finalized the multi-party block, which is then compared to the highest-bid single-party block available at delivery time. The multi-party block is delivered if it pays a higher bid than the single-party block, and if the base builder of the multi-party block is the same builder that has submitted the highest-bid single-party block at delivery time. This ensures that the mechanism improves on the bid floor set by the PBS auction without changing how builders price their bids.

Operators execute the following steps:

1. The operator checks for the presently highest-bid single-party block $B_{\text{SP,latest}}$.

2. If $B_{\text{SP,latest}}$ was not built by the base builder of $B_{\text{MP}}$, the operator falls back to $B_{\text{SP,latest}}$. Otherwise, the operator verifies the improvement in blockspace utilization and block value by comparing $B_{\text{MP}}$ against the maximum value of $B_{\text{SP}}$ and $B_{\text{SP,latest}}$:

   $$
   \Delta V = \text{val}(B_{\text{MP}}) - \max\bigl(\text{val}(B_{\text{SP}}),\ \text{val}(B_{\text{SP,latest}})\bigr)
   $$

3. If $\Delta V > 0$ the operator returns the header of $B_{\text{MP}}$ to the proposer and splits the surplus as per the value distribution rule; otherwise, it falls back to $B_{\text{SP,latest}}$.

[Figure: While MPBC produces a multi-party block, builders keep submitting higher bids in the single-party auction. At delivery the operator compares its block with the highest bid and delivers whichever pays the proposer more, so the proposer always receives at least that bid.]

## Value distribution

The value unlocked per-block corresponds to the difference between the value of the multi-party block $B_{\text{MP}}$ and the value of the single-party block $B_{\text{SP}}$:

$$
\Delta V_{\text{block}} = \text{val}(B_{\text{MP}}) - \text{val}(B_{\text{SP}})
$$

As multiple builders contribute transactions, the surplus available for distribution is calculated on a per-transaction basis. When several builders contribute the same transaction, it is attributed to the builder with the highest PBS auction bid, incentivizing competitive bidding.

Initially the surplus is split 25% each across the base builder, the contributing builder, the MPBC operator, and the proposer. Performance-based compensation for operators is a [roadmap](https://docs.blockspace.forum/mpbc/roadmap#performance-based-compensation) item.

Value distribution is settled directly in the multi-party block. Priority fees accrue to the base builder's coinbase address and operators append transactions distributing the proposer's, operator's, and contributing builder's shares from [reserves maintained by the base builder](https://docs.blockspace.forum/mpbc/builders#reserves-and-opt-in). The gas cost is subtracted from the surplus added by MPBC. This flow is illustrated below.

[Figure: A base block pays the proposer with its last transaction and keeps the base builder's address as its coinbase. Fees from the merged transactions accrue to that coinbase as surplus, and one transaction appended by the operator pays the proposer, the contributing builders, and the operator their shares from the base builder's reserves. The rest stays with the base builder.]