Technical Specifications
A detailed review of the security systems, bare-metal server specs, zero-downtime upgrade loops, and network parameters powering GTSTAKING.
A detailed review of the security systems, bare-metal server specs, zero-downtime upgrade loops, and network parameters powering GTSTAKING.
To secure nominator stakes while actively participating in governance, GTSTAKING splits funds and utility into a dual stash-proxy setup:
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.
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.
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.
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.
When a Polkadot substrate node upgrade is released, we perform a manual server migration cycle to maintain validation duties without interruptions.
We download and install the new release on Server B (Backup). We run telemetry checks, monitor substrate logs, and verify synchronization.
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.
Both servers run simultaneously for 12 hours. We monitor Grafana panels and verify blocks are being produced and signed on the new node.
Once validation performance on B is stable, Server A (Primary) is stopped, upgraded to the new release, and set to active standby status.
Validator nodes must remain isolated from external network scans to prevent DDoS attacks and intrusion. Our firewall rules strictly restrict input:
We use a layered monitoring structure to verify server resources, hardware health, and blockchain-level validator status: