Thanks @MalithHatananchchige! For anyone else reading this, you may find this thread to be a useful collection of subnet-specific Subnet Management proposal forum discussions. → Subnet Management - General Discussion - Developers - Internet Computer Developer Forum (dfinity.org)
3 Likes
Just to confirm, we are internally working on a suggestion how proposal can be shared on the forum, so that it is easy to find all proposal discussions. We will share this in the coming week or so!
6 Likes
Greetings to all, there was a discovery made by Katie and Sven that our 10 nodes are assigned to one operator id, but since nodes are running in 2 different datacenters should be on registered on 2 different node operator id’s, therefore I created 2 proposals to split from currently 10 nodes into 5 rewards for one operator id and 5 nodes to another operator id, please accept my proposal 133083 and 133082 . Nothing is changed regarding the nodes, nothing is added nor removed.
Sincierely MB Patrankos suvis team,
Rokas Ambrazaitis
4 Likes
Voted to adopt proposals 133082 and 133083.
Using ic-admin and the dashboard, it can be seen that node provider 4jjya has two sets of nodes - 5 at data centre RG1 under node operator ID jptla and 5 at data centre BT1 under node operator ID mbnsu, with a node_allowance of 5 for each node operator. Currently, rewardable_nodes is set to none at RG1 and 10 at BT1. These two proposals would change the rewardable_nodes setting to 5 for each of the two node operator IDs.
4 Likes
Hi! Louise here from Aviate Labs. I will vote to adopt 133082 and 133083.
Via the dashboard, I’ve verified that all node IDs listed in each proposal are indeed owned by the same node provider and were previously under one node operator ID, as seen here. This allocation of 10 nodes was approved and aligns with the target topology. Proof of this can be found in the forum discussion here.
The update in node configuration is necessary as prior to these proposals, this node provider currently had 10 nodes—5 in Vilnius 1 and 5 in Riga 1. These should have two separate operator IDs, but were under a single ID instead. While there isn’t a strict rule on operator IDs, the convention that can be see throughout the dashboard is that each data center should have its own operator ID.
5 Likes
Voted to adopt both proposals 133082 and 133083.
Node provider MB Patrankos suvis used :
Proposal 131001 to set rewards for the listed nodes under node_operator_id “mbnsu” setting rewardable_nodes to “10”.
The current proposals splits the 10 nodes into 2 separate node_operator_id's for BT1 datacenter is “mbnsu” and for RG1 datacenter is “jptla”, both of them will have rewardable_nodes set to “5”. There was no rule to be enforced on this that I could find anywhere in the NP docs but if it makes it easier to have separate id’s for different datacenters to handle rewards, maybe someone should update the documentation for future reference.
3 Likes
Voted to adopt proposals 133082 and 133083.
The node provider 4jjya has 10 nodes, with five in dc bt1 under node operator jptla and five in dc rg1 under node operator mbnsu as seen in the image using the ic-admin tool and in the dashboard links of the data centers where the nodes are under MB Patrankos šūvis.
The proposals changes the rewardable_nodes of dc bt1 from 10 to 5 and of dc rg1 from None to 5
2 Likes
Hi all 
I’m Quint from Aviate Labs, and I’ve been reviewing proposals 133082 and 133083. After going through the details, I’ll be voting to adopt both, but there’s an important consideration regarding the order in which these proposals should be executed.
After validating the node data on-chain using scripts from our repo, I’ve confirmed the current setup for node provider 4jjya:
- They have 10 nodes, with 5 located in data center RG1 (operator ID
jptla) and 5 in data center BT1 (operator IDmbnsu). - The current rewardable_nodes is set to:
- 10 for BT1 (
mbnsu), - None for RG1 (
jptla).
- 10 for BT1 (
Proposal 133083 aims to reduce the rewardable_nodes in BT1 from 10 to 5, while Proposal 133082 would set rewardable_nodes in RG1 to 5.
However, if Proposal 133082 is executed first, it would temporarily result in a total of 15 rewardable nodes for the provider (5 at RG1 and 10 at BT1), which exceeds the intended cap of 10. To prevent this, Proposal 133083 should be executed before Proposal 133082, lowering the rewardable nodes for BT1 to 5 before increasing RG1 to 5. This will ensure the total remains at 10 rewardable nodes, split evenly between the two data centers.
Thanks to everyone who’s contributed to this, and I’m in full support of the proposals with the above sequence in mind.
6 Likes
Hello ICP Community,
My name is Philip Hur, and I’ve been working in the tech space for around 20 years, closely following ICP and its ecosystem.
With the recent developments and progress made by the foundation, I’m eager to participate in its growth by becoming a node provider.
Although I understand that the IC has currently reached its target topology, I’d like to express my interest in getting started when opportunities arise.
Once the network expands to accommodate more nodes, I plan to establish them in Malaysia, Indonesia, Thailand, South Korea (Busan) and Singapore where few or no nodes are currently planned.
I will update this thread when the proposal is up for voting. Thank you for considering my interest, and I look forward to contributing to the network’s success.
Best regards,
Philip Hur
6 Likes
Hi everyone,
Roald from the Aviate Labs team here! I’ve reviewed proposals 133082 and 133083 and wanted to share my conclusions.
After verifying the details, I found that all node IDs listed in both proposals are indeed owned by the same node provider, which had been previously grouped under one node operator ID, as indicated in proposal 131001. The allocation of 10 nodes under that proposal aligns with the planned topology.
The current proposal is requesting an update to the node configuration because this node provider operates 10 nodes—5 at Vilnius 1 and 5 at Riga 1—all under a single operator ID. While it’s not explicitly required, the norm is for different data centers to be assigned different operator IDs, which is reflected across the dashboard.
Based on this information, I will be supporting these proposals with my vote, but with taking @quint 's considerations into account:
5 Likes
Hi all,
I’ve just submitted my proposal to register as a new node provider. The proposal (#133135) is now live for voting, and I’d greatly appreciate your support in voting to adopt it.
I used proposals.network to submit it, and it worked seamlessly!
Please feel free to reach out if you have any questions or concerns.
Thanks again,
Philip Hur
5 Likes
Hi Philip,
Do you have a linkedIn by chance?
1 Like
Hi Philip,
Welcome to the IC community! I’m part of the CodeGov team, one of two teams that has funding grants to review and recommend votes on Participant Management proposals. Do you have a registered business for this process or are you just pursuing this as an individual?
@SvenF @sat Does Dfinity have a KYC process that could verify Philip’s Singapore driver’s licence or other documents? I respect that Philip would want to keep some of his personal details confidential so if you can say you’ve verified it then I’d be happy to accept that. By that I just mean proof of identity - obviously there are other considerations for the vote.
Regards,
Tim
4 Likes
hi @timk11 there is no KYC process from Dfinity end, that would make the onboarding process more centralized than decentralized. That’s why currently on the IC wiki pages no specific type of identity document is asked. This is one of the topics (next to for example audits of data centers) that are part of the agenda of the Technical Working Group for Node Providers, maybe it is an idea to join the next meeting. Totally agree to your question how the proof-of-identity should be verified, and whether it should go as far as a KYC process that is typically done in banking. Suggestions are welcome!
3 Likes
Thanks Sven. I use the term KYC rather loosely. On the one hand there could be a bank-style process, but on the other hand an on-chain or zero-knowledge proof mechanism would probably be much more in keeping with the decentralisation objective. Then again, to what extent does identity need to be verified? Are there legal considerations to be taken into account here, and similarly for data centres?
3 Likes
Hi @timk11 thanks and understand your point on using KYC loosely. There has not been a strong discussion on this yet in the community but it would be good to kick this off somewhere in the coming months. Personally I think it would be great to have some sort of “trustworthiness” level for both the Node Provider and Data Center (maybe even different levels of trustworthiness registered in the NNS) based on some kind of verification. Zero Knowledge Proof would be great if there is a good way to implement this for both Node Provider and for Data Center.
If the IC has different levels of trustworthiness, it could for example be possible to only allocate Node Providers and Data Centers with the highest trustworthiness level to e.g. NNS, Fiduciary Subnet, Bitcoin subnet. This could for example also be reflected back in the node remuneration.
4 Likes
So I take it there’s no firm requirement with respect to identity verification and it largely comes down to community judgement as reflected through the proposal voting results and in keeping with the decentralisation principle. I should mention that I’ve used this post on voting grant recipient requirements as the starting point for these queries, as well as referring to relevant parts of the IC Wiki. I wasn’t meaning to frame anything as a suggested new direction, but the points you’ve mentioned there are certainly worth discussing over time. That answers the question I had, and I’d be interested to hear some further opinions from anyone who’s already been thinking about this for a while.
3 Likes
Yes @timk11 I think that is correct.
3 Likes
Voted to adopt Proposal 133135. The core requirements for self-declaration as outlined here have been met, and hashes match for both of the submitted PDF documents. The identity document is not easily verifiable but I note that ease of verification varies between jurisdictions and the agreed requirements do not extend to a full KYC check.
3 Likes
I vote to reject proposal 133135.
The self-declaration of @Protocol16 / Philip Hur is not listed alongside other node providers in the self-declarations section.
Although the documents are available on the wiki, they should be linked on the self-declarations page to follow the established convention.
This is also outlined as part of the process here.
Once a new proposal is issued with this correction made, I would likely accept that new proposal.
3 Likes