Running a Validator
Hardware Requirements
| Component | Minimum | Recommended |
|---|---|---|
| CPU | 8+ cores (AMD Ryzen 7/9 or Intel i7/i9) | 16 cores, AMD Ryzen 9 |
| RAM | 64 GB | 128 GB |
| Storage | 1 TB NVMe SSD | 2 TB NVMe SSD |
| Network | 1 Gbps symmetric, low-latency | Dedicated 1 Gbps, <10ms to peers |
| OS | Ubuntu 22.04 LTS | Ubuntu 22.04 LTS |
Staking Requirements
| Phase | Minimum Stake | SLA Requirement |
|---|---|---|
| Phase 2 (Institutional) | 500,000 GX | 99.9% uptime |
| Phase 3 (Community) | 100,000 GX | 99.9% uptime |
Estimated Costs
| Item | Provider | Monthly Cost |
|---|---|---|
| Dedicated server (Hetzner AX102) | Hetzner | ~$90/month |
| Bandwidth | Included | $0 |
| Total | ~$90/month |
We recommend dedicated servers from Hetzner or OVH for consistent uptime. Home internet connections typically cannot meet the 99.9% SLA requirement due to ISP maintenance, power outages, and variable latency.
Installation
# Install GX Chain validator
curl -sSL https://install.gx.exchange/validator | bash
# Initialize validator
gx-engine init --mode validator \
--moniker "my-validator" \
--chain-id gx-engine-mainnet-1
# Start validator
gx-engine start --validator-key $GX_VALIDATOR_KEYSecurity Note: The validator key is passed via environment variable (
$GX_VALIDATOR_KEY), never as a CLI argument. This prevents the key from appearing in process listings or shell history. Store the key in a secure secrets manager or encrypted environment file with restricted permissions.
Geographic Distribution
Phase 1 validators are distributed across:
| Location | Region |
|---|---|
| Frankfurt | EU-Central |
| Helsinki | EU-North |
| Ashburn | US-East |
Phase 2+ validators are encouraged to select diverse geographic locations to maximize network resilience.
Slashing Conditions
| Violation | Penalty | Additional Consequence |
|---|---|---|
| Double-signing | 5% stake slash | Permanent jail (cannot rejoin) |
| Extended downtime (>24h) | 0.1% stake slash | Temporary removal from active set |
| Invalid block production | 1% stake slash | Block rejected, validator flagged |
Downtime Rules
- Brief outages under 24 hours result in missed block rewards but no slashing
- After 24 hours continuous downtime, the 0.1% slash is applied
- The validator must re-signal readiness to rejoin the active set
- Delegators’ tokens are affected proportionally
Unbonding Period
Staked tokens have a 14-day unbonding period. During unbonding:
- Tokens do not earn rewards
- Tokens cannot be transferred
- The validator remains responsible for previously produced blocks
This protects the network from sudden stake withdrawals that could compromise security.
Monitoring
Recommended monitoring setup for validators:
- 24/7 on-call with automated alerting on block production delays
- Monitor block height to detect falling behind consensus
- Track peer count to detect network isolation
- Alert on disk usage exceeding 80% capacity
- Monitor system resource utilization (CPU, RAM, network)