Chain 🎮 Games

🖥 Chain Games Supernet — Validator Node Requirements Hardware • Recommended: 4 cores / 8–16 GB RAM / 250 GB NVMe SSD • Future Proof: 8 cores / 16–32 GB RAM / 500 GB+ NVMe ⚠️ NVMe SSD is not negotiable. The database is random-I/O heavy and writes every block. SATA SSD is borderline; a spinning disk or a low-IOPS network volume will not keep up with the 3-second block time. CPU • Architecture: x86-64 (tested/supported). ARM64 is unverified — should build, but nothing tests it. Use x86-64. • Validators need dedicated vCPU — no oversubscription/shared “burstable” instances. Fast single-thread speed matters more than core count. A non-validating full node can run on shared CPU. Operating System • Ubuntu LTS (22.04 / 24.04) is the tested distro. Any modern Linux should work, or use the container image. Not for Windows/macOS in production. Storage details • Growth: ~3.3 GB/month on an idle chain (measured floor). Real growth depends on transaction volume and can be 10–100× that. State only grows — it’s never pruned. • SSD endurance: use enterprise (0.3–1 DWPD) or high-TBW NVMe. Avoid cheap DRAM-less QLC drives — they throttle and wear out under constant writes. Networking • Bandwidth: ~1–5 Mbps sustained symmetric (estimate). Public RPC adds more. • Monthly transfer: roughly 0.5–2 TB/month for a validator. • Ports: – 9000/tcp — P2P (must be reachable from outside) – 8545/tcp — JSON-RPC (keep on localhost or behind an authenticated proxy — never open it publicly) – Metrics/ops HTTP (private network only) • Static public IP: required for validators. Peers connect to you by IP, so you need a stable reachable address. NAT/dynamic IP is only OK for a non-validating node. • Keep latency to other validators low — the 3s block includes a full voting round-trip. Uptime • The network tolerates up to ⌊(N−1)/3⌋ validators offline at once without stopping. • No enforced minimum, but target 99%+ — downtime = missed blocks and missed rewards. 🔐 Slashing — read this carefully • Going offline is NOT slashable. You lose rewards, you do not lose stake. • Double-signing IS slashable: 5% of stake + your validator is tombstoned/jailed. • The #1 cause of accidental slashing is running two nodes with the same validator key. Never run a “hot spare” or a backup node with the same key. Never restore your key onto a second machine while the first is still running. One node per key. Always. Key storage & backup • The validator key is a secp256k1 key file — permissions 600, owned by the node user, generated offline, encrypted at rest. Never commit it to git or bake it into a Docker image. • Back up your key + config offline and encrypted. That backup is for rebuilding one node after a disaster — not for running a second node. • The chain database does NOT need backups — it re-syncs from peers if lost. Other requirements • Validators need at least 2 Polygon RPC endpoints (dedicated/archive recommended — free public RPCs get rate-limited). Block production keeps running even if Polygon is fully down; only bridge/checkpoint functions pause. • Building from source needs Rust 1.92.0 + build-essential libssl-dev libclang-dev clang cmake m4, or just run the container image.