> ## Documentation Index > Fetch the complete documentation index at: https://seilabs-docs-evm-cookbook.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Sei Validator Operations Guide > Learn how to set up and maintain a validator node on Sei Network, including hardware security configuration, key management, monitoring practices, and governance participation requirements. This document covers the complete lifecycle of a validator node, from initial setup through ongoing operations and maintenance. To run a reliable and secure validator, you need to understand these concepts. ## Understanding validator responsibilities A validator on the Sei network has several critical functions. As a validator, you are responsible for: * Participating in consensus by proposing and validating blocks * Maintaining high uptime and performance to avoid slashing * Managing delegator relationships and maintaining transparent operations * Participating in governance and network upgrades ## Initial setup ### Initialize node Before key management and registration, initialize your node in validator mode. In this mode, RPC and P2P bind to localhost, which is recommended for validator security: ```bash theme={null} seid init --chain-id --mode validator ``` The default init mode is **full**, which binds RPC and P2P to all interfaces (`0.0.0.0`). For validator (and seed) nodes, use `--mode validator` or `--mode seed`. RPC and P2P then listen on localhost only. Genesis is written automatically for known networks. You do not need to download it separately. `--chain-id` is required. Pass a value such as `pacific-1` or `atlantic-2`. For recognized public networks (`pacific-1`, `atlantic-2`), `seid init` automatically writes the Sei Labs seed nodes into the `bootstrap-peers` field of `config.toml`. As a result, a newly initialized node bootstraps peer discovery with no other configuration. Devnets (`arctic-1`) and unknown or private chains receive no seeds. An existing `bootstrap-peers` value is never overwritten. ### Key management Validator security starts with correct key management. Your validator needs several separate keys: ```bash theme={null} # Validator consensus key - Used for signing blocks seid tendermint show-validator # Operator key - Used for managing validator operations seid keys add operator ``` These keys have different purposes, and you should manage them with appropriate security measures. The consensus key is stored in `priv_validator_key.json`. It is particularly critical because the validator uses it to sign blocks. A compromised or mishandled consensus key could result in slashing. ### Hardware security module (HSM) integration For production validators, an HSM is strongly recommended to protect your consensus key. To configure an HSM for your validator, use these steps: ```bash theme={null} # Install required libraries sudo apt-get install opensc pkcs11-utils # Configure YubiHSM2 yubihsm-connector -d # Generate key in HSM yubihsm-shell # Configure seid to use HSM tee "$HOME/.sei/config/priv_validator_config.json" << EOF { "chain_id": "pacific-1", "key_type": "yubihsm", "state_file": "$HOME/.sei/data/priv_validator_state.json", "hsm_serial": "YOUR_HSM_SERIAL", "hsm_key_id": "YOUR_KEY_ID" } EOF ``` ### Validator registration Before you register your validator, make sure that your node is fully synced with the network. Validator creation is a crucial step that needs careful thought about the commission parameters. The examples below use `pacific-1` (Sei Mainnet). For Sei Testnet, use `atlantic-2`. ```bash theme={null} seid tx staking create-validator \ --amount=1000000usei \ --pubkey=$(seid tendermint show-validator) \ --moniker="choose_moniker" \ --chain-id=pacific-1 \ --commission-rate="0.10" \ --commission-max-rate="0.20" \ --commission-max-change-rate="0.01" \ --min-self-delegation="1" \ --gas="auto" \ --gas-adjustment="1.5" \ --gas-prices="0.02usei" \ --from=operator ``` Plan the commission parameters carefully: * `commission-rate`: Your initial commission rate. It should be competitive and still keep your operation sustainable. * `commission-max-rate`: An upper limit that can never be exceeded. It sets a permanent cap on your commission. * `commission-max-change-rate`: The maximum daily commission change. It limits how quickly you can adjust rates. ## Monitoring and alerting For details about monitoring and alerting for your validator, price feeder, and other nodes, see the [Advanced Operations](/node/advanced-config-monitoring) section. ## Security practices ### Network security Validators may use a sentry node architecture to protect the block-signing node (the validator). This setup adds a layer of defensive proxies, which helps prevent DDoS attacks on your validator node: ```bash theme={null} # Validator node config.toml [p2p] pex = false persistent-peers = "sentry_node_id@sentry_node_ip:26656" private-peer-ids = "" # Sentry node config.toml [p2p] pex = true persistent-peers = "validator_node_id@ip:port" private-peer-ids = "validator_node_id" #optional unconditional-peer-ids = "validator_node_id" ``` ### Key management practices Set up secure procedures to back up your keys. Choose the storage media carefully. Mechanical or flash-based storage can fail unexpectedly. **Never** use cloud storage. The consensus (signer) key is stored in `$HOME/.sei/config/priv_validator_key.json`. With the `file` keyring backend, the wallet key files (`.info` and `.address`) are stored in `$HOME/.sei/keyring-file`. Back up both locations. This example script encrypts backups of the key files: ```bash theme={null} #!/bin/bash # Create encrypted backup of validator keys BACKUP_DIR="/secure/validator/backup" DATE=$(date +%Y%m%d) # Backup validator key tar czf - $HOME/.sei/config/priv_validator_key.json | \ gpg --symmetric --cipher-algo AES256 \ -o $BACKUP_DIR/validator_key_$DATE.tar.gz.gpg # Backup keyring tar czf - $HOME/.sei/keyring-file | \ gpg --symmetric --cipher-algo AES256 \ -o $BACKUP_DIR/keyring_$DATE.tar.gz.gpg # Create SHA256 checksums sha256sum $BACKUP_DIR/*.gpg > $BACKUP_DIR/checksums_$DATE.txt ``` ## Maintenance procedures ### Planned maintenance To minimize the potential impact of planned maintenance: * Notify delegators, preferably at least 24 hours in advance Consider posting to: * Shared communication channels for the development team and validators * Social media channels * Validator website Make sure that you stop the service: ```bash theme={null} # Gracefully stop the node sudo systemctl stop seid # Perform maintenance tasks # Restart services sudo systemctl start seid ``` ### Emergency procedures Create and maintain an emergency response plan for different scenarios: #### Consult with your fellow validators or a member of the Sei Labs or Foundation team directly for advice ## Governance participation As a validator, you must participate actively in governance. Governance is the primary tool to adjust various chain parameters. Another critical role for validators is to review proposed software upgrades to the network, and finally approve or reject them. Anyone who pays the mandatory (refundable) deposit may submit a governance proposal. Any network user can vote on a proposal. Only votes from accounts that delegate \$SEI at the end of a proposal's voting period are given weight. You can query the proposals that are currently on chain at any time: ```bash theme={null} # List active proposals seid query gov proposals --status voting_period # Vote on a proposal seid tx gov vote 1 yes \ --from operator \ --chain-id pacific-1 \ --gas auto \ --gas-prices 0.02usei ``` ## Recovery procedures ### Critical warning: Double-signing prevention Double-signing is a severe violation that results in permanent validator tombstoning (irreversible jailing). Never run your validator keys on more than one machine at the same time. If your primary validator goes offline: 1. DO NOT start another validator with the same keys 2. Either recover the original machine, or migrate the keys properly. Migrate them only when you are absolutely certain that the original is offline 3. If you are unsure about the state of your original validator, get support before you continue The safe approach to recovery is: 1. Diagnose why the original validator is offline 2. If the original validator cannot be recovered, verify that it is offline and powered down 3. Only then migrate the keys to a new machine ### Validator recovery To recover your validator on a new machine, follow these steps carefully: ```bash theme={null} # 1. Set up new machine with Sei node # 2. Copy secured backup files # 3. Restore validator key gpg -d validator_key_backup.tar.gz.gpg | tar xzf - # 4. Restore keyring gpg -d keyring_backup.tar.gz.gpg | tar xzf - # 5. Start services sudo systemctl start seid ``` After recovery, verify your validator's status and performance: ```bash theme={null} # Check validator status seid status # Verify signing is working seid query slashing signing-info $(seid tendermint show-validator) ``` Validator operation requires constant attention to security, performance, and network participation. Stay engaged with the Sei community, and keep up to date with network developments. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.