Staking Nodes
Your Vault is created but not yet operational. You need to set up the following node infrastructure before installing the Operator Service.
Automated Node Setup Available
A new experimental feature allows the Operator Service to automatically set up execution and consensus clients (Reth and Lighthouse). See Automated Node Setup for details.
Execution Client
Your execution node must be fully synced and running. Any client that supports the ETH Execution API specification ↗ can be used:
- Nethermind ↗ — (Ethereum, Gnosis)
- Besu ↗ — (Ethereum)
- Erigon ↗ — (Ethereum, Gnosis)
- Geth ↗ — (Ethereum)
- Reth ↗ — (Ethereum)
Configure execution client
The Operator Service needs event logs from a network checkpoint onward. If your execution client prunes history, retain receipts and logs from at least the following blocks:
| Network | Required from block | Recommended setting |
|---|---|---|
| Ethereum | 25,933,938 | 25,900,000 |
| Hoodi | 3,583,807 | 3,580,000 |
| Gnosis | 48,127,042 | 48,100,000 |
The recommended value rounds down to leave a safety margin; any block at or below it works.
- Nethermind
- Erigon
- Reth
Nethermind must be run in FastSync mode. The barrier flags set the first block whose bodies and receipts are kept, and --History.Pruning=UseAncientBarriers removes older history from an already synced node:
# Ethereum Mainnet
nethermind --Sync.FastSync=true \
--Sync.AncientBodiesBarrier=25900000 \
--Sync.AncientReceiptsBarrier=25900000 \
--History.Pruning=UseAncientBarriers
Erigon does not support pruning from a fixed block. It only keeps a rolling window of the latest N blocks:
# Keep the latest N blocks
erigon --prune.mode=full --prune.distance=N --prune.distance.blocks=N
Set N to at least the current block minus the recommended block from the table above.
Add the following options to Reth command:
# Ethereum Mainnet
--prune.bodies.before=25900000 --prune.receipts.before=25900000
For other networks, use the recommended setting from the table above.
Operator Service versions before v5.1.1 still require the full event log history since the Keeper contract deployment. Upgrade the Operator Service before pruning.
Consensus Client
Your consensus node must be fully synced and running. Any client that supports the ETH Beacon Node API specification ↗ can be used:
- Lighthouse ↗ — (Ethereum, Gnosis)
- Nimbus ↗ — (Ethereum, Gnosis)
- Prysm ↗ — (Ethereum)
- Teku ↗ — (Ethereum, Gnosis)
- Lodestar ↗ — (Ethereum, Gnosis)
Validator Client
Set the suggested-fee-recipient flag in your validator client to the correct fee recipient address.
This is the Block reward recipient shown in the Details section at the bottom of your Vault page.
An incorrect value will result in penalties for your Vault in the Smoothing Pool and will trigger a warning on the Vault page, alerting users to an invalid validator setup.
MEV-Boost
Set up MEV-Boost ↗ to capture execution layer rewards. MEV-Boost is open source middleware that connects your validator to a network of block builders competing to produce the most profitable block, maximizing your Vault's execution-layer revenue.
If your Vault uses the Smoothing Pool, you must use one of the StakeWise DAO-approved MEV relays.