Complete guide to becoming a Goliath Network validator node operator - requirements, setup, and best practices.
Join the Goliath Network as a Validator Node Operator
Preview Testnet Phase: Validator onboarding is currently limited during the preview testnet phase. Open validator registration will be enabled once the testnet phase is concluded. This page provides information for prospective validator operators.
Overview
Validators are the backbone of the Goliath Network, responsible for:
Consensus Participation: Validating transactions and achieving network agreement
Network Security: Maintaining the integrity of the distributed ledger
State Management: Storing and updating the network state
Event Generation: Producing event streams for network activity
Validator Rewards
Validators earn significant rewards for operating nodes. See the Validator Rewards page for complete details including:
Validator Rewards: ~$100,000/year per validator (current testnet config)
Staking Rewards: Additional income from self-staking
Profit calculations with server cost examples
TESTNET VALUES - The reward figures above are testnet parameters only. Mainnet economics will be announced separately.
Why it matters: Consensus nodes perform intensive cryptographic operations. A slow CPU causes the node to fall behind and trigger consensus failures.
Avoid:
ARM processors (not supported)
Consumer-grade CPUs (inadequate cache, no ECC support)
Low-frequency server CPUs (single-thread performance matters)
Memory Requirements
Attribute
Specification
Minimum Capacity
256 GB
Recommended
320 GB+
Type
DDR4 ECC Registered (3200MHz) or DDR5 ECC
ECC
MANDATORY
Why ECC is mandatory: A single bit flip in the in-memory state causes the node to compute a different state hash than other validators, triggering consensus failure. At the scale of 256 GB with constant activity, soft errors are statistically inevitable without ECC.
What happens with insufficient memory:
Heap Size
Observed Behavior
6 GB
Out of memory within hours
16 GB
Out of memory after ~5 days
48 GB
Stable at low TPS with tuning
192-256 GB
Required for mainnet loads
Storage Requirements
Boot Volume (OS):
2x 240 GB SSD minimum in RAID 1 (mirror)
Purpose: Operating system, logs, management tools
Data Volume (Blockchain State):
Attribute
Specification
Capacity
5 TB minimum, 8+ TB recommended
Type
NVMe SSD (enterprise-grade)
Configuration
RAID 0 or RAID 10
Sequential Write
2,000+ MB/s
Random Read IOPS
250,000+
Storage Growth Projections:
Network Load
Daily Growth
Year 1 Total
10 TPS (testnet)
~500 MB
~200 GB
50 TPS (low mainnet)
~3 GB
~1.1 TB
200 TPS (moderate)
~15 GB
~5.5 TB
Network Requirements
Attribute
Specification
Bandwidth
1 Gbps sustained (not burstable)
IP Address
Static IPv4, publicly routable
NAT
Not supported
Latency
<100ms to other validators
Required Ports:
Port
Protocol
Direction
Purpose
50111
TCP
In + Out
Gossip protocol (node-to-node)
50211
TCP
Ingress
gRPC API
50212
TCP
Ingress
TLS-encrypted gRPC
123
UDP
In + Out
NTP time synchronization
Hosting Requirements
VPS vs. Bare Metal: Why VPS is NOT Acceptable
Factor
VPS Risk
Consensus Impact
CPU steal
Noisy neighbors
GC pauses extend → node falls behind → failure
Memory overcommit
Hypervisor swapping
Catastrophic performance degradation
Disk I/O contention
Shared storage
State writes stall → consensus failure
Network jitter
Virtual networking
Gossip delays → consensus divergence
Acceptable Hosting Options:
Option
Verdict
Notes
Dedicated bare metal (Hetzner, OVH, Equinix)
Recommended
Full hardware isolation
Cloud bare metal (AWS i3en.metal, Azure LSv3)
Acceptable
No hypervisor, but expensive
Colocation
Ideal for large operators
Own hardware, rented rack space
Standard VPS / cloud VM
NOT ACCEPTABLE
Causes failures
Data Center Requirements:
Tier III or higher (N+1 redundancy)
Redundant power (UPS + generator)
Redundant cooling
Physical security (badge access, cameras)
Operating System
Attribute
Specification
Supported OS
Ubuntu 22.04 LTS (64-bit)
Alternative
RHEL 8/9, Oracle Linux 8/9
Kernel
5.15.x or 6.x LTS
Required Software:
Component
Version
Purpose
Docker Engine
20.10.6+
Container runtime
Docker Compose
1.29.2+
Container orchestration
JQ
1.5+
JSON processing
cURL
7.58+
API health checks
Estimated Costs
Hardware Budget (Monthly Rental)
Option
Specification
Monthly Cost
Budget bare metal (Hetzner AX162)
32c, 256GB, 2x 3.84TB NVMe
$300-400
Mid-range bare metal (OVH HG-1)
24c, 256GB, 4x 1.92TB NVMe
$400-600
Enterprise bare metal (Equinix)
24c, 256GB, 2x 3.8TB NVMe
$2,000-3,000
Colocation (1U, 5kW)
Your hardware
$500-1,500
Operational Costs
Item
Monthly Estimate
Bandwidth (unmetered)
Included or $100-500
Monitoring/alerting
$50-200
Backup storage
$50-200
Failure Modes: Why Requirements Matter
Hashgraph consensus is Byzantine Fault Tolerant up to a threshold:
< 1/3 faulty: Consensus continues normally
>= 1/3 faulty: Consensus halts completely
There is no graceful degradation. A node that computes a slightly wrong state hash is just as faulty as a node that's completely offline.
Failure Cascade:
Security Best Practices
Key Management
Hardware Security Module (HSM): Recommended for production keys
Validator onboarding will be announced when we are ready.
We are currently in the testnet phase with a limited number of validators operated by the Onyx DAO. Open registration will be announced through official channels.
Becoming a Goliath validator means joining a community dedicated to building the future of distributed ledger technology. While validator onboarding is currently limited during the preview testnet phase, we encourage interested operators to prepare for the upcoming open registration phase.
Resource exhaustion (OOM, CPU steal, disk full)
↓
Node computes wrong state hash
↓
Platform detects Invalid State Signature (ISS)
↓
Node enters CATASTROPHIC_FAILURE state
↓
Node stops participating in consensus
↓
If 2+ of 5 nodes fail: CONSENSUS HALTS
