Introduction
Following multiple forum discussions on network security and decentralization, we reviewed community feedback and structured it into a set of actionable enhancements.
A first forum post, published last week, focused on identity verification and assessing provider independence.
In this second post, we propose a comprehensive set of standards for node providers—covering maintenance transparency, data center requirements, minimum node thresholds, provider backgrounds, and “skin in the game” commitments—to strengthen network operations and promote decentralization.
Because these measures are broad, certain details are still being refined. This post should serve as a starting point for further discussion within the ICP community. In addition to these standards, we also present a few supporting measures aimed at facilitating effective implementation.
Suggested Enhancements
Maintenance Standards
Criterion: Each node provider must ensure its maintenance is independent of other node providers. To promote transparency and accountability, node providers must publicly disclose the name of any external provider contracted for node maintenance.
In this context, a “node maintenance provider” refers to an entity responsible for providing technical support and having either physical or remote access to the systems. “Independent maintenance” means a distinct, non-overlapping arrangement for each node provider. This can be achieved by engaging a separate third-party maintenance provider or by utilizing a dedicated internal team that is not shared with other node providers.
Rationale:
- Independent maintenance helps ensure that operational control cannot be consolidated under a single entity, reducing the risk of collusion or single points of failure.
- Verifying who performs maintenance is challenging in practice. Publicly disclosing the maintenance arrangement allows the community to hold providers accountable and helps verify that providers are not relying on the same service.
Enforcement:
- If a node provider’s disclosure is found to be inaccurate, incomplete, or misleading, the community (through the NNS governance mechanisms) may initiate actions such as withholding node rewards or revoking node-provider status.
- Providers must update their disclosures if any maintenance arrangements change.
Note: This proposal has a drawback as disclosing the names of node maintenance service providers could expose them to attacks by malicious actors. However, without such disclosure, node providers would not be able to determine which maintenance providers to choose to ensure independence from others.
Data Center Requirements
Criterion: A portion of nodes—especially those in critical subnets—should be hosted in Tier III or Tier IV data centers. Additionally, data centers must not be shared across node providers to ensure that each provider’s infrastructure access is exclusive and does not overlap with others.
Rationale:
- High-tier data centers adhere to rigorous standards for uptime and access control, enhancing overall network security.
- Requiring exclusive use of data centers by single providers reduces the risk of unwarranted access and enhances decentralization. As the ICP network expands, the community may choose to relax this requirement at a later point in time to balance availability and decentralization objectives.
Enforcement:
- The node target topology will define how many nodes in critical subnets must reside in Tier III or IV data centers.
- In future, the usage of Tier III or IV data centers could be incentivized by offering higher node rewards.
- Grant existing node providers a transition period to meet the non-overlapping data center requirement.
The following graph provides an initial analysis of the breakdown of the current node set per Tier Level, with node data sourced from the ICP dashboard. We observe that approximately 45% of the current nodes are located in Tier III or IV data centers. The term “Tier III/IV (design)” refers to data centers that claim their design aligns with Tier III/IV standards, whereas “Tier III/IV (certified)” indicates data centers that have obtained official certification confirming their adherence to these standards.
Note: While data center tiers primarily focus on the resiliency and redundancy of IT infrastructure, they also entail enhanced access control, which is the key concern here. If alternative tiering definitions place a greater focus on access control, these could be considered instead.
Minimum Number of Nodes
Criterion: Establish a threshold of 10 as the minimum number of nodes that a provider must operate.
Rationale:
- The node provider KYC process, including assessing independence, imposes a burden on both node providers and the community. Setting a minimum number of nodes helps balance the administrative overhead compared to the contribution to the network.
- A minimum threshold supports professional and sustainable node management by ensuring providers achieve a critical mass necessary for effective operation.
Enforcement:
- Grant existing node providers a clearly defined transition period of e.g. one year to meet the new minimum node threshold.
- Monitor the node count of each provider to ensure continuous compliance with the established minimum number threshold.
Increase Skin in the Game
Criterion: A portion (e.g. 50%) of each node provider’s monthly node rewards are automatically staked for one year.
Rationale:
- Currently, the network lacks a robust enforcement mechanism beyond stopping reward payments.
- Introducing a stake requirement would create a direct financial incentive for node providers to operate honestly. If they fail to meet well defined (to be established) criteria, their stake could be subject to slashing. For example, the stake could serve as collateral to guarantee the accuracy of the node provider data in self-declarations and the node hardware.
- In addition, this requirement ensures that node providers maintain a long-term financial commitment to the network, aligning their interests with the ecosystem’s success.
- Why stake only a portion? Node rewards are determined in XDR to cover fixed monthly expenses such as internet connectivity and data center space, independent of the fluctuating ICP price. To cover these payments, a portion of rewards should be paid out in liquid ICP. Consequently, only the remaining part of the monthly node rewards should be staked.
Enforcement:
- A designated percentage of 50% of each monthly reward is automatically staked for one year.
- Failure to comply with network standards (e.g., incorrect self-declaration data) would trigger a slashing process, whereby part or all of the staked amount is forfeited.
Note: The data structure for automatic staking would need to be defined. Using a neuron offers the advantage of enabling governance participation and providing voting rewards, but it does not support slashing. As an alternative, a staking pool could be considered, which would facilitate a delayed payout.
Node Provider Backgrounds
Criterion: During the onboarding process, node providers must submit a comprehensive summary of their background, detailing their interest in and motivations for joining the network, as well as their potential contributions.
Rational:
- There was a debate about setting specific background criteria for node providers to ensure effective contributions to the network.
- Given the varied ways individuals can contribute, such as building projects, engaging with the community, or supporting other initiatives, establishing strict criteria is challenging.
- Instead, it is suggested that new providers detail their relationship with and interest in the ecosystem during the onboarding process.
Enforcement:
- The approval or rejection of node providers based on their backgrounds will be determined through NNS voting.
Supporting Measures
In addition to the above minimum requirements we should consider the following supporting measures
- Audits:
- To enforce the above requirements and to verify node data, consider introducing periodic audits, e.g., data center audits. Before introducing system-wide audits, a pilot could help assess feasibility, refine the audit process, and address potential challenges.
- Educational Resources:
- Evaluate the need for enhanced node provider documentation and potential training sessions (which can also be community led) to help providers fully understand their responsibilities and adopt best practices.
Next steps
We kindly invite the community to provide feedback on the proposals outlined above. Please note that several elements are still being refined, and your input is crucial in shaping these proposals.
Additionally, we plan to discuss these suggestions at the upcoming node provider working group meeting on April 14, 2025.
Once we have reached a conclusion, we intend to formalize it through a motion proposal.