# Node Operators

MPBC improves the expected value of the bids validators receive. Once connected to MPBC operators, validators will start to receive multi-party blocks in addition to single-party blocks. As a multi-party block is [delivered only when it pays more than the best single-party block available](https://docs.blockspace.forum/mpbc/mpbc-mechanism#delivery), this is expected to increase validator revenue. A mainnet dry run test from January to June 2026 covering around 250k blocks indicated that the V1 of MPBC can add up to 4.15% to block value if all eligible transactions are made available for merging. [Live Metrics](https://docs.blockspace.forum/mpbc/live-metrics#overview) reports what MPBC adds on mainnet.

MPBC uses existing integrations and requires no changes from node operators that are already using PBS and connected to the largest relays. Validators will start benefiting from multi-party blocks automatically. [Your Benefits](https://docs.blockspace.forum/mpbc/live-metrics#benefits) charts what MPBC has added for validators. Common node operator questions are answered in the [FAQ](https://docs.blockspace.forum/mpbc/faq#node-operators).

## Getting started

### Connecting a sidecar

Node operators already running a Commit-Boost or MEV-Boost sidecar connected to
any of the [relays and operators below](https://docs.blockspace.forum/mpbc/node-operators#endpoints) may already be receiving multi-party
blocks. They arrive on the same endpoints as every other bid, so nothing about
the sidecar or the registration has to change.

To start from scratch, follow
[Commit-Boost](https://commit-boost.github.io/commit-boost-client/) or
[MEV-Boost](https://boost.flashbots.net/) to get a sidecar running, then add an
operator's URL to its relay list.

### Endpoints

Three operators currently serve multi-party blocks. Their endpoints are listed
here:

| Operator | Network | Connection URL |
| --- | --- | --- |
| [Ultra Sound](https://relay.ultrasound.money) | Mainnet | `https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money` |
| | Hoodi | `https://0xb1559beef7b5ba3127485bbbb090362d9f497ba64e177ee2c8e7db74746306efad687f2cf8574e38d70067d40ef136dc@relay-hoodi.ultrasound.money` |
| [Titan](https://docs.titanrelay.xyz) | Mainnet | `https://0x8c4ed5e24fe5c6ae21018437bde147693f68cda427cd1122cf20819c30eda7ed74f72dece09bb313f2a1855595ab677d@global.titanrelay.xyz` |
| | Hoodi | `https://0xaa58208899c6105603b74396734a6263cc7d947f444f396a90f7b7d3e65d102aec7e5e5291b27e08d02c50a050825c2f@hoodi.titanrelay.xyz` |
| [Aestus](https://aestus.live) | Mainnet | `https://0xa15b52576bcbf1072f4a011c0f99f9fb6c66f3e1ff321f11f461d15e31b1cb359caa092c71bbded0bae5b5ea401aab7e@aestus.live` |
| | Hoodi | `https://0x98f0ef62f00780cf8eb06701a7d22725b9437d4768bb19b363e882ae87129945ec206ec2dc16933f31d983f8225772b6@hoodi.aestus.live` |

The public key in each URL is the operator's identity and should be verified against their official channels before trusting it. Note that Titan also publishes a regional mainnet endpoint, `regional.titanrelay.xyz`, under the same key.

### Registration preferences

Like relays, operators allow node operators to express preferences by attaching
an `x-preferences` JSON header to the standard `/validators` registration
request. The following are supported in MPBC v1, and only the fields to change
are set.

| Preference | Default | Example | Effect |
| --- | --- | --- | --- |
| `disable_optimistic` | `false` | `true` | Only fully validated blocks can win the node operator's slots, so each bid waits on simulation |
| `trusted_builders` | unset | `["SampleBuilder"]` | Restrict the node operator's slots to blocks from a named set of builders |
| `filtering` | `global` | `"regional"` | Regional or global transaction filtering, applied when a submitted block is validated |
| `header_delay` | `true` | `false` | Whether the operator waits before answering a header request. Set it false to be answered immediately |

Builder names are assigned by the operator, so take them from the connected
operator. Each publishes the set it accepts, for example
[Titan's registration docs](https://docs.titanrelay.xyz/proposers/registrations).

### Connecting over a stream

Commit-Boost with the PBS module can now accept bids over a [streamed
connection](https://github.com/Commit-Boost/commit-boost-client/releases/tag/v0.11.0-rc2).
Over HTTP the sidecar polls for bids, adding round trip latency to each
request. This happens at the end of the auction, when the time left to sign and
publish is shortest.

Streaming connections let operators push bids to the sidecar, which makes bid
delivery more reliable and faster:

- Bids arrive throughout the slot, rather than one at the end.
- Once the connection is open, new bids arrive faster without paying for a
  round trip.
- The operator can measure the connection's latency and adjust for it.
- The sidecar falls back to HTTP requests if the stream fails, preserving the
  status quo.

[Figure: ws-stream]