The one thing we should also think about is what collusion is. The definition of collusion is generally the following: “secret or illegal cooperation or conspiracy in order to deceive others.” From everything I have seen so far, I am not convinced that we have found evidence of that and that there are truly “malicious” node providers. Generally I don’t think “cooperation between node providers” is necessarily “collusion”. Intent matters. We should structure node providing rewards in such a way that the right incentives are set and we should tighten the disclosure requirements to mitigate identified risks.
Thank you, @MalithHatananchchige, for your feedback and for providing specific figures, which is very helpful to make the discussion concrete.
I fully agree that a node provider needs to cover monthly expenses to maintain their nodes. This is precisely why it was suggested to stake only the portion of rewards that corresponds to profit margins. Additionally, you mentioned that the approach should be fair and take regional differences into account due to varying costs in different areas. I also fully agree with this point. The ICP node rewards structure already takes into account the different costs across regions by using a region specific base cost which covers opex and capex (on top of which a margin multiplier is applied).
Hence, could you clarify if your concern is mainly with the specific parametrisation of the proposal—i.e., staking 50% of rewards for one year—or with the overall approach?
I would suggest that this information is stored on-chain, similar to other node related information. As mentioned above, node provider would need to update this information whenever a change in the service maintenance provider occurs.
Just to add something to the mix, I haven’t seen discussion about NP clusters/linkage on this thread (maybe I missed it). I think one of the things slowing that converstation down is the expectation that we need to be comprehensive straight off the bat.
Lets just focus on sorting out the obvious cases first (so we can get something done sooner i.e. business aliases / duplicate identities, and immediate family ties).
If there’s going to be a motion spawned from this thread, I certainly think this needs covering.
My concern lies with the overall approach of the proposal, not just the specific percentage or duration involved. I encourage you to take a step back and consider the broader objective: the goal should be to retain and support good node providers, while implementing fair and effective ways to discourage and remove bad actors.
Why the suggested approach would not work:
The suggestion to stake 50% of node rewards for a year MAY SEEM like a neutral mechanism, but in practice, it creates significant challenges. From a business perspective, asking node providers to wait a full year to see actual profit (after covering ongoing operational expenses) can make the model financially unsustainable. This could unintentionally drive away some of the most committed and reliable operators.
Moreover, many of us have already made substantial upfront capital investments. This in itself demonstrates our long-term commitment and “skin in the game.” Imposing additional financial locks doesn’t necessarily align with the realities of operating in such a capital-intensive environment.
What should be done instead:
As previously mentioned, if the goal is to improve the quality and reliability of the network — which I fully support — a more targeted and effective approach would be to:
Define clear quality standards and expectations for node performance and behavior.
Monitor compliance in a transparent and consistent way.
Enforce consequences: notify underperforming providers, offer them a reasonable window to resolve issues, and reduce or revoke their allocations if they fail to meet expectations.
This kind of structured accountability helps the community to retain high-quality NPs while creating space for new entrants who are willing to meet those standards.
The discussion on dealing with linkages is being addressed in a separate thread, which you can find here. I agree that we can and should handle the linkage topic in parallel to this thread (and that we can proceed in incremental steps).
Yes, I agree with that point, and the standards listed above are precisely an attempt in that direction.
This objective sounds fine, too, but it is quite high-level. I would be very interested in hearing more details about how you specifically propose to set standards and to monitor them.
As stated in the criterion, my suggestion is to apply this rule to the onboarding of node providers, rather than retroactively (unless people believe that this would add a lot of value).
Should the provider have 10 nodes in total or 10 in one data center?
If the provider has fewer than 10 nodes, will you allow it to install additional nodes regardless of the topology, and will these additional nodes also be rewarded?
Let me give you an example: there are two providers that use one data center. Provider A has 10 nodes and Provider B has 10 nodes. How do you decide who will stay and who will be transferred to the other data center?
“Currently, the network lacks a robust enforcement mechanism beyond stopping reward payments.”
i.e. “Current enforcement (stopping rewards) are seen as insufficient.”
But, Why❓
Node providers already face considerable financial and operational risks from current NNS enforcement powers. Mandatory staking adds unnecessary risk without clear benefits. Providers are already strongly incentivized through existing penalties, and further restrictions simply threaten to destabilize their operations.
Key Considerations:
ICP already possesses an extremely powerful enforcement mechanism: the capability to immediately stop rewards or even remove a node provider entirely, strongly incentivizing compliant behavior.
Existing Financial and Operational Risks:
The NNS can halt provider rewards or deplatform an NP entirely at any moment, making it the single biggest threat node providers face.
Immediate consequence: Providers become financially trapped in costly, multi-year obligations with data centers, ISPs, and fiber providers.
Operational penalties: Loss of ICP rewards or deplatforming leaves node providers with significant financial liabilities, including data center fees, contractual obligations, and possible legal repercussions for breach of contract.
Revenue Volatility Risks:
Yes, XDR (Special Drawing Rights) attempts to stabilize compensation; however, that still converts to remuneration ICP tokens. Due to ICP token volatility, providers face substantial uncertainty in revenue, let alone profit.
Providers must manage this volatility to cover stable fiat expenses like data center fees and ISP contracts, intensifying financial risk.
TLDR, The mandatory staking proposal compounds existing risks and instability without clear justification or additional protective measures. Furthermore, placing personally identifiable information (PII) on-chain significantly heightens operational security (OPSEC) risks, exposing providers to unnecessary vulnerabilities. Additionally, imposing sanctions on Node Providers without first establishing clear due process raises concerns about fairness and legitimacy. The introduction of a 50% lockup and slashing also lacks a clearly outlined due process mechanism, further complicating fairness and transparency concerns.
Generally speaking, I’d say we’d be better off spending our brainpower on finding interesting projects to launch on dfinity - and doing them! - rather than trying to limit the income of nodes providers or stackers. The heart of the problem has never been remuneration, but the lack of uses/liquidity/projects on dfinity. Bob has been a band-aid on a bitter wound, and has helped burn some icp, but the problem is really the lack of use of the network today.
Current NP penalties are about limiting their future rewards. This is insufficient to disincentivise a would-be malicious actor (they have no intention of sticking around after executing an attack).
Staked ICP (ideally max staked) gives NPs a measurable and visible long-term incentive to keep the network healthy (and not attack it for significant short term gain).
I think this is so needed that I would support an increase in node rewards if that’s what it’ll take. There needs to be PoS if this network is ever going to see large scale adoption. Node machines are not really stake.
@wpb@Lorimer@Alex43342, you all raised good questions about the proposed single data center requirement and the potential transition process.
Recall that the aim is to limit physical access to nodes, avoiding access across different node providers.
My view on current issues:
In some data centers, multiple node providers only have a few nodes each (even sometimes only one node each). These are probably co-located in the same rack (or at least co-located with non-ICP servers in the same rack). This seems like a security risk and I suggest that this should be mitigated soon.
Data centers hosting multiple node providers, each with their separate racks (e.g. with 14 nodes each), might be less of a security risk as access to the racks can be separated. This seems like something which could be addressed later.
Potential Mitigations (without moving hardware):
For groups of node providers with nodes across multiple locations, a possible solution could be to rearrange ownership so that each node provider consolidates their nodes in one or two locations.
If all node providers in the same data center are part of a cluster (as discussed in the separate thread on node provider independence), this issue might be mitigated as they would be treated as one in the subnet allocation.
Below is a graph showing data centers with less than 10 nodes but multiple node providers. We can see that there are groups which could be consolidated, using the above ideas. I look forward to hearing your thoughts and additional suggestions on this topic.
@Gabriel_Rodriguez@MalithHatananchchige
since you were the first node providers to provide feedback in this thread, it would be great to also hear your opinions on the suggestions related to aspects other than reward staking. Many thanks in advance!
I said this on another forum topic, but some of these situations shown here are probably a direct (unintended) consequence of the Gen2 node reward structure with the reduction factor. I think rather than duck taping ex post facto and looking at a few individual situations, we should think about setting the right incentives going forward in a risk based approach.
And if the concept of clusters is introduced and taken into account for node allocations across subnets, then why are the above situations such a concern? I mean, wouldn’t you just treat them as a cluster anyway?
As mentioned above, having multiple node providers in one data center belonging to a single cluster would indeed not pose an issue. However, the question is how these clusters are precisely determined (see also the discussion in the separate cluster thread where the focus is on UBO and control relationships, but not co-location). Could you please clarify the specific rules you have in mind for forming a cluster?
Overall, I agree that our main focus should be on expanding the ecosystem and developing exciting projects on ICP. However, it is also crucial to spend some time on securing the foundation. Even the most impressive projects would fail if the underlying security is compromised (and hence I think it is important to have this discussion now and derive actionable follow-ups).
I think that thread already made a pretty good start. I have thought about it also, can share my initial thoughts. In general, I think we should rely on self declarations and ask for the following disclosures from node providers - and like someone else on another topic put it so eloquently, I would try to follow a principle of “less is more”, not “more is better”:
Related by blood, marriage, or domestic partnership
Share the same UBO(s) (could refine further about % ownership etc.)
Rely on same technical or operational teams or companies
Are a joint party to a collocation contract or rely on the same collocation contract
I think we need the same type of proof for buying a house, as a cluster of nodes is around the same price.
Imagine what questions your bank asks you when you’re trying to get a mortgage. That’s the kind of hoops that node providers should have to jump through.
Key Considerations:
ICP already possesses an extremely powerful enforcement mechanism: the capability to immediately stop rewards or even remove a node provider entirely, strongly incentivizing compliant behavior.
Existing Financial and Operational Risks:
The NNS can halt provider rewards or deplatform an NP entirely at any moment, making it the single biggest threat node providers face.
Immediate consequence: Providers become financially trapped in costly, multi-year obligations with data centers, ISPs, and fiber providers.
Operational penalties: Loss of ICP rewards or deplatforming leaves node providers with significant financial liabilities, including data center fees, contractual obligations, and possible legal repercussions for breach of contract.
Revenue Volatility Risks:
Yes, XDR (Special Drawing Rights) attempts to stabilize compensation; however, that still converts to remuneration ICP tokens. Due to ICP token volatility, providers face substantial uncertainty in revenue, let alone profit.
Providers must manage this volatility to cover stable fiat expenses like data center fees and ISP contracts, intensifying financial risk.
TLDR, The mandatory staking proposal compounds existing risks and instability without clear justification or additional protective measures. Furthermore, placing personally identifiable information (PII) on-chain significantly heightens operational security (OPSEC) risks, exposing providers to unnecessary vulnerabilities. Additionally, imposing sanctions on Node Providers without first establishing clear due process raises concerns about fairness and legitimacy. The introduction of a 50% lockup and slashing also lacks a clearly outlined due process mechanism, further complicating fairness and transparency concerns.