Skip to main content

Builders

MPBC compensates builders for flow added to their blocks and for contributions to other builders' blocks. This allows earning revenue without winning the slot outright, and increases the likelihood that a block serving as the base for MPBC wins the auction.

Operators continue to offer services like cancels and block propagation. Because operators share payloads with each other, block propagation is likely to be faster and more predictable compared to legacy relay services. Operators share demotions and will support shared collateral to unlock more capital efficiency for builders.

MPBC is permissionless and requires minimal changes to the existing block submission process. Common builder questions are answered in the FAQ.

Getting started​

Builders already submitting blocks to Ultra Sound, Titan or Aestus do not have to change their submission endpoints. Participation requires MPBC reserves and lean additions to bid submissions. See Interfaces for wire details.

Reserves and opt-in​

Builders become eligible for MPBC by registering a Safe with every operator they wish to use and adding reserves.

A builder then opts in one submission at a time, through the x-merge-type header. A builder that sets append_only offers the block as a merge base. A builder that sets mergeable offers transactions out of the block, and offers the block as a base only when the body sets allow_appending. A submission that sets neither value stays out of MPBC.

Because the priority fees added through MPBC accrue to the base builder's coinbase, the value share of the proposer, contributing builders, and operator is drawn from the base builder's reserves. For this reason, builders participating in MPBC must keep their reserves Safe funded. See Value distribution for more details.

Contributing transactions​

To contribute transactions to MPBC, submissions carry the mergeable merge type and merging data:

struct BlockMergingData {
    allow_appending: bool,       // may this block be used as a merge base?
    builder_address: Address,    // credited for orders merged out of this block
    merge_orders:    Vec<Order>, // what may be merged out of it
}

enum Order {
    Tx(TransactionOrder), // { index, can_revert }
    Bundle(BundleOrder),  // { txs, reverting_txs, dropping_txs, flags }
}

Bundles are kept in sequence and execute atomically unless specific transactions within the bundle are marked as available to be dropped or reverted. Orders flagged LATEST_ONLY are only used while present in the builder's most recent submission, thus allowing cancels. Cancels only apply to future multi-party blocks and a block built before the cancel can still be delivered.

Mergeable submissions may use the dehydrated format, and the operator decodes the merging data alongside them. Merge headers that fail to parse are treated as none, which leaves the block out of MPBC.

Builders continue to benefit from bidding competitively in the auction. Higher bids increase the chance of winning the slot outright, of a block being selected as a base block, and of contributing transactions to others' base blocks.

Accounting​

Operators expose a data API for tracking multi-party blocks. For every multi-party block, the endpoint reports the original and new block hash, the original and new value, and the revenue of the base builder, contributing builders, operator, and proposer. This makes win rates and revenue traceable and is documented under Verification. Value charts those figures aggregated per builder.

Quickstart example​

The following bid submission metadata marks a block as an eligible base block for MPBC. This means that transactions by other builders can be added to it. Additionally, a transaction and a bundle are marked as eligible to be merged into a base block by another builder.

This is done by submitting the bid submission with an x-merge-type: mergeable header to the operator API endpoint under POST /relay/v1/builder/blocks, with preferences indicated in the body. A builder that only wants to make its block available as a base can alternatively simply set x-merge-type: append_only in the header without submitting the body.

{
  "submission": { "...": "the standard signed bid submission" },
  "merging_data": {
    "allow_appending": true,
    "builder_address": "0x4242424242424242424242424242424242424242",
    "merge_orders": [
      { "index": 12, "can_revert": false },
      {
        "txs": [45, 46, 47],
        "reverting_txs": [2],
        "dropping_txs": [],
        "flags": "LATEST_ONLY"
      }
    ]
  }
}
  • The block takes part in MPBC because the submission sets x-merge-type: mergeable.
  • By setting allow_appending true, the block is eligible to serve as a base block for others to merge on.
  • The first order marks the transaction at index 12 available for MPBC and specifies that it must not revert.
  • The second order offers the transactions at indices 45 to 47 as a bundle, in this order. The third transaction in the sequence may revert, and none may be dropped.
  • "flags": "LATEST_ONLY" sets that flag on the bundle, which means that it is cancelled if it is not included in the builder's next submission for this block.