Security / Audit·Ethereum · Gnosis · Hoodi
Nethermind Sedge
Open-source one-click setup tool from Nethermind for Ethereum / Gnosis PoS validators and full nodes. Sedge is a Go CLI that interactively (or non-interactively, for CI/CD) generates Docker Compose stacks combining an execution client + consensus client + validator + optional MEV-Boost, runs client-diversity randomization, and handles validator-key generation/import — reducing the foot-gun surface area of running staking infra in production.
- 01solo and institutional staking setup
- 02client-diversity-aware validator deployments
- 03mev-boost integration
- 04DevOps / CI-driven node provisioning
- 05secure validator-key generation + import
- curl -L https://github.com/NethermindEth/sedge/releases/latest/download/sedge-$(uname -s)-$(uname -m) -o /usr/local/bin/sedge && chmod +x /usr/local/bin/sedge
| Variable | Scope | Description |
|---|---|---|
| FEE_RECIPIENT | Server | Ethereum address that receives execution-layer fees (priority tips + MEV) for the validator. REQUIRED; not setting this on mainnet means lost rewards. |
| MEV_BOOST_RELAY_URLS | Server | Comma-separated MEV-Boost relay URLs (e.g. Flashbots + Ultra Sound + bloXroute). Optional — omit to opt out of MEV-Boost. |
Use Sedge to generate and run a validator stack. Interactive setup: `sedge cli` walks through network selection (`mainnet`/`hoodi`/`gnosis`), execution client (Nethermind/Geth/Besu/Erigon/Reth), consensus client (Lighthouse/Lodestar/Nimbus/Prysm/Teku), validator client, MEV-Boost relays, and `FEE_RECIPIENT`, then writes a `docker-compose.yml` + `.env` to `./sedge-data`. Non-interactive (CI): `sedge generate full-node --network mainnet --execution nethermind --consensus lighthouse --validator lighthouse --fee-recipient $FEE_RECIPIENT --mev-boost --relay-urls $MEV_BOOST_RELAY_URLS`. Generate keystores: `sedge keys --network mainnet` (writes mnemonic + keystore files locally). Import keys + start: `sedge import-key --network mainnet lighthouse` then `sedge run`. Monitor: `sedge logs` and `sedge monitoring`.
- ⚑Sedge installs and configures the validator stack but does NOT register, manage, exit, or monitor your validator post-launch — you are responsible for uptime, attestation health, slashing protection, and exit flows. Pair with a monitoring stack (Prometheus + Grafana + alerting) before going live.
- ⚑Validator keys are generated and imported on the host filesystem (`./sedge-data/keystores`) — treat that directory as a hardware-grade secret. Compromise of the keystores OR the mnemonic means slashable theft. Use full-disk encryption + restricted user accounts and never sync `sedge-data` to cloud backup unencrypted.
- ⚑Defaults can drift from current best practice (relay set, client versions, checkpoint-sync URLs) — always pin client image tags, review the generated `docker-compose.yml`, and check Nethermind's changelog before re-running `sedge generate` on a live machine.
- ⚑MEV-Boost is opt-in but adds new failure modes (relay outage, censorship, payload timing) — at minimum configure 3+ relays with a healthy mix of regulated/unregulated/censorship-resistant ones, and confirm `mev-boost` falls back to local block production on relay failure.
- ⚑`FEE_RECIPIENT` is per-validator and must be set before producing the first block — forgetting it on mainnet sends fees to the burn address (`0x000…0000`) by default, which is unrecoverable.
- ⚑Network coverage is currently Ethereum + Gnosis + Hoodi testnet — non-EVM PoS chains and L2 sequencer setups are out of scope. Do not assume Sedge supports your chain without checking the latest networks page.