No, it’s pointless if we can’t get the foundations right (which is what this current movement is about)
I’m aware of all this and not at all out of the loop. I’m following all developments quite closely.
Again what would be the real risk here? How would someone manage to get his 5 nodes voted in replacing current nodes? IF that is somehow managed what is the risk? Is it just halting a subnet? The whole Solana Network halted several times in the past and it didn’t result in much damage. This would be only a single subnet.
If someone goes to all this length to halt a subnet he gets banned with all his nodes over 5 node provider entities and the nodes get replaced by other node providers.
So even if the super unlikely scenario somehow happens the damage would be limited and the threat actor eliminated.
This all sounds like a totally theoretical approach to a very low probability scenario and the proposed measures wouldn’t even prevent a real bad actor. It just gives the false feeling of security since something was done to prevent the theoretical threat.
Beside all these theoretical thought processes there was not a single downtime of a subnet because of the mentioned problems. Why is there after 4+ years of the IC running now a desire to change the fundamentals of the whole system esp. retroactive? There were few forum posts with allegations and not a single one of these was withstanding little bit scrutiny. I could perhaps understand if the process gets improved for new onboarded nodes. But forcing current node providers who onboarded under a specific set of rules and have long term commitments to absolutely insane privacy violations shouldn’t even be entertained. I can clearly tell you that most will just refuse to doxx publicly UBOs and CEOs. Perhaps you personally don’t care about privacy but it is a fundamental right and it was once a core pillar of the whole crypto movement. It’s quite sad to see this fully undermined in this context.
Again this literally tries to set up a banking style compliance department. Banks do this in order to fulfill government regulations and its very costly. Now some community members want to implement government style surveillance willingly on a web3 project? But that’s not all: They also want the collected data to be made public. Like mentioned in my first post perhaps take a few steps back and realize what’s demanded here.
Thank you for speaking up on all of these points. As I mentioned in the last Node Providers working group meeting, it is very important for Node Providers to voice these kinds of concerns. I know that most people don’t want to get involved in messy forum discussions, but it’s necessary in order to help ensure that we end up with Node Provider selection and onboarding rules that adequately take into consideration the concerns of everyone. Other Node Providers need to get involved in this conversation as well. Time is running out.
The whole process started with allegations against several node providers. I think most node providers were following but the risk : reward engaging in these discussions after seeing the attacks on others was just not worth it. Everyone who pointed out that the allegations didn’t have much ground or tried to reason in these discussions was just labeled complicit and attacked as well.
I was personally following it for weeks but didn’t engage exactly because of that. Further more it takes endless time which I normally don’t have.
I literally already answered this question - controlling the consensus of a subnet, and therefore the finalised blocks on that subnet. This means control of the assets residing on that subnet (which should be expected to hold signifcant financial value).
Anyone can influence the distribution of nodes on subnets by proactively responding to offline or degraded nodes and swapping them for good nodes that appear to meet decentralisation targets (and would therefore be accepted by the NNS). I literally feel like a worn-out record.
NPs that require privacy regarding UBOs do not belong on the IC, simply because you cannot verify claims of independence, which is an essential requirement for the IC’s design principles to work.
Ok, to summarize in a subnet of 13 nodes 9 of these nodes need to go offline or degrade over time and then the bad actor could convince the NNS to implement the 9 nodes of his 9 different node providers he controls. This would give him the power over the assets in said subnet.
You try to prevent this via doxxing all node providers and assume the bad actor who’s waiting for this finally to happen would forget to fake his documentation in the independence assessment?
Wouldn’t it be much easier to just make sure at least 5 nodes in a subnet are gen1 nodes which went through KYC/KYB and got approved by dfinity in the beginning? They also proofed that they are good actors for over 4 years by now.
Statements like this make it really hard to believe in the good intentions. Who are you to decide who belongs on the IC?
All gen1 node providers invested significant capital and time before the IC was running. We all believed in the vision even before the network was live. Everyone went through KYC/KYB. Now you say we don’t belong here because the biggest shareholders in the parent companies don’t want their personal data publicly on the internet? I give you the benefit of the doubt that you don’t know what you are asking for.
You can verify claims of independence without making everything public. Like already several times suggested it can be done by a 3rd party. Most likely even in a way more efficient and compliant way.
This is really the last I will write to this point since its absolutely ludicrous.
Fully agree with @DavidB. The only node providers that didn’t go through third party KYC are Gen2 node providers, if that is the concern, then rather than this lengthy list of questions and disclosing ever more details publicly - which just opens another attack vector - we can get a third party to KYC everyone and confirm connections between node providers. This would seem to achieve what is intended while still taking on board the valid concerns raised.
I would also be curious about the following: how many node providers have used the DRE tool to ADD their nodes to subnets? Given there is no incentive to do so, it takes time and effort and risks 25 ICP, I assume there would be a negligible number of such proposals to date, if any. If one would further want to limit the risk of occurrence of this hypothetical scenario that has been outlined, couldn’t the DRE tool be modified to only allow a maximum of [3] proposals in a [30] day period per subnet by a party other than Dfinity to add/remove nodes from that subnet? This would then make it pretty much impossible for anyone to add 5 or 9 malicious nodes to a subnet.
I get the impression that a large number of Node Providers out there aren’t really very technical. They also have no obvious incentive to willingly jump through additional hoops. I think both of these factors conspire to paralyse any sensible discussion on this topic. It’s peppered with self-interested false logic and wishful thinking - and I haven’t got the energy any more to keep pointing this out.
At the end of the day, these measures will need to be agreed by those who actually have a substantial stake on the IC (formal ICP stake), and/or a substantial following thanks to their development and/or governance contributions and technical background.
Several people in this thread — and via other channels — have asked: Why should the Ultimate Beneficial Owner (UBO) of a node provider entity be public? Let me explain the motivation in more detail:
Fundamental security element:
Knowing who the node providers are is a fundamental component of the ICP protocol. Node providers are vetted by the community during onboarding. This transparency — and the resulting accountability — combined with other elements of Deterministic Decentralization, enables the creation of smaller subnets, allowing for ICP scalability. This only works if the ICP community knows who is behind each node provider entity.
Practicability and verifiability of independence assessment:
The UBOs of node provider entities are used to verify the independence of node providers. Some have suggested that UBOs could be disclosed only to the audit firm, which would then check for overlaps between node providers. However, this approach has several practical limitations. It would require a single auditor to review all node providers at the same time — because they would need visibility into all UBOs to detect any overlaps. Furthermore, a single change of a node provider would require a complete re-assessment by the auditor.
Please note that, to address safety concerns, only the legal name and country of residence of the UBO would be required — not their full address.
Thank you to @louisevelayo and @bjoern for co-ordinating the latest node provider meeting. Following on from that I have taken on board the concerns and suggestions that were raised and I think this new set of questions would provide the auditor with specific things to verify, and ensure that there are no intrusive questions presented to any node providers.
Open to feedback on these of course. We all want the same goal here.
Proposals for Identity Verification
Q1: UBO Ownership & Control
Public Disclosure: (forum/wiki)
- Please list the Ultimate Beneficial Owners (UBOs) of the node provider entity, including their full legal names and countries of residence.
- Include any individual who:
- Holds ≥25% direct or indirect ownership; or
- Otherwise exercises control over the entity’s decisions (e.g., through a management position such as CEO, CFO, COO, board membership, a trust arrangement, or other legal agreements).
- If no individual holds ≥25%, list the person(s) with the largest stake.
Private Disclosure: (auditor & Dfinity)
- Provide the latest corporate documentation listing all UBOs.
- Submit a government-issued ID showing each UBO’s name and address. If no such document exists, provide a government-issued ID showing the UBO’s name along with a recent (less than 2 months old) utility bill showing the UBO’s name and address.
- Have any criminal convictions or judgments been made against the UBO(s)? If yes, please provide details.
- If you have been a node provider for 3 months or more, submit a transaction record demonstrating proof of 3 months’ rewards sold on an exchange (along with documentation from the exchange). This should also include a clear trail of those funds being deposited into a bank account in your name or your company’s name.
- If you are unable to provide this, please explain why.
- If you have not sold any of your rewards, provide the addresses where the rewards are stored and a clear trail from the reward payment from the node provider to the relevant addresses for verification.
- If you have been a node provider for more than 1 tax year, submit a copy of your personal or business tax return showing proof of payment of applicable taxes on your node provider rewards.
Q2: Overlap of UBOs with Other Node Providers
Public Disclosure: (forum/wiki)
- Is any UBO of this node provider also a UBO of another node provider?
If yes, provide the legal name(s) of the other node provider(s). - Is any UBO of this node provider an employee of or in a business relationship with a UBO of another node provider?
If yes, describe the nature of that relationship. - Have you transferred any of your nodes to another node provider?
If yes, do you have any business or personal relationship with that/those node provider(s)?
Private Disclosure: (auditor & Dfinity)
- Does any UBO of this node provider provide technical assistance to another node provider?
If yes, do you have physical or remote access to their machines?
Q3: Family Ties
Private Disclosure: (auditor & Dfinity)
- Is any UBO of this node provider directly related (i.e., spouse, parent/child, sibling) to a UBO of another node provider?
If yes, specify the relationship(s) and the node provider(s) involved.
Q4: Corporate Structure
Public Disclosure: (forum/wiki)
- Is your company currently active and in good standing?
- Was your company created solely for the purpose of becoming a node provider?
- If not, what other activities does/did the company undertake?
- Are there any holding companies, parent companies, or subsidiaries that also have stakes in other node providers?
If yes, specify the relationship and the node provider(s) involved.
Q5: Overlap of Financing
Public Disclosure: (forum/wiki)
- Does any individual or entity providing loans or debt financing to this node provider also finance (or hold a significant stake in) any other node provider?
If yes, name the other node provider(s) involved.
Private Disclosure: (auditor & Dfinity)
- If the node provider uses debt financing, identify the ultimate beneficial owners behind the lending entity.
- Provide all relevant documentation regarding the debt.
Thank you for the detailed feedback, Donna!
I will take a closer look tomorrow (when I also plan to draft the motion proposal).
A few quick comments upfront:
- As per the discussion, the auditor’s role would be to verify the correctness of the public statement — meaning all required documentation and checks should directly support the public disclosure.
- To preserve decentralization, I believe DFINITY should not receive any private documentation. However, we can involve more than one auditor.
- As per the design of the questionnaire, I suggest we focus on the UBO concept for now so that we can kick-start the motion & pilot (and I agree that additional points should be addressed in the second thread on node provider standards).
A further thought following yesterday’s working group meeting: I agree that it makes sense to drop the open question Q6 on “other relationships” for the time being, so we can move forward with the pilot focused on the UBO concept. In parallel, we can continue discussing the other topics related to node provider standards in the separate thread.
I just thought 6 was a bit vague, just ask the questions you want to know directly.
Having an auditor have sight of tax returns and a clear chain of the funds going from the rewards to a bank account in the UBOs name should be proof enough of who actually controls the nodes.
That is really what the goal is here right?
What if the node provider decides to not sell their ICP?
You just need to have proof, which should be easy. There are some NPs that haven’t sold a penny, they just lock it up. You can trace from the reward address to the storage address.
Nothing wrong with that.
I suggest that we verify during the pilot what kind of corporate records are required for the auditors to confirm the listed UBOs.
Is anyone able to offer some clarity on these technicalities?
If a single node provider has a 24.9% share in all of the other node providers on the network, would that be okay (for argument’s stake)? If not, what about that would make it not okay?
Owning 25% or more of a company’s shares typically grants substantial influence over decisions, such as voting rights or board appointments, making it a reasonable indicator of beneficial ownership. It suggests the individual has enough control to potentially exploit the company for illicit purposes.
Setting the threshold at 25% avoids overburdening companies with reporting requirements for minor shareholders while still capturing those with meaningful control. Lower thresholds could lead to excessive administrative costs and complexity, especially for companies with many small investors.
It needs more than simply an incorporation document. Anyone can create a company. Delaware llc are 25 dollars a pop. You need proof the company does what it claims. Tax filings seem the most logical solution.
The 25% ownership threshold originates from the KYC/AML framework applied by European banks, as outlined by the European Banking Authority in this official guidance.
However, it’s also important to consider whether the individual holds any decision-making authority, such as a position on the board of directors.
While this arrangement might be “okay” from a strictly legal ownership perspective, it could still raise concerns from a governance, risk, or regulatory standpoint. That said, these are precisely the kinds of situations that will be monitored, especially since all participants are required to disclose such information to DFINITY.