What Does a Validator Actually Do?
Validators are the backbone of the Qlorix network. They receive new transactions from users and other nodes, execute them through the Block-STM parallel execution engine, propose new blocks, and then sign attestations confirming the validity of blocks proposed by other validators. When two-thirds plus one of all active validators sign an attestation for a block, that block achieves BFT finality and becomes permanently part of the chain.
Running a validator is a serious commitment. Your node needs to be online continuously because missed attestations reduce your rewards and, if your downtime is persistent, trigger a small slashing penalty on your stake. In exchange, you earn a share of block rewards proportional to your stake, plus a portion of transaction fees from every block processed during your active slots. This guide walks through every step from choosing hardware to watching your first rewards land.
Step 1 - Hardware Requirements
The Qlorix node binary is a single statically-linked executable that runs on any x86-64 Linux host. ARM64 is supported but not the recommended path for production validators. The minimum and recommended specifications differ significantly, and running at minimum spec will hurt your attestation performance under load.
Minimum (testnet / familiarization only):
- CPU: 8 cores at 3.0 GHz or faster
- RAM: 32 GB DDR4
- Storage: 500 GB NVMe SSD (not SATA)
- Network: 100 Mbps symmetric, stable connection
- OS: Ubuntu 22.04 LTS or Debian 12
Recommended (mainnet production):
- CPU: 16+ cores at 3.5 GHz or faster (AMD EPYC or Intel Xeon preferred)
- RAM: 64 GB DDR5 ECC
- Storage: 2 TB NVMe SSD with at least 5,000 MB/s sequential read
- Network: 1 Gbps symmetric, ideally colocated at a Tier 3+ datacenter
- OS: Ubuntu 22.04 LTS
The Block-STM execution engine benefits enormously from high single-core clock speed and fast NVMe latency. RAM is consumed by the multi-version data store during peak block processing. If your NVMe falls below the recommended spec, you will see latency spikes during busy blocks that push attestation timing past the deadline, causing missed votes.
Step 2 - Install Dependencies and the Qlorix Binary
Start with a fresh Ubuntu 22.04 server. Update the system and install the required dependencies before fetching the node binary.
Now fetch the latest stable Qlorix node binary from the official release endpoint and verify its SHA-256 checksum before running it.
Step 3 - Generate Validator Keys
Every Qlorix validator has two key pairs: an identity key that identifies your node on the peer-to-peer network, and a voting key used to sign block attestations. The voting key signs thousands of messages per day and must be kept on the hot server. The identity key can be rotated without affecting your stake. Both use CRYSTALS-Dilithium under the hood, giving them post-quantum security.
Important: The seed phrase output during key generation is the only way to recover your voting key if your server is destroyed. Write it down on paper and store it in at least two physically separate, secure locations. Do not store it digitally on any internet-connected device.
Copy the validator public key output from that last command. You will paste it into the staking transaction in the next step.
Step 4 - Configure the Node
Create the main configuration file at /etc/qlorix/validator.toml. The configuration below is a sensible production starting point.
Open port 8900 in your firewall for inbound peer connections. Leave port 8899 (RPC) and port 9090 (metrics) bound to localhost only unless you have a specific reason to expose them.
Step 5 - Create a systemd Service
Running the validator as a systemd service ensures it starts automatically on boot and restarts immediately if it crashes.
Watch the logs for lines like syncing blocks height=XXXXXX. Wait until the node reaches the current chain tip before proceeding to the staking step. Depending on how far behind your node started, this can take anywhere from a few minutes to a few hours.
Step 6 - Stake QLX and Activate Your Validator
Once your node is fully synced, register it as an active validator by submitting a staking transaction. The minimum self-stake is 50,000 QLX. You can delegate additional QLX from other holders later, but the initial registration requires your own stake.
The --commission-rate flag sets the percentage of delegator rewards you retain as an operator fee. A rate of 5 to 10 percent is typical for public validators. Once the registration transaction is confirmed, your validator enters the pending set and will be activated at the next epoch boundary (epochs are 2 hours long).
Step 7 - Monitor Uptime and Rewards
The metrics endpoint at 127.0.0.1:9090 exposes Prometheus-compatible data. You can scrape it with a local Prometheus instance and visualize it in Grafana. The most important metrics to watch are:
- qlx_attestation_total - cumulative attestations signed; should increase every slot (~400 ms)
- qlx_attestation_missed_total - missed attestations; should stay at zero or very close to it
- qlx_block_proposal_total - blocks you have proposed as leader; increases less frequently
- qlx_peer_count - number of connected peers; should stay above 20
- qlx_sync_lag_slots - how far behind the chain tip your node is; should be 0
Rewards accrue every epoch and can be claimed at any time. They are not automatically compounded - you need to submit a separate restake transaction if you want to add claimed rewards back to your stake balance and increase your share of future rewards.
Slashing and How to Avoid It
Qlorix has two slashing conditions. The first is downtime slashing: if your validator misses more than 10 percent of its expected attestations in a rolling 24-hour window, a small penalty is applied and your stake is reduced. The penalty starts at 0.1 percent of your stake and increases if downtime continues. The second condition is double-signing: signing two conflicting blocks at the same slot, which is evidence of an equivocation attack. Double-signing results in a 5 percent instant stake slash and forced ejection from the validator set. Never run two instances of your validator with the same vote key simultaneously.
The most reliable way to stay slash-free is to use quality hardware with a redundant network connection, monitor your attestation metrics continuously, and have an alerting rule that pages you if qlx_sync_lag_slots exceeds 5 or qlx_attestation_missed_total increases by more than 10 in any 10-minute window. A well-maintained validator on solid hardware should run for months without any manual intervention beyond periodic binary upgrades.