Secure Node Criteria

Each of the criteria specified below must be met and maintained for a Secure Node to register and remain eligible to receive a share of the dedicated Secure Node reward pool. The reward pool is distributed at the end of each reward period, which lasts exactly 576 blocks, approximately 1 day. The criteria may be added to, or modified at any time.

Balances / Challenges

• Maintain a balance of at least 42 ZEN, held as a stake, within a transparent (t) address where you control the private keys
  • For additional rules and information about updating staking addresses see Change Staking Address
• Maintain a balance greater than 0.001 ZEN in a private (z) address on the Secure Node (a challenge consumes 0.0002 ZEN)
  • Recommended to keep at least 0.02 ZEN in a private (z) address
• Able to perform a challenge in 200 seconds or less
• Must always successfully pass a challenge within the defined challenge interval, currently 72 hours (challenges are sent automatically by the tracking server) or at random times
  • Exceptions are created for failed challenge attempts. Passing a re-attempted challenge will clear the open exception. Failed challenges count against reward eligibility for the duration of the exception
  • Tracking server will periodically issue new challenge requests upon receiving a failed challenge response

Availability / Exceptions

• Meet, with minimal exceptions or downtime (~2hrs max), an availability target of 92% within a reward period
• Not fall behind the current block height by more than 4 blocks
• Maintain and run the minimum required version of zend and tracker software (upgrading within the posted time frame)
• Must dedicate the host for the sole use as a Secure Node and provision the required level of resources (CPU, RAM/SWAP, Disk space) to consistently meet the eligibility criteria
• Must not add, or utilize additional transparent addresses, except for approved applications

• There must not be more than 5 stake balance (stkbal) exceptions in one earning period

• The stake address must not be used by other nodes (Secure or Super) at the same time

• Must send updated stats to the tracking server on the configured schedule or when requested

• Must only run approved nodetracker software

• Must respond to all requests from the tracking server and allow the tracking server to update the node configuration

  • Exceptions will be triggered for nodes not responding from commands issued by the tracking server
• Must provide the nodetracker a valid email to receive alerts and other notifications issued by the tracking server

Network / Security

• Must not restrict peer connections (no maxconnection= in zen.conf)
• Must configure the zend P2P port with valid SSL/TLS certificate reachable from the outside for other nodes to connect to (zend MUST accept incoming connections from other nodes)
• Correct reachable address and port combination are advertised to the network by zend (listed in zen-cli getnetworkinfo "localddresses" and 'reachable:true')
• The Tracking Server must be able to establish a connection to zend directly
• The Nodetracker must establish the outgoing connection to the tracking servers from the same IP address specified in zen.conf (externalip=)
• Only one unique IPv4 or IPv6 is required, but it is suggested to have one of both types to help the network
• The proper DNS record (A or AAAA) has to be in place for the same IP as configured in the zen.conf (externalip=)

Reward Eligibility

(1) Eligibility

• At the end of each reward period the active Secure Nodes are checked for eligibility. Any Secure Nodes with exceptions or downtime reducing their availability to less than 92% of the reward period are excluded from rewards for that reward period
• Reward allocations are created for all non-excluded Secure Nodes, which equate to the maximum reward a single Secure Node can receive for the reward period

(2) Deductions

• Secure Nodes meeting the uptime threshold, 92% of the reward period, with unavailability periods due to downtime or exception, i.e. not 100% availability, will have the reward equivalent of the period for which the Secure Node was unavailable, subtracted proportionally from their allocated reward. This intended behavior rewards Secure Nodes based on their availability and afford the associated transaction fees (for reward payments) and potential credits to be covered by the Secure Node reward pool

(3) Payment

• On a weekly basis, a payment administrator reviews the reward payments to ensure they were generated correctly and marks them to be paid
• Rewards are then sent to the stake address associated with the node. This is the transparent (t) address holding the 42 ZEN stake configured for the node during the earning period. To change the stake address see Change Staking Address

(4) Support

• Any configurations using multiple super or secure nodes within the same OS instance are not officially supported and will not receive support through the help desk

Secure Node Criteria and Reward Eligibility