Validator Infrastructure

Technical Specifications

A detailed review of the security systems, bare-metal server specs, zero-downtime upgrade loops, and network parameters powering GTSTAKING.

Wallet Architecture

To secure nominator stakes while actively participating in governance, GTSTAKING splits funds and utility into a dual stash-proxy setup:

Stash Wallet Ledger Hardware Security Module (HSM)
16YwUZyLdeAoe4KmhivGwuuJpBH1US4qkUtXK2V83MVXUy6x
Governance & Staking Proxy Hot Wallet - Transfers Disabled
12WFDBwgui7TNxU6J5mUGZgeWAYKtXBSCxYQnoVmMC7sxP1n

By employing an active proxy wallet, we can vote in governance metrics (Democracy) and manage session keys without ever having the private key of the Stash wallet online. Even if the proxy hot wallet is compromised, **token transfers are impossible**, maintaining total security over nominators' stakes.

Commission Strategy

We have updated our commission rate on Polkadot to **10%**, which represents the network's current mandatory minimum.

Minimum Commission Standard: The Polkadot ecosystem enforces a 10% minimum threshold. GTSTAKING pledges to always remain at the minimum possible fee required by network governance.

This minimum fee provides resources to support high-performance server hardware rents, continuous monitoring infrastructure, and allows us to steadily accumulate self-stake to further secure the validator set.

Slashing & Double-Sign Protection

Our server strategy strictly avoids automated High-Availability (HA) failover setups. Instead, we use two separate server environments and perform node changes manually when necessary.

Why avoid automated HA clusters?

In blockchain networks, running two validator instances simultaneously with the same keys triggers **Equivocation (Double Signing)**. If an automated script misidentifies a node freeze and boots the secondary node while the first is still active, the validator gets immediately slashed by the network for a significant percentage of delegated tokens.

Conversely, the penalty for a validator being briefly unresponsive is extremely minor. Therefore, we prioritize absolute security over minor downtime. In case of issues, a manual, human-validated process handles the migration of session keys.

Zero-Downtime Upgrade Process

When a Polkadot substrate node upgrade is released, we perform a manual server migration cycle to maintain validation duties without interruptions.

1. Independent Upgrade of Standby Node

We download and install the new release on Server B (Backup). We run telemetry checks, monitor substrate logs, and verify synchronization.

2. On-Chain Key Migration

We generate new session keys on Server B and submit the transaction on-chain via the proxy wallet, directing the validator identity to block production on Server B.

3. 12-Hour Dual Monitoring Loop

Both servers run simultaneously for 12 hours. We monitor Grafana panels and verify blocks are being produced and signed on the new node.

4. Primary Server Alignment

Once validation performance on B is stable, Server A (Primary) is stopped, upgraded to the new release, and set to active standby status.

Security & Firewall Setup

Validator nodes must remain isolated from external network scans to prevent DDoS attacks and intrusion. Our firewall rules strictly restrict input:

  • Port 22/TCP (SSH): Restricted access. Logins require cryptographically secure SSH keys protected by heavy passphrases. Root SSH logins are completely disabled.
  • Port 30333/TCP (Substrate P2P): Open to the internet to allow synchronization and peer-to-peer block consensus.
  • Ports 9615 (Prometheus) & 9944 (WebSocket RPC): Strictly closed to the external interface; metrics are polled only through secure private tunnels.

24/7 Monitoring & Alerting

We use a layered monitoring structure to verify server resources, hardware health, and blockchain-level validator status:

  • Prometheus & Grafana: Real-time hardware performance tracking (CPU loads, NVMe read/writes, ECC RAM error counters, temperature metrics).
  • Alertmanager: Dispatches immediate notifications via SMTP/Email for system limits (disk utilization above 80%, system package updates, network anomalies).
  • SubTV & Web3 Alerts: Interactive Telegram bot subscriptions checking validator on-chain metrics (era points, missed block warnings, payout executions).