Prerequisites
Before installing the Operator Service, ensure you meet the following prerequisites.
Deployed Vault
You will need your Vault contract address for Operator Service configuration. If you haven't created a Vault yet, do that first — otherwise, see where to find your Vault address.
Staking Nodes
Ensure your node infrastructure meets the technical requirements below for reliable operation.
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)
Event log retention
The Operator Service reads event logs from the execution client. It only needs event logs from a recent network checkpoint onward, so you can run it against a pruned node. Retain receipts and logs from at least the following blocks:
| Network | Retain from block |
|---|---|
| Ethereum | 25,900,000 |
| Hoodi | 3,580,000 |
| Gnosis | 48,100,000 |
Any block at or below the value in the table works. The values are rounded down from the actual checkpoint to leave a safety margin.
Operator Service version
Pruned nodes require Operator Service v3.1.14 or later. Earlier versions need the full event log history from the Keeper contract genesis block, so upgrade before pruning your node.
Configure pruning
- Nethermind
- Erigon
- Reth
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.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 block from the table above. The window moves forward as the chain grows, so increase N over time.
Add the following options to Reth command:
# Ethereum Mainnet
--prune.bodies.before=25900000 --prune.receipts.before=25900000
For other networks, use the block from the table above.
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.