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 four nodes on Kusama.

Selection Process

  • The two networks are evaluated independently.
    • You may apply for Polkadot, Kusama, or both networks.
    • Operators who apply for Polkadot node(s) with four nodes for Kusama will be favoured for the Polkadot selection (bonus), provided that at least half of the Kusama nodes are selected. The bonus gets bigger if all four Kusama nodes are selected to the program.
  • The selection process aims to increase diversity and decentralization and include as many operators as possible. To achieve this the selection process will be as follows:
    • We’ll reject any applications that scored poorly on each network.
    • The rest will receive 1 Polkadot node and 2 Kusama nodes.
    • Any remaining spots will be awarded to the highest graded applications. Kusama nodes will be distributed in pairs in this way.
  • Still, the nodes for each network will be evaluated as a group.
    • The evaluation happens with an AND condition, meaning the worst node in the group will determine the score of the whole group.
  • 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 for Cohort 4

  • The applications will remain open until Sunday, Nov 23, 2025 23:59 CET.
  • The selected nodes per network will be announced between 15 and 19 of December, 2025.
  • The nominations will be issued on Tuesday, January 13, 2026.
  • The term of the cohort will be five months.
  • The nominations will remain the same for the full five-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 (they won’t be replaced during the cohort).

Selection Criteria

The following selection criteria are applied during the applications evaluation. We strongly encourage you to read more details about them and guidelines in our guide on “How to submit a good application”.

Hardware

  • Hardware specs: Nodes must meet the minimum requirements on the Polkadot documentation. Further details on hardware evaluation can be found in the above guide.
  • Performance: The average paravalidation score of the node during the current cohort.
  • 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.
  • Diverse hardware setups: Uncommon hardware setups, especially CPUs, will be favoured.
  • Decentralization: Operators with independent nodes will be less favoured.
  • Server type: Where the node is hosted, with self-hosting or colocation being favoured.

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

Operations

  • Communication: Participant’s communication with the committee and responsiveness to DMs and emails (this applies to the participants of the current cohort).
  • Technical expertise:
    • 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 current cohort).
  • Adherence to rules: Whether the participant adhered to the program rules (this applies to participants of the current 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 current 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, bounties, 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.
  • 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 applied to previous cohorts) will be favoured. A smaller bonus will be given to applicants who’ve applied before but haven’t been selected.
  • Newcomer bonus: Participants with no or little previous Polkadot affinity that apply to the program will be favoured.
  • Returning participant bonus: Participants of previous cohorts that were not selected in the current cohort will receive this bonus.
  • Kusama participation: Operators who apply with four Kusama nodes will receive a bonus for the Polkadot selection, provided that at least half of the Kusama nodes are selected. The bonus gets bigger if all four Kusama nodes are selected to the program.

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.

General

  • 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.

Communication

  • 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 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 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

Self-stake, commission, reward destination

  • Each validator must have a minimum self-stake of 10,000 DOT on Polkadot and 250 KSM on Kusama.
  • The validator can have a commission of up to 5% on Polkadot and up to 20% on Kusama.
  • The validator’s reward destination can be set to “Staked” or “Stash”.

Telemetry

  • 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, clearly indicating they’re a backup server.

Duties and responsibilities

  • The nodes must meet the minimum hardware requirements described here.
  • The node operators should avoid frequent changes to their nodes’ setup or operations.
  • If a Polkadot node gets slashed or loses significant rewards (gets less than 50% rewards in one era or less than 75% rewards in two or more consecutive eras), the node operator needs to reimburse Web3 Foundation for the slashed amount and/or missed rewards. If the incident is due to a bug this rule won't apply, but the onus to prove that lies with the validator.
    • Node operators may reimburse any other affected nominators at their discretion.
    • Details of the reimbursement will be communicated by Web3 Foundation, but proactive communication about the incident will be appreciated.
    • The above thresholds apply only to missed rewards due to node downtime or underperformance. Missed rewards due to slashing will need to be reimbursed irrespective of these thresholds.
  • 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 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 minimum Linux kernel version must be 5.16, as described here.
  • 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
  • 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.
    • An exception is members of DAOs who can transfer funds to the DAO for this purpose.

Miscellaneous

  • 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.
  • 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.
  • 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.