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 single password.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

Using Binary

./operator start \
  --vault=0x834F27bC8670491b75af512d943f01D5383F87Cf \
  --consensus-endpoints=https://consensus-node \
  --execution-endpoints=https://execution-node

Docker

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.9 \
src/main.py start-local \
--vault=0x834F27bC8670491b75af512d943f01D5383F87Cf \
--data-dir=/data \
--consensus-endpoints=http://localhost:5052 \
--execution-endpoints=http://localhost:8545

Source Files

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)
• --max-validator-balance-gwei - The maximum balance (in Gwei) a validator can have before it is no longer eligible for top-ups. The default is 1945000000000 Gwei (1945 ETH) for Ethereum and 1800000000000 Gwei (1800 mGNO) for Gnosis.
• --max-withdrawal-request-fee-gwei - The maximum fee (in Gwei) for submitting a withdrawal request per validator. The default is 1000 Gwei.
• --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 to 0x01 if you want to register 0x01 validators. By default 0x02 validators are registered
• --harvest-vault - Keeps your Vault synced by calling the updateState 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
• --disable-validators-registration - Disables registering new validators.
• --disable-validators-funding - Disables topping up existing 0x02 validators.
• --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.