Decentralized Nodes Processes & Rules

Application Process

  • The operator must have successfully completed KYC or KYB before applying to the program. Any applications without an “Approved” KYC/KYB status will not be considered.
    • During the KYB/KYC process a VPN must not be used, otherwise the application will be rejected.
    • If KYC/KYB has been successfully completed in the past, it doesn’t need to be done again, unless any of the provided information has changed.
  • Companies, organizations, or DAOs must specify a single person who will be managing the node. This person should be the one to fill the application form and will be the representative of the entity in the program.
  • The operator can apply for either Polkadot, Kusama, or both.
  • The operator can apply with up to two nodes on Polkadot and five nodes on Kusama.

Selection Process

  • An operator’s nodes for each network will be evaluated as a group, which means either all their nodes for a network will be selected or none of them.
    • Example: Let’s say an operator applies for 2 Polkadot nodes and 3 Kusama nodes. For Polkadot either both their nodes will be selected or none of them. Similarly, for Kusama either all 3 nodes will be selected, or none of them. The two networks will be evaluated independently.
    • The evaluation happens with an AND condition, meaning the worse node in the group will determine the selectability of the whole group.
    • An exception might be made and less nodes might be selected from an operator if there aren’t enough remaining nomination slots to select the whole group.
  • The two networks are evaluated independently.
  • The evaluation will be done based on the "Selection Criteria" below.
  • There is no cap to the number of cohorts an operator can participate in.

Timeline

  • The applications will remain open until Wed March 5, 2025 23:59 CET.
  • The selected operators per network will be announced on Fri March 14, 2025.
  • The nominations will be issued on Mon March 17, 2025.
  • The nominations will remain the same for the full four-month term. No new nominations will be issued during the term, unless circumstances change dramatically.
  • The program will not evaluate a node’s “independence” (i.e. whether a node has accumulated enough nominations to be in the active set without the program’s nomination)
    • Any participant that believes any of their nodes have become independent can apply with different nodes in the next cohort.

Selection Criteria

Hardware

  • Hardware specs: Nodes must meet the minimum requirements on the Polkadot documentation.
  • Performance: This applies to nodes that have been active in the past.
    • The average paravalidation score of the node in the previous 4 months.
    • Any slashing events in the previous 4 months.
  • Benchmarks: Node performance based on the machine benchmarks.

Diversity

  • OS used: Less used operating systems will be favoured.
  • Node location: Less saturated countries and regions will be favoured.
  • Node provider: Less saturated host or ISP providers will be favoured.
  • Diversity in hardware setup: Less common hardware setups will be favoured.

IMPORTANT: Find here a list of countries, regions, providers, and hardware setups to avoid or prefer.

Operations

  • Responsiveness: Participant’s responsiveness to DMs and emails (this applies to participants of the first cohort).
  • Experience:
    • Documented sysadmin experience in the application with references
    • Practical experience in running validators or collators
    • Previous participation in DN or 1KV
    • Session key handling
    • Monitoring and security operations
  • Telemetry: Node must have uninterrupted connection to the dedicated telemetry (this applies to participants of the first cohort).
  • Adherence to rules: Whether the participant adhered to the program rules (this applies to participants of the first cohort).
  • Adherence to declared: Whether the node’s information through telemetry agreed with the information provided in the application or any updates thereafter (this applies to participants of the first cohort).
  • Enterprises: Professional staking providers that employ a DevOps team have higher chances of being selected.

Ecosystem affinity

  • Ecosystem participation: Overall contributions to the ecosystem in any meaningful form (guides, apps, ambassadors, etc.), participation in the community, etc.
  • Technical contributions: Contributions to issues, in technical/validator channels, etc.
  • Program contributions: Contributions to the program through tool development and other meaningful participation. This applies both to previous/existing contributions as well as planned contributions, both from existing and new participants.
  • Hodling: Long term DOT hodlers and operators who don’t sell (all) their staking rewards will be favoured.
  • OpenGov participation: Meaningful participation in OpenGov.

Other

  • New joiner bonus: New applicants (that haven’t participated in the previous cohort) will be favoured.
  • Backup nodes inclusion: Backup nodes of the first cohort that were nominated with less than 2 months remaining in the cohort or were skipped not due to violation of rules, will be selected for the second cohort, unless the DN Committee deems their application inadequate.
  • Newcomer bonus: Participants with no or little previous Polkadot affinity that join the program will be favoured.
  • Kusama participation: Operators who apply for Polkadot node(s) and with five nodes for Kusama will be favoured for the Polkadot application, provided their Kusama nodes are selected.

Rules

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.

  • The node operators must comply with the Terms & Conditions of the program at all times.
    • Violation of the Terms & Conditions will result in the immediate removal from the program and disqualification from any future cohorts.
  • Each validator must have a minimum self-stake of 7500 DOT on Polkadot and 150 KSM on Kusama.
    • If the operator participates with two Polkadot nodes or five Kusama nodes the minimum self-stake per validator becomes 6000 DOT and 100 KSM respectively.
  • 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.”
    • Alternatively, the validator can set the reward destination to "stash" if they have a self-stake of 11500 DOT or 250 KSM.
    • If they are participating with two Polkadot nodes or five Kusama nodes, the above requirements become 10000 DOT and 200 KSM per validator respectively.
  • 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"
    • The dedicated telemetry is private. If the operator wishes to make their setup public they should mention this in their application. In that case their node names will be published and the command should be:
      --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
    • Benchmark results
  • The node must not use any method (VPN, proxy, etc.) to obfuscate its true location. The use of VPN to connect to the node for its management is allowed and encouraged.
  • The operator must not use the same node (telemetry) name for multiple nodes. Any backup nodes should have a distinct name.
  • The nodes must meet the minimum hardware requirements described here.
  • The minimum Linux kernel version must be 5.16, as described here.
  • Any scheduled changes to the nodes’ declared details or operations must be communicated in advance to the DN Committee at validators@web3.foundation and receive approval. Any unscheduled changes (e.g. due to hardware failure) must be communicated as soon as possible and should be short-lived.
  • The node operators should avoid frequent changes to their nodes’ setup or operations.
  • If the node gets slashed or loses significant rewards (based on prolonged poor paravalidation performance), the node operator needs to reimburse Web3 Foundation and all other nominators during that time for the slashed amount or missed rewards.
  • 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 as well as emails from the DN Committee 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.
  • 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 an operator's term will negatively impact their future prospects in the program and in cases of egregious violations may result in the immediate and potentially permanent removal from the program of the offending operator.