ObolNetwork/lido-charon-distributed-validator-node v0.4.0-rc1 on GitHub

Summary

Warning

This is a release candidate and a required update for hoodi operators ahead of the Glamsterdam (Gloas) fork, activating on hoodi at epoch 132352, October 26, 2026, 17:42:48 UTC. Mainnet operators should not update and should remain on v0.3.10.

CHARON_BUILDER_URLS=https://hoodi.titanrelay.xyz/,https://relay-hoodi.ultrasound.money/,https://relay-filtered-hoodi.ultrasound.money/,https://hoodi-relay.ethgas.com/,https://boost-relay-hoodi.flashbots.net/,https://hoodi.aestus.live/

These are the hoodi relays on the Lido MEV-Boost relay allowlist that Charon requests Gloas execution payload bids from directly.

Important

All operators in your cluster must use the same builder list. Builder authorisations are threshold-signed by the whole cluster, so they only work when threshold nodes sign for the same builders. Coordinate with your squad before updating. If a node's list differs, Charon logs Mismatching peer builder configuration, ensure the builder flags are identical on all nodes in the cluster, and the app_peerinfo_builder_config_mismatch metric is 1 for that peer.

Important

Set CHARON_BUILDER_URLS before starting the new version. Charon writes .charon/vc-config/proposer-config.json the first time it starts and never changes it afterwards. If you started v0.4.0-rc1 without the builder list, or you change the list later, regenerate the file and restart your validator client. Replace vc-lodestar below with the VC set in your .env (vc-nimbus, vc-prysm or vc-teku):

Stop Charon and your validator client:
docker compose stop charon vc-lodestar
Remove the outdated proposer config:
rm .charon/vc-config/proposer-config.json
Start Charon first. It generates a new proposer config from your .env:
docker compose up -d charon
Check that the new file lists your builders (see Verify your setup below):
cat .charon/vc-config/proposer-config.json | jq
Start your validator client. It reads the new file on start:
docker compose up -d vc-lodestar
If the file and your .env don't match, Charon logs Builder flags differ from the proposer config file.

The Teku, Prysm and Nimbus validator clients now run from images built locally on top of the official ones, so the first docker compose up -d after updating takes a little longer.

To update to this version, please run the following commands:

# Stop the node
docker compose down
# Save your local .env / custom overrides
git stash
# Update your local copy of this repo
git pull
# Checkout this release
git checkout v0.4.0-rc1
# Re-apply your stashed changes
git stash apply
# Add CHARON_BUILDER_URLS to your .env (see above), identical to the rest of your cluster
# Restart the node
docker compose up -d

Verify your setup

Once your node is running, check that Charon generated the proposer config with your builders:

cat .charon/vc-config/proposer-config.json | jq

It should look like this. Your fee_recipient comes from your cluster lock, and builders must list every relay in your CHARON_BUILDER_URLS, in the same order:

{
  "version": 1,
  "proposer_config": {},
  "default_config": {
    "fee_recipient": "0x... (the Lido Execution Layer Rewards Vault)",
    "gas_limit": "200000000",
  "builder": {
    "min_bid": "0",
    "builder_boost_factor": "100",
    "max_execution_payment": "0",
    "builders": [
      { "url": "https://hoodi.titanrelay.xyz/" },
      { "url": "https://relay-hoodi.ultrasound.money/" },
      { "url": "https://relay-filtered-hoodi.ultrasound.money/" },
      { "url": "https://hoodi-relay.ethgas.com/" },
      { "url": "https://boost-relay-hoodi.flashbots.net/" },
      { "url": "https://hoodi.aestus.live/" }
    ]
  }
}
}

If builder is missing or the list differs, follow the steps above to regenerate the file. Compare your file with the rest of your squad: the builder section must be identical on every node.

What's Changed

Gloas support with charon v2.0.0-rc1 by @KaloyanTanev in #332

Note

lido-charon-distributed-validator-node is a repo intended as a deployment guide and is not intended to be the canonical way to deploy a distributed validator.

Operators are encouraged to use this repository to build and maintain their own configurations that work for their individual use case. Please work with your squad to have your cluster exposed to no single point of failure on three or more nodes.

Full Changelog: v0.3.10...v0.4.0-rc1