Enhancing Network Decentralization - Proposals for Node Provider Standards

Governance
1

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.

1600×1243 129 KB

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.

12 Likes
2

Hey @bjoernek thanks for this summary. It should help generate a lot of discussion. Here are a few questions that come to mind immediately:

  1. For data centers where there are currently more than one node provider already, who gets to decided who will stay and who will have to be relocated? Will the NNS pay for relocation since the business decision each node provider made to enter into the contracts with the data center were signed before this new rule was established?

  2. I can imagine there may be a lot of node providers who don’t want to own 10 nodes or more or who don’t want 50% of their remuneration staked for 1 year or who will struggle to find fully independent maintenance support. There are many reasons here why we may lose node providers. At what point do we need to start thinking about back filling new node providers? Who gets to decide who will be allocated those node slots? How much turnover would be considered too much turnover? Would new node providers be required to use the same Gen1 or Gen2 specs or could they follow new specs?

2 Likes
5

This is wonderful news. Exactly what needs to be done.

@wpb

  1. Obviously there will be a ‘grace period’ to allow transition. Considering the whole goal of the IC is decentralisation I don’t see why anyone would oppose this. A quick google search shows there are approximately 8-9k data centres in the world. This really is not a major ask. As to the costs, I assume it will be something that is worked out on a case by case basis.

  2. Why would a node provider not want to have at least 10 nodes? It seems counter productive. If you have the expertise and the ability to host the very specific systems that the IC requires, I would imagine you would want to optimise as much as possible. Maintaining one or two nodes just doesnt make sense. This isnt a mom and pop shop we are talking about here, it is the future of technology!

It would certainly be easier to maintain security if you had an entire racks worth of equipment as nobody else would ever have to access your machines. I am sure that if existing node providers no longer wish to carry on, there will be more than enough people willing to step in.

As to who that is, it should be someone who goes through the new kyc process and is willing to put skin in the game and has the expertise required to manage their equipment.

For specs, it seems only logical that any new providers would have to adhere to the latest standards. Why would you want people to onboard with outdated tech?

All in all though, fantastic progress, very positive steps!

5 Likes
6

Thank you for the quick feedback, @Thyassa and @wpb! Regarding the non-overlapping data center requirement, I agree that a transition period should be applied, similar to the one for the minimum number of nodes. I have updated the original post accordingly.

In addition, in data centers currently hosting multiple node providers with few nodes each, ownership of these nodes could be transferred to a single node provider (subject to not exceeding 42 nodes).

2 Likes
7

Thanks for this @bjoernek, looks very promising in general.

Could I confirm if this is meant on a per subnet basis (which is already the case), or if this would be a network-wide restriction (requiring a lot of node relocations).

Update 1: I see you’ve just answered Wenzel and Donna on this. Sounds like it’s the latter. This approach could be both good and bad for IC Target Topology achievability. If Node Providers sell off their nodes to another provider already in that data center as you suggest (but which one? who gets to stay? - Wenzel’s point), it’s likely to make the IC Target Topology less achievable :-1:. If they instead move their nodes to other data centres, it will make the IC Target Topology more achievable :+1: (but still, which ones should be forced to move? The ones with fewest nodes in that data center?).

Update 2: Actually, I’m not confident about my statements above. I think what I mean is, the effect on IC Target Topology achievability seems like it could be nuanced - in any case, I like what’s being proposed.

This is interesting. I’d been toying with this sort of idea as a means of making PoS more accessible, but I assumed it would be unpalatable for node providers. It could be worth considering significantly extending the one year (i.e. max stake) while reducing the percentage that is allocated into that stake. Voting rewards should certainly be disbursable, otherwise the Node Provider’s only sensible option is to start dissolving immediately. I would prefer to see some Node Provider’s choose to build the size of their stake. In the future, Node Providers that have managed to accrue up to a certain threshold could be eligible for including in higher security subnets, potentially benefitting from higher rewards. I’m just thinking out loud. I certainly think there are a lot of avenues with this sort of approach.

In terms of slashing, I think this could be supported without too much work. These neurons should be controlled by the NNS governance canister (much like NF neurons), while the NP would have a hotkey {actually Neuron Management followees would be a better approach given that NPs aren’t always individuals, but teams }. This allows the NNS to split neurons and mark a neuron as forfeit (the ICP would be burnt after dissolving). Again, just thinking out loud. Dispersibility of the rewards would still need addressing.

3 Likes
8

I’m thinking along the lines of a comment that @EnzoPlayer0ne made a while ago which I liked

2 Likes
9

A few more questions and comments come to mind after studying these details a bit more.

Is it correct to assume that node maintenance service providers can be companies and do not necessarily have to be identified by personal name? Would it also be correct to assume that the same company cannot provide service to more than one node provider even if there are different people who work for the company providing the service to the difference node providers? How and where should the node provider reveal the names of their node maintenance providers and how will it be updated if it changes over time?

A quick search of current node providers reveals that 24% (23 out of 95) of node providers currently have less than 10 nodes. So this threshold might be considered a sizable change to a fair number of them. These node providers own a total of 116 nodes currently, but if all of them want to comply with this requirement, then we would have to allow them to onboard 114 additional nodes. These would be new nodes that didn’t exist previously and they would have to onboard with the latest node specs, which are paid at a higher remuneration rate. This amounts to a 9% increase in node machines over the existing 1328 node machines that are getting paid remuneration. Perhaps I misunderstood, but I thought that we generally felt we already have more than enough nodes for all the subnets that exist. Does the benefit of this minimum threshold outweigh the cost?

Is this intended to be retroactive where all current node providers are required to submit new proposals outlining their backgrounds? When do you suggest that these background statements are published? Should we target the month of May? June? Just trying to get a sense of timeline. What happens when the NNS rejects an existing node provider who has made in investment in the nodes and signed data center and ISP contracts based on the previous rules?

I generally agree and think that most node providers will as well. I’m just curious how these changes might impact existing business decisions that were made by node providers prior to these new rules. For example, I suspect that many node providers may not be skilled enough to provide the node maintenance themselves. The rules didn’t require them to be, so they spent a lot of money to buy the machines and hired others to provide the setup and maintenance. There is nothing inherently wrong with this approach. However, with a new rule that a maintenance provider can only service one node provider, it means we may find a big gap in the number of maintenance service providers that are available to support the network. I don’t know if this will be a problem or not. Hence, I look forward to learning what the node providers think.

Yes, I agree that we need to be sensible about it and working something out on a case by case basis would make sense. I think we need to be empathetic to each situation and work with node providers to comply with these new rules as much as practical.

Generally, I agree with this as well. There must be a reason why 24% of current node providers don’t have 10 nodes already. The average number of nodes owned by this 24% of node providers is only 5 nodes. I would jump at the chance to add 5 more nodes if I were a node provider already, but it may not be so simple. It may also be hard to justify from a business perspective if all of your investment returns (50% of the remuneration) are tied up for 1 year. A lot of folks may see a huge opportunity cost associated with locking up those returns that isn’t worth the extra investment.

1 Like
10

And node provider onboarding has been closed for some time, this may be the reason why people have fewer nodes than 10, so would we now allow existing node providers to add more nodes to get to 10? Rather than letting new people come in?

And personally I don’t like the ex post facto nature of these proposals. People invested based on existing rules for a 4 year period, if rules can change in this kind of significant manner any time this adds a lot more risk for the type of high hardware cost investment.

Another aspect is that relocation and potential sale of nodes in different markets will be very difficult for some node providers in certain markets. Sure, Europe and US, not so much. But weren’t a lot of Gen2 node providers onboarded under the mandate of geographic decentralization? We then added people in like Argentina, Sri Lanka etc, there would be super high shipping and import costs and very few other data centers to consider and much fewer people able to operate in these markets. If they wanted to sell their nodes under this process they would likely not find many buyers either. This would be quite an unequal process.

I would encourage that people are allowed to finish their 4 year term, like Gen1 node providers were allowed to do, before new rules are set for them.

2 Likes
11

And just to clarify, I am not against adding rules around disclosures etc. But making people either invest more to get to 10 nodes or divest if they cannot, I don’t think this is fair before the 4 year period ends.

12

I’m fully on board with KYC and IDC up to Tier 3 and 4. What feels unfair, though, is changing the terms of the 4-year rewards contract and downgrading nodes—just like @snoopy mentioned.

Staking 50% of rewards or tying rewards to staking just doesn’t work, especially for APAC regions. Let me explain why. Importing and shipping alone adds 30–40% to node costs in places like Colombo. On top of that, proper Tier 1 internet (not your mom and pop cafe WiFi) costs around $1,000/month for 100Mbps in places like India, South Korea, and Colombo.

ICP originally rewarded based on real Opex costs based on country, which encouraged global decentralization. That worked—unlike some chains that ended up centralized in Hetzner or Contabo. If decentralization is still the goal, you can’t ignore geopolitics and expect to cut down rewards for staking.

Most of us aren’t here to run nodes at a loss. And with AI ramping up, future nodes using H100s or H200s will cost ~$900K - retail. Why would anyone run that kind of hardware on ICP for just for 50% of ICP rewards, when there’s massive demand elsewhere in Web2 and AI?

Let’s focus on the real problem before reshaping the whole ecosystem.

4 Likes
13

Thanks for this context. Another thing to note that applies to anyone in the context of having to move nodes to new data centers: there is one-time setup costs in data centers when you first set up your nodes there. Racking costs, cabling etc. This amounts to thousands of dollars. Shipping costs even within Europe and US of hardware that weighs 20kg per server is also not insignificant. Not to mention that node providers have data center contracts, presumably for the 4 year period, and there would be early termination costs for sure.

2 Likes
14

Yes another part is, all of these contracts are signed 4 years with ISP and IDC. There are penalties on early termination. So once an NP contract of 48 months was signed digitally by the community onchain gets revoked on entire difference reason it seems unfair. Let me also add in another fact, some NP might have used Loans. This is something any business would do rather than buying off hardware using capital.

2 Likes
15

ICP NNS was designed to terminate misbehaving and colluding nodes. Even the tokenomics of this network was changed multiple times.

Yes Network Nervous System has the capabilities to remove node providers.

Network Security takes Priority over Node Provider Profits. I haven’t seen DFINITY starving any NP. This is basic maths. Its a voluntary step and the risks involved are obvious for any Node Operator. You are always allowed to reapply and wait like the rest of the others. No one is forcing anyone to provide nodes

1 Like
16

Hi :waving_hand:
Just to clarify—I’m already an NP (in case that wasn’t obvious), and I fully agree with everything you’ve said. DFINITY has actually done a great job with NP rewards, and that’s why ICP is more decentralized than most other chains out there.

The points I laid out earlier are just facts to keep in mind if we’re talking about changing the rules. We already have node reduction protocols in place, which I support—bad actors should definitely be penalized.

What I’m saying is, let’s not go back to staking-based rewards. But if we do, then we absolutely need to factor in geographical costs so the reward model remains sustainable and fair across the board.

3 Likes
17

Yes, and this is a decision people would have made based on all the facts available at the time. If the rules would have been different from the very beginning, people would have made different decisions. This type of change would also put a much larger burden on small private node providers than on some VC fund who is node providing. This would set a bad precedent and would also discourage individual node providers from participating in the future, leading to a system where you only have large institutions willing to take the risk. Not what we should aim for IMO, and there are other things we can do to mitigate risks that were identified.

2 Likes
18

If you have a problem you quit, there are plenty of people here willing to follow the new rules for registering NPs

19

There is definitely something wrong with the existing NP rules, so they must be corrected. dfinity should consider the interests of ICP as a whole rather than those of certain NPs

20

There is definitely something wrong with the existing NP rules, so they must be corrected. dfinity should consider the interests of ICP as a whole rather than those of certain NPs

21

How are you thinking about non-overlapping data centers? I took a quick look at the dashboard. Let’s pick Digital Reality data center as an example. There are several data centers in different cities and countries used. I don’t claim to know the corporate structure of Digital Reality and how they run operations in each country, but just conceptually, if someone picked Digital Reality in one city/country, nobody else could choose any other Digital Reality data center? And if this is the case, how would it be decided who can keep a particular data center and who needs to move their nodes?

22

I find all these solutions effective to Enhance network decentralization, but two things that require addressing.

  1. The proposal to increase Skin in the Game to motivate the NPs doesn’t seem like a well-thought-out decision.
  2. You haven’t addressed collusion among existing node providers, which is the most important factor for decentralization.

Alternative solution to motivate NPs to behave.

The proposal to increase Skin in the Game to motivate the NPs doesn’t seem like a well-thought-out decision because,

  1. The main reason is that we’ve overlooked the fact that node providers (NPs) are businesses too, even though NPs contribute far more than just infrastructure. They support ICP’s growth and provide essential infrastructure. Expecting them to stake 50% of their rewards puts their cash flow at serious risk.

  2. Secondly, imposing this kind of restriction on all node providers demotivates well-behaved NPs because of the actions of a minority of bad actors. This will destabilise the entire existing node provider base.

  3. While other networks/chains expect staking, their capital expense is close to zero because they can simply use existing infrastructure providers to run their software. They mostly incur operating costs, which is why staking is reasonable in those cases. In contrast, ICP’s capital expense is substantially higher, and the opex is also significant, especially for NPs in rare locations due to the network’s unique requirements. In other words, node providers have already made a significant stake, even before any additional requirements.

Instead of demanding more staking, We should focus on motivating node providers to protect the investments they’ve already made by reducing their node allocations when they behave badly.

The solution:

Dfinity and the community should treat NPs the same way it would treat a supplier.
First, define clear criteria to distinguish between good and bad nodes.
Second, notify underperforming NPs and give them a set time period to resolve the issues.
If they fail to comply, reduce their node allocation accordingly for each bad node.

Why this solution works:
Over time, this approach will naturally filter out the bad actors, leaving Dfinity with a stronger base of reliable NPs. There are many investors eager to become node providers — Dfinity can leverage this demand to strengthen the network instead of focusing on disciplining the few bad actors.

Addressing collusion

You’ve suggested actions to improve onboarding procedures and to identify collusion. However, what’s missing is a clear set of actions that would be taken if collusion is identified among existing or new node providers (NPs).

For existing NPs:
The community is currently struggling to take decisive action against colluding NPs because collusion wasn’t officially addressed during the initial onboarding process. While it may be unethical to remove them retroactively on that basis, what are your plans to reduce the associated risk?
For example:

  • Removing their nodes from critical subnets
  • Freezing their node allocations to prevent further expansion
  • Banning them from technical initiatives or programs

For new NPs:
Will the node provider documentation be updated to reflect the new rules on collusion, clearly stating that any potential provider found to be involved in collusion will be rejected?

4 Likes