Commit-Boost now supports Stader: configure your MEV relays without manually listing validators

Stader node operators using Commit-Boost can now automatically load their validators' public keys from the protocol's onchain registries.

At Stakely, we contributed this functionality to the open-source Commit-Boost client to provide native support for Stader's validator registries. It is available from pre-release v0.10.0-rc4 and removes the need to manually copy and maintain a list of pubkeys in the configuration file.

The goal is simple: Stader validators should use the MEV relay configuration assigned to them, even when a node operator adds new validators.

When an Ethereum validator proposes a block, it can use MEV relays to receive blocks built by specialized builders. This flow is known as Proposer-Builder Separation, or PBS. The software that connects a validator to those relays is the MEV sidecar, historically MEV-Boost.

Commit-Boost is an open-source sidecar for Ethereum validators, compatible with the Builder API used by MEV-Boost. It connects validators to MEV relays and can also incorporate other modules related to proposer commitments, such as preconfirmations.

For an operator, it can be used in the flow traditionally covered by MEV-Boost. The beacon node communicates with Commit-Boost through the same standard interface, while the client manages header and payload requests with the configured relays.

One of its most useful functions is the multiplexer, or mux. It makes it possible to apply different relay configurations to specific groups of validators within the same instance.

This is useful when an operator combines its own validators with validators from a protocol such as Stader, as each group may require a different relay policy. Relay selection should always follow the protocol's requirements and the operator's own operational policies.

To apply a relay configuration to a validator group, the mux needs to identify the public keys that belong to that group.

Until now, a Stader operator had two options:

• manually add pubkeys to config.toml through validator_pubkeys, or use a JSON file;
• maintain a dedicated HTTP endpoint serving that key list.

Both options depend on keeping the list up to date. If a Stader validator is added but not included in the Commit-Boost configuration, it will keep using the default relay configuration instead of the configuration assigned to its group.

Commit-Boost already supported loading validators from onchain registries used by other protocols. With Stakely's contribution, it can now do the same for Stader.

Stader maintains validator registries by operator for its permissionless and permissioned pools.

The new stader loader lets Commit-Boost query the appropriate registry at startup. It uses the operator's node_operator_id and the relevant Stader pool.

The flow works as follows:

1. It identifies the registry contract for the selected pool.
2. It queries how many keys the operator has registered.
3. It retrieves the pubkeys in batches through RPC.
4. It assigns those keys to the mux and the relays defined for that group.

When enable_refreshing is enabled, Commit-Boost queries the registry again periodically. This means validators added later can be included in the configuration without manually maintaining key lists.

You will need Commit-Boost v0.10.0-rc4 or a later version that includes this functionality, as well as access to an Ethereum mainnet RPC endpoint.

The Stader loader is currently available for mainnet. If you have not installed Commit-Boost yet, first read its official installation guide.

1. Define the base PBS configuration

In config.toml, configure rpc_url within the [pbs] section. Commit-Boost uses this endpoint to query Stader's onchain registry.

chain = "Mainnet"

[pbs]
port = 18550
rpc_url = "http://YOUR_EXECUTION_CLIENT:8545"

# Default relays for validators NOT included in any mux
[[relays]]
url = "https://[email protected]"

The endpoint can be your own execution client or a compatible RPC provider.

2. Add a mux with the Stader loader

Next, define the mux and specify your operator ID and the pool where you operate, either permissionless or permissioned:

[[mux]]
id = "stader-validators"
loader = { registry = "stader", node_operator_id = 42, stader_pool = "permissionless", enable_refreshing = true }

[[mux.relays]]
id = "relay-1"
url = "https://[email protected]"

[[mux.relays]]
id = "relay-2"
url = "https://[email protected]"

The loader fields are:

Not sure what your node_operator_id is? You can find it in Stader's operator dashboard or in the relevant registry contract.

3. Restart and review the logs

After applying the configuration, restart Commit-Boost and review the PBS module logs. You should see keys being loaded from Stader's registry.

Two common errors can help identify an incomplete configuration:

• Stader registry requires RPC URL to be set in the PBS config: rpc_url is missing from [pbs].
• Stader registry requires stader_pool to be set in the mux config: stader_pool is missing from the loader configuration.

Check that the number of keys loaded into the mux matches the validators registered for your operator. From that point on, block proposals from that group will use the relays defined in the mux.

• Mainnet only, for now: the configured registry contracts correspond to Ethereum mainnet. This version does not support testnets.
• Pre-release: the functionality is included in v0.10.0-rc4 and will be part of the next stable v0.10.0 release. If you prefer to wait for the stable version, the configuration will be exactly the same.
• Default relays: validators that do not belong to any mux will keep using the relays in the global [[relays]] section. This lets you combine Stader validators with other validator groups in the same instance.

Resources

• Commit-Boost documentation
• Stader node operator documentation
• Commit-Boost v0.10.0-rc4 release

At Stakely, alongside operating validators across dozens of networks, we operate Ethereum validators, including as a Stader operator, and use Commit-Boost in production.

This contribution came from an operational need of our own: preventing a manually maintained key list from becoming a maintenance and error-prone point. By contributing the loader upstream, any Stader operator can adopt the same flow.

You can review the contribution and follow the project's evolution in the Commit-Boost repository. If you operate Stader nodes and have questions about the configuration, get in touch. We will be happy to help.