Skip to main content
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:
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:
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:

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.
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 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:

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:

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:

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:

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:
After recovery, verify your validator’s status and performance:
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.