Start Operator
After completing Validators Manager → setup, you're ready to start the Operator Service to begin automated validator registrations.
Start Operator Service
You are ready to run the Operator Service using the start
command, passing your Vault address and consensus and execution endpoints as flags.
Required Flags
--vault
- Your Vault address--consensus-endpoints
- Consensus client API endpoints--execution-endpoints
- Execution client API endpoints
There are several ways to run the Operator Service, depending on how you store private keys.
Local Keystores
By default, the Operator Service runs with locally stored keystores created during key creation.
./operator start \
--vault=0x834F27bC8670491b75af512d943f01D5383F87Cf \
--consensus-endpoints=https://consensus-node \
--execution-endpoints=https://execution-node
If you did not use Operator Service to generate validator keys, you will need to add the following flags:
--keystores-dir
- The directory with validator keys in the EIP-2335 ↗ standard. The folder must contain either a singlepassword.txt
password file for all the keystores or separate password files for each keystore with the same name as keystore, but ending with.txt
. For example,keystore1.json
,keystore1.txt
, etc.--keystores-password-file
- Absolute path to the password file for decrypting keystores.
Existing Wallet Configuration
If you are using an existing wallet (instead of the Operator Service generated wallet), you must add these flags:
--wallet-file
- Path to the wallet keystore file--wallet-password-file
- Path to the password file for the wallet keystore
External Key Management
For alternative key management methods (Remote Signer, HashiCorp Vault, API Mode), see the Alternative Key Management → section.
Running Options
Depending on your installation method, use the appropriate command format:
- Binary
- Docker
- Source Files
Using Binary
./operator start \
--vault=0x834F27bC8670491b75af512d943f01D5383F87Cf \
--consensus-endpoints=https://consensus-node \
--execution-endpoints=https://execution-node
Using Docker
For Docker, you first need to mount the folder containing validator keystores and include the --data-dir
flag alongside the start
command:
docker run --restart on-failure:10 \
-u $(id -u):$(id -g) \
-v ~/.stakewise/:/data \
europe-west4-docker.pkg.dev/stakewiselabs/public/v3-operator:v4.0.0 \
src/main.py start-local \
--vault=0x834F27bC8670491b75af512d943f01D5383F87Cf \
--data-dir=/data \
--consensus-endpoints=http://localhost:5052 \
--execution-endpoints=http://localhost:8545
Using Source Files
PYTHONPATH=. poetry run python src/main.py start-local \
--vault=0x834F27bC8670491b75af512d943f01D5383F87Cf \
--consensus-endpoints=http://localhost:5052 \
--execution-endpoints=http://localhost:8545
Optional Flags
--verbose
- Enable debug mode, prints full output on error--log-level
- Logging detail level, value can be one of: 'ERROR', 'WARNING', 'INFO', 'DEBUG'--min-deposit-amount-gwei
- The minimum amount (in Gwei) that must accumulate in the Vault to trigger validator registration or a top-up. The default is 10,000,000,000 Gwei (10 ETH/GNO)--min-deposit-delay
- The minimum delay that must pass between validator registration or top-up transactions. Adjust this to control the frequency of registration transactions. The default is 3600 seconds (1 hour)--max-fee-per-gas-gwei
- The maximum fee per gas for transactions. Default is 10 Gwei for Ethereum, 2 Gwei for Gnosis. Adjust it if you want to limit the maximum gas fee you're willing to pay--validator-type
- Set to0x01
if you want to register0x01
validators. By default0x02
validators are registered--harvest-vault
- Keeps your Vault synced by calling theupdateState
function of the Vault contract every 12 hours. This simplifies contract interactions and reduces gas costs for your users. By default, the Vault state is also updated whenever users interact with the Vault (deposits, withdrawals, etc.)--claim-fee-splitter
- Claims fees periodically to the addresses of the shareholders. See Fee Claiming → for details--disable-withdrawals
- Disables submitting partial and full withdrawals. This reduces gas costs but increases withdrawal times for users. Oracles will instead submit the exit signatures received from the Operator Service during validator registration--concurrency
- Number of CPU cores used to both load and create keystores
Performance Optimization
For optimal performance, set --concurrency
to half your CPU cores (e.g., --concurrency=4
for 8-core systems) to prevent overloading during keystore operations.
Setup Complete
Congratulations 🎉! Your Operator Service is now running and ready to trigger validator registrations within your Vault. Monitor the logs to ensure validators are being registered successfully.
Next Steps
Continue to Additional Actions → to explore optional configurations and integrations to enhance your Operator Service setup, including validator performance tracking with Rated Network.