Decentralized Nodes Rules

Process

The operators can apply with up to two nodes per network, but that doesn’t create an obligation on the number of nodes, if any, that will be selected. Each cohort will be nominated for a four-month term.

The selected nodes and a set of backup validators will be announced per cohort. In case any of the selected nodes lose their nomination during their term or additional nominations become available, the backup validators will be contacted. They must declare their availability within 24 hours. The selected backup node(s) will be nominated for the rest of the current term, and for the whole next term, provided there are less than 2 months remaining in the current term.

A node that has been selected to participate in a cohort may be selected to participate in a next one as well. For each additional term after the first, their maximum allowed commission will be reduced by 1%. The maximum number of terms a node may be selected is 3, and these don’t need to be consecutive.

The following rules, as well as the processes described above, may be updated from time to time. Any changes will be announced in the relevant channels. Continued participation in the program implies acceptance of these changes.

Rules

• The node operators must comply with the Terms & Conditions of the program at all times.
• Each validator must have a minimum self-stake of 7500 DOT on Polkadot and 150 KSM on Kusama.
• The validator can charge a commission of up to 5% on Polkadot and 15% on Kusama.
• The validators’ reward destination should be set to “staked.”
• If the operator applies for Polkadot nodes, they must apply for the same number of Kusama nodes. As an exception, if the validator already has the necessary number of Kusama nodes continuously in the active set and they don't wish to apply for more, they can use their existing nodes to cover this requirement. They still need to fill out in the application the specifications of their Kusama nodes and mention that the nodes are already in the active set.
• The nodes must be connected to the dedicated telemetry endpoint, with verbosity 1. Use the following parameter during node startup: --telemetry-url "wss://telemetry-backend.w3f.community/submit/ 1"
  • If connection to the public telemetry is still desired, the command should look like the following: --telemetry-url "wss://telemetry-backend.w3f.community/submit/ 1" --telemetry-url "wss://telemetry.polkadot.io/submit/ 0"
• No data should be hidden from telemetry. More specifically, the nodes must share at least the following information:
  • Hardware specs (CPU, RAM, Core count, and whether the machine is a VM)
  • IPv4 & IPv6
  • Client version
• The nodes must meet the minimum hardware requirements described here.
• Each node must be run on a separate machine. An exception can be made to host one Polkadot and one Kusama node on the same machine, provided the server has the required resources to support them, and this setup is adequately justified. Two Polkadot nodes or two Kusama nodes on the same machine is not allowed. This includes nodes running independently of the program.
• The validators must never have been slashed or be slashed in the future. The only exception is if the slash was due to a client bug or a general network issue and was/is deferred by OpenGov.
• Validators that have been active in the past must have consistency in their era points with active and average era points around the median value of other validators in the active set.
• The validators must have an updated on-chain identity on each chain they’re applying for. The operator must update their validators’ on-chain identity as soon as possible, should any of their information change. The on-chain identity should contain at least the following information:
  • Email
  • Matrix handle
• The node operators must respond within 24 hours to nominators and generally DOT/KSM stakeholders contacting them, provide adequate answers to any queries, and be forthcoming about their setup and operations.
• The nodes must be updated to the latest client version within 24 hours after it’s released. It’s the node operator’s responsibility to monitor for new releases.
• The node operator must monitor their nodes to ensure their uninterrupted and smooth operation.
• The validators should pay out staking rewards within 72 hours after the era ended at the latest.
• The nodes must not be hosted on any of the following blacklisted providers:
  • Hetzner
  • Contabo
• The operators will be added to a dedicated Element room. They must respond to DMs or tags in the room within 24 hours.
• Directors, legal representatives, and UBOs of for-profit legal entities applying for the program cannot apply as individuals too. Any such applications will be automatically rejected in favour of the company’s application.
• Node operators must operate their nodes themselves; they may not be run by a third party or staking provider.
• Node operators must have the necessary system admin and security knowledge to effectively and securely run their node. Relying on other people for systematic guidance to set up or run a node, either in the public channels or privately, is prohibited. Companies hiring DevOps personnel for this task are exempt.
• Node operators cannot rent infrastructure from other participants in the program.
• Node operators are prohibited from borrowing the funds for their operations or lending or gifting funds to other participants for this purpose.
• The node operators must be available for a call (in English) if requested, during which they may be asked questions about or be asked to provide proof of their operations.
• The node operators must have completed the KYB/KYC process. During the KYB/KYC process a VPN must not be used, otherwise the application will be rejected.
• Web3 Foundation and Parity employees/service providers are not allowed to participate in the program.
• If a participant decides to leave the program, they must notify Web3 Foundation via email at validators@web3.foundation at least a week before taking down their participating nodes.

Not adhering to any of the above rules during a node’s term may result in the immediate and potentially permanent removal from the program of the specific or all participating nodes of the offending operator.