Shardeum Documentation
EcosystemAdvanced Operations

Validator Rewards & Key Security

Understanding how validator rewards work and how to keep your keys secure are fundamental aspects of being a Shardeum node operator.

Validator Rewards

As a validator, you earn rewards in SHM for actively participating in network consensus, processing transactions, and helping to secure the network.

How Rewards Are Earned:

  • Active Participation: Rewards are primarily earned when your node is in the active state. Nodes in standby, syncing, or other states do not typically earn rewards.
  • Cycle-Based: The Shardeum network operates in cycles. Rewards are calculated and distributed based on your node's uptime and performance during these cycles while it was active.

Claiming Rewards:

  • Currently via Unstaking: As of the recent testnet/stagenet versions, the primary way to claim your accumulated rewards is by unstaking your node. When you successfully unstake, both your principal stake and any earned rewards are returned to your nominator wallet address.
  • Future Mechanisms: Shardeum plans to introduce mechanisms to claim rewards without needing to fully unstake the node. Keep an eye on official announcements for updates on this feature.
  • currentRewards Field: The operator-cli status command shows a currentRewards field. This should reflect the rewards your node has accumulated since the last claim (or since it started if never claimed).

No Rewards Generated?

  • If your node was stopped or spent all its time in standby without becoming active, it would not have generated rewards.
  • Network issues or very low network activity (on testnets) might also impact reward generation if there are few transactions to process.

Key Security: Protecting Your Assets

You'll interact with two main types of private keys. Protecting them is critical – if they are compromised, you could lose access to your staked SHM and rewards.

  1. Validator Node Private Key:

    • What it is: This key defines the identity of your validator node on the Shardeum network. It's unique to each validator instance.
    • Storage: When a validator node starts for the first time (without a PRIV_KEY environment variable set), it generates this key pair and stores it in a file named secrets.json (usually located in the /home/node/.shardeum/ or /home/node/config/ directory inside the Docker container). This directory is what you map as a volume in your docker-compose.yml.
    • Security:
      • Backup secrets.json securely! If the host machine fails or the Docker volume data is lost, having a backup of secrets.json allows you to restore your validator's identity on a new machine/instance by simply placing the file in the correct mapped volume before starting the new node.
      • Do not share secrets.json or its contents.
      • The validator software uses this key internally to sign messages and participate in consensus.
  2. Nominator (Staker) Wallet Private Key:

    • What it is: This is the private key of the regular Shardeum wallet address from which you send SHM to stake on your validator(s). This wallet receives the unstaked SHM and rewards.
    • Usage: You provide this private key to the operator-cli when you run stake or unstake commands. The CLI uses it to sign the staking/unstaking transaction on your behalf.
    • Security:
      • This is your main SHM wallet key – guard it like any other crypto private key!
      • Never store it directly in scripts or in plain text on servers if possible.
      • Using Environment Variables (with caution): While the operator-cli can accept the private key via an environment variable (e.g., export KEY1="your_private_key_hex" then echo $KEY1 | operator-cli stake ...), be aware that environment variables can sometimes be logged or be accessible to other processes on the system if not properly secured. This is more for automated testing or very controlled environments.
      • Interactive Prompt: The operator-cli will prompt you to enter the private key if it's not provided via an environment variable. This is generally safer for manual operations.
      • Hardware Wallets & Secure Storage: For significant amounts of SHM, consider best practices for private key management, such as using hardware wallets for your main funds and only transferring what's needed for staking to a hot wallet whose key is used with the CLI.
      • Dedicated Staking Wallet: Consider using a dedicated wallet address (and thus private key) solely for staking operations. This can help isolate risks.

Key Management for Your Platform (Node-as-a-Service Providers):

If you are building a platform to manage nodes for customers, the security of their nominator wallet private keys (if you handle staking/unstaking on their behalf) and the validator node secrets.json files is paramount.

  • Encryption: Private keys (both nominator keys and the contents of secrets.json) should be encrypted at rest using strong encryption algorithms (e.g., AES-256-GCM).
  • Master Key Management: The master key used to decrypt these stored private keys must itself be protected.
    • Avoid storing the master key on the same server as the encrypted data.
    • Consider solutions like Hardware Security Modules (HSMs) or other secure key management services.
    • If a master key must be entered manually (e.g., "typed manually in a safe and hidden prompt when the program is started"), ensure the process is secure and the key is only held in memory by trusted processes.
  • Least Privilege: Ensure that processes handling keys have the minimum necessary permissions.
  • Audits & Best Practices: Follow industry best practices for key management and undergo security audits if handling customer funds or keys.

By understanding how rewards work and diligently protecting your private keys, you can contribute to the Shardeum network securely and effectively.

On this page