Subnet Management - x33ed (Application SNS)

[MalithHatananchchige]

Proposal 135423 Review | Malith H - CO.DELTA

VOTE: NO

TLDR:

The proposal is to switch two dead/offline nodes in HongKong (Asia) and Jacksonville (North America).

Issue with the proposal

Node provider Rivonia Holdings LLC seems to be having a datacenter wide issue as seen in their other nodes. Jacksonville Datacenter

As seen in the proposal’s replacement node dwcjo…, it is in the same datacenter which is having issues at the moment, I strongly REJECT in making this node active.

For further explanation, coming from an NP experience, these node maybe be in awaiting status, during this status less connectivity is required. Thus during a partial network outage that is happening as seen the proposed DC. As soon as it joins a subnet and starts validating blocks, it will fall behind. @sat @DRE-Team it is best to reach out to the NP on the timeline of the resolution if by the time it can be resolved.

Provider Changes

Removed	Added
Rivonia Holdings LLC	Pindar Technology Limited
Web3game	Rivonia Holdings LLC

Location Changes

Removed	Added
North America, Jacksonville	Asia, HongKong 1
Asia, HongKong 4	North America, Jacksonville

Nodes Removed 2

Node ID	Status	Provider	Data Center	Location
44hxg…	DOWN	Rivonia Holdings LLC	jv1	Jacksonville
lf2qh…	DOWN	Web3game	hk4	HongKong 4

Nodes Added 2

Node ID	Status	Provider	Data Center	Location
phgey…	UNASSIGNED	Pindar Technology Limited	hk1	HongKong 1
dwcjo…	UNASSIGNED	Rivonia Holdings LLC	jv1	Jacksonville

Passes:

Node 44hxg…: Health check passed.

Node 44hxg…: Remove from Subnet check passed.

Node lf2qh…: Health check passed.

Node lf2qh…: Remove from Subnet check passed.

Node phgey…: Replacement Status check passed.

Node dwcjo…: Replacement Status check passed.

You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.

CO.DELTA

We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:

• Look: We observe the details and context of NNS proposals

• Test: We test and verify the claims made by those proposals

• Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.

Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.

[timk11]

Proposal 135423 | Tim - CodeGov

Vote: Adopt

This proposal replaces 2 nodes in subnet x33ed, appearing in the decentralization tool as “DOWN”. Both of the replacement nodes appear as “Status: Awaiting” in the IC dashboard. As shown in the proposal, decentralisation parameters are unchanged and remain within the requirements of the target topology.

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neurons’ Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralisation of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

[Lorimer]

Proposal 135423 Review | Lorimer - CO.DELTA △

VOTE: Awaiting further discussion … YES (although really great points raised by @MalithHatananchchige! I’m interested to see further discussion on this, regarding confirmation on whether the DC’s are experiencing hardware or connectivity issues)

TLDR: Two down nodes replaced with two unassigned nodes at the same data centres. Decentralisation stats remain unchanged.

@MalithHatananchchige nice review! Particularly displaying the results of your automated checks Regarding the ‘Awaiting’ status, my understanding was that this is an artificial status that the dashboard applies to indicate that the node is due to be added to a subnet (due to an open proposal). I could have the wrong end of the stick with that. If you check the raw status presented by the IC API both nodes have a status of ‘unassigned’ (I believe ‘down’ or ‘degraded’ would override an ‘unassigned’ status). I’ve never seen ‘awaiting’ in the raw status data, so I don’t think it actually represents a real node status (in terms of how it’s performing).

@MalithHatananchchige

For further explanation, coming from an NP experience, these node maybe be in awaiting status, during this status less connectivity is required. Thus during a partial network outage that is happening as seen the proposed DC. As soon as it joins a subnet and starts validating blocks, it will fall behind. @sat @DRE-Team it is best to reach out to the NP on the timeline of the resolution if by the time it can be resolved.

This is interesting. Perhaps there are multiple types of ‘awaiting’ status that are being conflated? I’ll hold off voting for now to aer on the side of caution, until there’s been some further discussion

Country Discrepancies (4)

A few country discrepancies involving relatively small distances, so could be considered to be within a margin of error.

Node	Data Center	Claimed Country	According to ipinfo.io
izmdg	South Moravian Region 1	Czechia	Austria
m6pbx	Vancouver	Canada	United States of America (the)
wwwxf	Geneva 2	Switzerland	Germany
xnraq	Brussels	Belgium	France

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

	Smallest Distance	Average Distance	Largest Distance
EXISTING	104.032 km	7749.871 km	19325.937 km
PROPOSED	104.032 km	7750.565 km	19325.937 km

Subnet characteristic counts →

	Continents	Countries	Data Centers	Owners	Node Providers	Node Operator
EXISTING	6	25	34	34	34	34
PROPOSED	6	25	34	34	34	34

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

	Continent	Country	Data Center	Owner	Node Provider	Node Operator
EXISTING	14	3	1	1	1	1
PROPOSED	14	3	1	1	1	1

See here for acceptable limits → Motion 132136

The above subnet information is illustrated below, followed by a node reference table:

Map Description

• Red marker represents a removed node (transparent center for overlap visibility)

• Green marker represents an added node

• Blue marker represents an unchanged node

• Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)

• Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used)

• Black dotted line connects to a small black marker that shows where the IP address indicates the node is located (according to ipinfo.io). This is only displayed if it conflicts with where IC records indicate the node is located. See Country Discrepancies section above for more info.

Node Changes

Action	Node	Status		Continent	Country	Data Center	Owner	Node Provider	Node Operator
Remove	lf2qh	DOWN		Asia	Hong Kong	HongKong 4 (hk4)	hkntt	Web3game	dg7of
Remove	44hxg	DOWN		North America	United States of America (the)	Jacksonville (jv1)	Tierpoint	Rivonia Holdings LLC	wmrev
Add	phgey	UNASSIGNED		Asia	Hong Kong	HongKong 1 (hk1)	Unicom	Pindar Technology Limited	vzsx4
Add	dwcjo	UNASSIGNED		North America	United States of America (the)	Jacksonville (jv1)	Tierpoint	Rivonia Holdings LLC	stqij

Other Nodes

Node	Status		Continent	Country	Data Center	Owner	Node Provider	Node Operator
hrhn3	UP		Oceania	Australia	Melbourne 2 (mn2)	NEXTDC	Icaria Systems Pty Ltd	l5lhp
j3pcf	UP		Oceania	Australia	New South Wales 1 (ns1)	Latitude.sh	Conic Ventures	h6fpp
xnraq	UP		Europe	Belgium	Brussels (br1)	Digital Realty	Allusion	mjeqs
f7hyn	UP		North America	Canada	Quebec l1 (mtl1)	Leaseweb	Marvelous Web3	ueggl
m6pbx	UP		North America	Canada	Vancouver (bc1)	Cyxtera	Blockchain Development Labs	feb2q
wwwxf	UP		Europe	Switzerland	Geneva 2 (ge2)	SafeHost	Archery Blockchain SCSp	5atxd
y7vmg	UP		Europe	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Stiftung	rzskv
7pvxh	UP		South America	Colombia	Bogota 1 (bg1)	EdgeUno	Geeta Kalwani	74vhn
5irn3	UP		Europe	Czechia	Praha 2 (pa2)	Coolhousing	Vladyslav Popov	6hl6v
izmdg	UP		Europe	Czechia	South Moravian Region 1 (bn1)	Master Internet	Lukas Helebrandt	zc635
yyjdt	UP		Europe	Estonia	Tallinn 1 (ta1)	InfonetDC	Maksym Ishchenko	z7r2x
pbva7	UP		Europe	Spain	Madrid 1 (ma1)	Ginernet	Bohatyrov Volodymyr	wzrq6
oobdg	UP		Europe	France	Paris 1 (pr1)	Celeste	Carbon Twelve	g3nqx
dofld	UP		Asia	Georgia	Tbilisi 1 (tb1)	Cloud9	George Bassadone	yhfy4
4ilsj	UP		Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	lis4o
efnid	UP		Asia	India	Greater Noida 1 (gn1)	Yotta	ACCUSET SOLUTIONS	slaxf
dnt7y	UP		Asia	India	Navi Mumbai 1 (nm1)	Rivram	Rivram Inc	mpmyf
qnn43	UP		Asia	Japan	Tokyo (ty1)	Equinix	Starbase	cqjev
7pch3	UP		Asia	Korea (the Republic of)	Seoul 1 (sl1)	Megazone Cloud	Neptune Partners	ukji3
qpt6h	UP		Asia	Sri Lanka	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	ywjtr
zk7wk	UP		Europe	Lithuania	Vilnius 1 (bt1)	Baltneta	MB Patrankos šūvis	mbnsu
2xph2	UP		North America	Panama	Panama City 1 (pc1)	Navegalo	Bianca-Martina Rohner	qaes5
catzb	UP		Europe	Poland	Warszawa 3 (wa3)	DataHouse	Ivanov Oleksandr	rhuve
6hqi5	UP		Europe	Portugal	Lisbon 2 (li2)	Edgoo Networks	Bitmoon	nvocp
r7few	UP		Europe	Romania	Bucharest (bu1)	M247	Iancu Aurel	c5ssg
i5xgw	UP		Asia	Singapore	Singapore 2 (sg2)	Telin	OneSixtyTwo Digital Capital	qffmn
pm6hc	UP		Europe	Slovenia	Ljubljana 2 (lj2)	Anonstake	Anonstake	eu5wc
vcl5k	UP		Europe	Slovenia	Maribor (mb1)	Posita.si	Fractal Labs AG	3xiew
oh5wh	UP		North America	United States of America (the)	Las Vegas (lv1)	Flexential	87m Neuron, LLC	gsps3
ct3c3	UP		North America	United States of America (the)	Utah 1 (dr1)	FiberState	Privoxy Solutions, LLC	nhr3z
nxeqo	UP		Africa	South Africa	Cape Town 1 (ct1)	Africa Data Centres	Illusions In Art (Pty) Ltd	2aemz
5osj4	UP		Africa	South Africa	Gauteng 3 (jb3)	Xneelo	Wolkboer (Pty) Ltd	ymenq

---

You may wish to follow the CO.DELTA known neuron (coming soon) if you found this analysis helpful.

CO.DELTA △

We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:

• Look: We observe the details and context of NNS proposals
• Test: We test and verify the claims made by those proposals
• Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.

Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.

---

Note that this analysis involved data provided by the IC-API, which is not open source. I’m in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.

[aligatorr89]

Proposal 135423 Review | aligatorr - CO.DELTA △

VOTE: YES

TLDR: Replaces 2 unhealthy nodes.

• Proposed topology Nakamoto Coefficient stayed the same as on current topology.

Node Changes 2 removed, 2 added

Node ID	Status	Country	City	Node Provider	Data Center	Data Center Owner
44hxg-ypmby-4grlh-grmge-hz6gp-vzir4-odo3n-6zvgn-xwcqs-46nne-gqe → dwcjo-nho7w-hpeyn-sj4g2-lo3gg-errgh-776xe-dmxis-iwncn-vqki4-2qe	DOWN → UNASSIGNED	US → US	Florida → Florida	Rivonia Holdings LLC → Rivonia Holdings LLC	jv1 → jv1	Tierpoint → Tierpoint
lf2qh-kizev-gkppo-tsz4a-tvev3-y7be3-gnyjz-5tmzr-ds56j-ylpwe-3ae → phgey-5cyzw-2ype7-y5q7w-yce6j-3yvg7-tlkfe-quvvy-pqpt4-252od-fqe	DOWN → UNASSIGNED	HK → HK	HongKong → HongKong	Web3game → Pindar Technology Limited	hk4 → hk1	hkntt → Unicom

Current Nakamoto Coefficients and Topology, avg = 10.80

Attribute	Nakamoto Coefficient	Identical attribute values	Max allowed identical values	Unique Counts
Country	6	3, US	3	25
City	12	1	1	34
Data Center	12	1	1	34
Data Center Owner	12	1	1	34
Node Provider ID	12	1	1	34

Proposed Nakamoto Coefficients and Topology, avg = 10.80

Attribute	Nakamoto Coefficient	Identical attribute values	Max allowed identical values	Unique Counts
Country	6	3, US	3	25
City	12	1	1	34
Data Center	12	1	1	34
Data Center Owner	12	1	1	34
Node Provider ID	12	1	1	34

You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.

CO.DELTA

We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:

• Look: We observe the details and context of NNS proposals.
• Test: We test and verify the claims made by those proposals.
• Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.

Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.

[ZackDS]

Proposal #135423 — Zack | CodeGov

Vote: Adopted
Reason:
The proposal replaces 2 dead Offline status node 44hxg from the JV1 DC in Florida and dead Offline status node lf2qh from the HK4 DC in Hong Kong4, with unassigned healthy Awaiting status node phgey from Hong Kong1 and unassigned healthy Awaiting status node dwcjo from Florida, without any change to decentralization.

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

[LaCosta]

Proposal 135423 – LaCosta | CodeGov

Vote: ADOPT

The proposal replaces two dead nodes on subnet x33ed:

• dead node 44hxg Dashboard Status: Offline and dead node lf2qh Dashboard Status: Active

with nodes:

• node phgey Dashboard Status: Awaiting and node dwcjo Dashboard Status: Awaiting

There is no impact in the overall decentralization across all features.

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

[wpb]

@MalithHatananchchige

For further explanation, coming from an NP experience,

I’d be interested in learning more about your node provider experience. I didn’t realize you are or were a node provider. Do you mind sharing more about your company, location, data center(s), number of nodes, type of nodes, owner vs operator vs hands on support? You don’t have to share and it doesn’t have any relevance other than I’m curious.

[wpb]

@Lorimer

@MalithHatananchchige nice review! Particularly displaying the results of your automated checks

You have put together a very nice team for these reviews @Lorimer. I’m impressed with CO.DELTA and I’m really glad there are more people involved in these technical proposal reviews who can offer new perspectives for people to consider as they make their decisions on their vote. @MalithHatananchchige @aligatorr89

[MalithHatananchchige]

Well it was back 2023 we joined

New Node Provider Proposals

Hi Guys It’s super nice to see ICP grow big. I stumbled upon it back in 2021 but for some reason, I was not able to invest. And again I did stumble upon it a few days ago. It must have been a journey for everyone! I want to invest a significant amount in being a node provider in Southeast Asia as there is less. I have access to a Tier 3 certified data center with colocation. The plan is to implement a single node first and grow to 5 by the end of the year. I would love to hear any thoughts befo…

Company name is Geodd colocated from Colombo Srilanka Tier 3 DC - Gen2 nodes, this was when the APAC region wasn’t big except for Singapore. And yes we have 24 hour devops / sysops team for ICP. Currently working with Gen AI providing AI inferencing for a few known projects. Based on A100, H100 & H200 optimized for x4 less latency and higher throughput than average providers. I was following up on Dffinity’s AI path as well, interested to see what contributions we can provide.

[aligatorr89]

Thank you @wbp. It is great to be a part of large decentralized organization.

[DRE-Team]

A new proposal with ID 135838 has been submitted, please take a look.

Click here to open proposal details

Replace nodes in subnet x33ed

Motivation:

• replacing dead node qpt6h

Calculated potential impact on subnet decentralization if replacing:

• 1 additional node would result in: (gets worse) the average log2 of Nakamoto Coefficients across all features decreases from 3.4183 to 3.3974 (solution penalty: 10)
• 2 additional nodes would result in: (gets worse) the average log2 of Nakamoto Coefficients across all features decreases from 3.3974 to 3.3745
• 3 additional nodes would result in: equal decentralization across all features
• 4 additional nodes would result in: equal decentralization across all features

Based on the calculated potential impact, replacing 2 additional nodes to improve optimization

Note: the heuristic for node replacement relies not only on the Nakamoto coefficient but also on other factors that iteratively optimize network topology.
Due to this, Nakamoto coefficients may not directly increase in every node replacement proposal.
Code for comparing decentralization of two candidate subnet topologies is at:
dre/rs/decentralization/src/nakamoto/mod.rs at 79066127f58c852eaf4adda11610e815a426878c · dfinity/dre · GitHub

Note: the information below is provided for your convenience. Please independently verify the decentralization changes rather than relying solely on this summary.
Here is an explaination of how decentralization is currently calculated,
and there are also instructions for performing what-if analysis if you are wondering if another node would have improved decentralization more.

Decentralization Nakamoto coefficient changes for subnet x33ed-h457x-bsgyx-oqxqf-6pzwv-wkhzr-rm2j3-npodi-purzm-n66cg-gae:

  node_provider: 12.00 -> 12.00    (+0%)
    data_center: 12.00 -> 12.00    (+0%)
data_center_owner: 12.00 -> 12.00    (+0%)
           area: 12.00 -> 10.00   (-17%)
          country: 6.00 -> 6.00    (+0%)

Mean Nakamoto comparison: 11.00 → 10.67 (-3%)

Overall replacement impact: (gets worse) the average log2 of Nakamoto Coefficients across all features decreases from 3.4183 to 3.3745

Impact on business rules penalties: 20 → 0

Details

Nodes removed:

• qpt6h-7m7xq-4crv7-pml2g-2jsxx-vxgv4-eka6d-hq4xj-73u5v-bsaki-zae [health: dead]
• dofld-ghkjo-hynoo-myl2n-mgqql-vsbou-5sowc-bcwtw-u4sr7-4w4dy-nqe [health: healthy]
• 4ilsj-76cys-w3sdj-znt6m-vsv6q-ak5st-iawte-mr4o7-o5d6s-jhego-7qe [health: healthy]

Nodes added:

• bv2x3-p2b3h-b23rg-aoq3s-kdzo2-pipmf-5y2me-jfa4w-tb7vr-qistz-2ae [health: healthy]
• dtf67-kbgf3-apiap-nxgwu-wtt3w-53scu-ep2yk-rfqm2-ccwod-jkdsh-tae [health: healthy]
• u3ahx-ft3kq-pzlkr-imzus-aeqxm-cirqv-ymehh-xzctz-os4ud-3a74m-vae [health: healthy]

    node_provider                                                              data_center            data_center_owner              area                             country        
    -------------                                                              -----------            -----------------              ----                             -------        
    3oqw6-vmpk2-mlwlx-52z5x-e3p7u-fjlcw-yxc34-lf2zq-6ub2f-v63hk-lae       1    bc1               1    Africa Data Centres       1    Bogota                      1    AU            2
    4dibr-2alzr-h6kva-bvwn2-yqgsl-o577t-od46o-v275p-a2zov-tcw4f-eae       1    bg1               1    Anonstake                 1    British Columbia            1    BE            1
    4jjya-hlyyc-s766p-fd6gr-d6tvv-vo3ah-j5ptx-i73gw-mwgyd-rw6w2-rae       1    bn1               1    Baltneta                  1    Brussels Capital            1    CA            2
    4r6qy-tljxg-slziw-zoteo-pboxh-vlctz-hkv2d-7zior-u3pxm-mmuxb-cae       1    br1               1    Celeste                   1    Bucuresti                   1    CH            2
    64xe5-tx2s3-4gjmj-pnozr-fejw2-77y5y-rhcjk-glnmx-62brf-qin5q-pqe  0 -> 1    bt1               1    Cloud9               1 -> 0    Cape Town                   1    CO            1
    6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe       1    bu1               1    Coolhousing               1    Colombo                     1    CZ            2
    6sq7t-knkul-fko6h-xzvnf-ktbvr-jhx7r-hapzr-kjlek-whugy-zt6ip-xqe  1 -> 0    cm1               1    Cyxtera                   1    Florida                     1    EE            1
    7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae       1    ct1               1    DataHouse                 1    Gauteng                     1    ES            1
    7ryes-jnj73-bsyu4-lo6h7-lbxk5-x4ien-lylws-5qwzl-hxd5f-xjh3w-mqe       1    dr1               1    Digital Realty            1    Geneva                      1    FR            1
    7uioy-xitfw-yqcko-5gpya-3lpsw-dw7zt-dyyyf-wfqif-jvi76-fdbkg-cqe       1    ge2               1    Dotsi                0 -> 1    Greater Noida               1    GE       1 -> 0
    bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe       1    gn1               1    EdgeUno                   1    HongKong               1 -> 2    HK       1 -> 2
    cp5ib-twnmx-h4dvd-isef2-tu44u-kb2ka-fise5-m4hta-hnxoq-k45mm-hqe       1    hk1               1    Edgoo Networks            1    Lisbon                 1 -> 2    IL       1 -> 0
    dhywe-eouw6-hstpj-ahsnw-xnjxq-cmqks-47mrg-nnncb-3sr5d-rac6m-nae       1    hk4          0 -> 1    Equinix                   1    Ljubljana                   1    IN            2
    diyay-s4rfq-xnx23-zczwi-nptra-5254n-e4zn6-p7tqe-vqhzr-sd4gd-bqe  0 -> 1    jb3               1    Everyware                 1    Madrid                      1    JP            1
    eatbv-nlydd-n655c-g7j7p-gnmpz-pszdg-6e6et-veobv-ftz2y-4m752-vqe       1    jv1               1    FiberState                1    Maribor                     1    KR            1
    efem5-kmwaw-xose7-zzhgg-6bfif-twmcw-csg7a-lmqvn-wrdou-mjwlb-vqe       1    li1          0 -> 1    Flexential                1    Melbourne                   1    LK            1
    eipr5-izbom-neyqh-s3ec2-52eww-cyfpg-qfomg-3dpwj-4pffh-34xcu-7qe       1    li2               1    Ginernet                  1    Navi Mumbai                 1    LT            1
    eybf4-6t6bb-unfb2-h2hhn-rrfi2-cd2vs-phksn-jdmbn-i463m-4lzds-vqe       1    lj2               1    InfonetDC                 1    Nevada                      1    PA            1
    i3cfo-s2tgu-qe5ym-wk7e6-y7ura-pptgu-kevuf-2feh7-z4enq-5hz4s-mqe       1    lv1               1    Interhost            1 -> 0    New South Wales             1    PL            1
    i7dto-bgkj2-xo5dx-cyrb7-zkk5y-q46eh-gz6iq-qkgyc-w4qte-scgtb-6ae       1    ma1               1    Latitude.sh               1    Panama City                 1    PT       1 -> 2
    ihbuj-erwnc-tkjux-tqtnv-zkoar-uniy2-sk2go-xfpkc-znbb4-seukm-wqe       1    mb1               1    Leaseweb                  1    Paris                       1    RO            1
    ivf2y-crxj4-y6ewo-un35q-a7pum-wqmbw-pkepy-d6uew-bfmff-g5yxe-eae       1    mn2               1    M247                      1    Praha                       1    SG            1
    kos24-5xact-6aror-uofg2-tnvt6-dq3bk-c2c5z-jtptt-jbqvc-lmegy-qae       1    mtl1              1    Master Internet           1    Quebec                      1    SI            2
    mjnyf-lzqq6-s7fzb-62rqm-xzvge-5oa26-humwp-dvwxp-jxxkf-hoel7-fqe       1    nm1               1    Megazone Cloud            1    Seoul                       1    US            3
    mme7u-zxs3z-jq3un-fbaly-nllcz-toct2-l2kp3-larrb-gti4r-u2bmo-dae       1    ns1               1    NEXTDC                    1    Singapore                   1    ZA            2
    optdi-nwa4m-hly3k-6ua4n-sqyxf-yahvb-wps77-ddayn-r7zcz-edla5-7qe       1    pa2               1    Navegalo                  1    South Moravian Region       1                   
    otzuu-dldzs-avvu2-qwowd-hdj73-aocy7-lacgi-carzj-m6f2r-ffluy-fae       1    pc1               1    OrionStellar              1    Tallinn                     1                   
    qsdw4-ao5ye-6rtq4-y3zhm-icjbj-lutd2-sbejz-4ajqz-pcflr-xrhsg-jae       1    pr1               1    Posita.si                 1    Tbilisi                1 -> 0                   
    r3yjn-kthmg-pfgmb-2fngg-5c7d7-t6kqg-wi37r-j7gy6-iee64-kjdja-jae       1    sg2               1    Rivram                    1    Tel Aviv               1 -> 0                   
    rbn2y-6vfsb-gv35j-4cyvy-pzbdu-e5aum-jzjg6-5b4n5-vuguf-ycubq-zae       1    sl1               1    SafeHost                  1    Tokyo                       1                   
    sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae       1    ta1               1    Telin                     1    Utah                        1                   
    spp3m-vawt7-3gyh6-pjz5d-6zidf-up3qb-yte62-otexv-vfpqg-n6awf-lqe       1    tb1          1 -> 0    Tierpoint                 1    Vilnius                     1                   
    trxbq-wy5xi-3y27q-bkpaf-mhi2m-puexs-yatgt-nhwiy-dh6jy-rolw5-zqe       1    tv1          1 -> 0    Unicom                    1    Warszawa                    1                   
    ulyfm-vkxtj-o42dg-e4nam-l4tzf-37wci-ggntw-4ma7y-d267g-ywxi6-iae       1    ty1               1    Xneelo                    1    Zurich                      1                   
    vegae-c4chr-aetfj-7gzuh-c23sx-u2paz-vmvbn-bcage-pu7lu-mptnn-eqe  1 -> 0    wa3               1    Yotta                     1                                                    
    wdjjk-blh44-lxm74-ojj43-rvgf4-j5rie-nm6xs-xvnuv-j3ptn-25t4v-6ae       1    zh2               1    hkntt                0 -> 1                                                    

Business rules check results before the membership change:

• Node provider cluster 1 (6sq7t, vegae, eatbv) has 3 nodes in the subnet

[MalithHatananchchige]

Incident Report

Node: qpt6h
Date & Time: March 14, 2025, 00:12 AM (+5:30)

Incident Summary

The node attempted to download the latest update (Proposal 135696), but the download repeatedly failed. This led to multiple retries, causing the node to degrade and appear offline after rebooting.

Root Causes & Resolutions

1. ISP Packet Loss: Possible packet loss during the update caused interruptions and slow download triggering the 60 second timeout retry (Fixed)
2. Download Loop & Throttling: Repeated download attempts may have led AWS or Cloudflare to throttle the IP. (Resolved after leaving the node offline for an hour)
3. Cable Issue: A faulty cable on one port was identified and replaced. (Fixed)

These issues were addressed around 6:00 PM +5:30. However, since there was no proper fix at the time, @DRE-Team and @sat considered submitting a proposal to remove the node from the subnet to allow it to download the update properly. (While keeping me inform)

Now that all issues have been resolved, the node is healthy again. Apologies for any inconvenience caused, and special thanks to @sat for the continued support.

[aligatorr89]

Proposal 135838 Review | aligatorr - CO.DELTA △

VOTE: NO

TLDR: The reason for this proposal was that the Sri Lanka node was offline for 18 hours. Incident was reported and fixed by node provider. Proposal is also making decentralization slightly worse.

• 1 Nakamoto parameters city: Lisbon above max identical count!!!
• Proposed topology Nakamoto Coefficient is worse than current!!!

Node Changes 3 removed, 3 added

Node ID	Status	Country	City	Node Provider	Data Center	Data Center Owner
4ilsj-76cys-w3sdj-znt6m-vsv6q-ak5st-iawte-mr4o7-o5d6s-jhego-7qe → bv2x3-p2b3h-b23rg-aoq3s-kdzo2-pipmf-5y2me-jfa4w-tb7vr-qistz-2ae	UP → UNASSIGNED	IL → LK	Tel Aviv → Colombo	GeoNodes LLC → Geodd Pvt Ltd	tv1 → cm1	Interhost → OrionStellar
dofld-ghkjo-hynoo-myl2n-mgqql-vsbou-5sowc-bcwtw-u4sr7-4w4dy-nqe → dtf67-kbgf3-apiap-nxgwu-wtt3w-53scu-ep2yk-rfqm2-ccwod-jkdsh-tae	UP → UNASSIGNED	GE → HK	Tbilisi → HongKong	George Bassadone → Web3game	tb1 → hk4	Cloud9 → hkntt
qpt6h-7m7xq-4crv7-pml2g-2jsxx-vxgv4-eka6d-hq4xj-73u5v-bsaki-zae → u3ahx-ft3kq-pzlkr-imzus-aeqxm-cirqv-ymehh-xzctz-os4ud-3a74m-vae	UP → UNASSIGNED	LK → PT	Colombo → Lisbon	Geodd Pvt Ltd → Artem Horodyskyi	cm1 → li1	OrionStellar → Dotsi

Current Nakamoto Coefficients and Topology, avg = 10.80

Attribute	Nakamoto Coefficient	Identical attribute values	Max allowed identical values	Unique Counts
Country	6		3	25
City	12		1	34
Data Center	12		1	34
Data Center Owner	12		1	34
Node Provider ID	12		1	34

Proposed Nakamoto Coefficients and Topology, avg = 10.40

Attribute	Nakamoto Coefficient	Identical attribute values	Max allowed identical values	Unique Counts
Country	6		3	23
City	10	2->Lisbon, 2->HongKong	1	32
Data Center	12		1	34
Data Center Owner	12		1	34
Node Provider ID	12		1	34

You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.

CO.DELTA

We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:

• Look: We observe the details and context of NNS proposals.
• Test: We test and verify the claims made by those proposals.
• Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.

Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.

[timk11]

Proposal 135838 | Tim - CodeGov

Vote: Reject

This proposal replaces 1 node in subnet x33ed, flagged as “dead” but appearing in the decentralization tool as “UP”, along with 2 additional nodes in order to improve overall topology. However, the flagged node qpt6h can also be seen in the Node Provider Rewards tool as having a block failure rate of at least 6% on 3 of the last 10 days recorded.

The effect of replacing the 2 additional nodes, as shown in the proposal, is that decentralisation is slightly worsened with respect to country in that the overall number of countries represented by this subnet is reduced by 2, even though the country Nakamoto coefficient is unchanged. The “region” Nakamoto coefficient is worsened, although this is not one of the parameters recognised in the agreed target topology. The “clusters” concept has not yet been agreed upon by an NNS vote. Although the target topology requirements are not violated, I would argue that the replacement of 2 additional nodes leaves this subnet more vulnerable to attack, hence my vote to reject this proposal.

@sat @alexu

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neurons’ Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralisation of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

[Lorimer]

Proposal 135838 Review | Lorimer - CO.DELTA △

VOTE: YES!

TLDR: This looks like a good proposal to me. The node that’s claimed to be offline has recovered (thanks for the detailed explanation @MalithHatananchchige!). Despite this there are some good reasons to adopt this proposal:

• George Bassadone and GeoNodes LLC are essentially the same NP. The fact that this isn’t currently explicitly captured is a known problem and a solution is being worked on. That doesn’t mean we need to wait to consider NPs like this as not belonging in the same subnet (see Node Changes section below to see these two NPs being removed)
• Despite the fact that theirs a slight reduction in the average nakamoto coefficient across all dimensions, the IC Target Topology is not violated, and in fact is strengthened by this proposal (if you consider the known NP relation described above). The IC Target Topology is specified in terms of limits, and these thresholds are respected by this proposal
• Rejecting this proposal means charging the proposer 25 ICP for their efforts (I personally think they made sensible decisions, particularly at the time the proposal was raised, and shouldn’t be punished for this)
• The average distance between nodes is actually increased on average by this proposal (not that this is a formal metric of decentralisation)

3 removed nodes replaced with nodes in Sri Lanka, China, Portugal.

Country Discrepancies (4)

The distances involved in these discrepancies are within a margin of error, so I expect can be discounted.

Node	Data Center	Claimed Country	According to ipinfo.io
izmdg	South Moravian Region 1	Czechia	Austria
m6pbx	Vancouver	Canada	United States of America (the)
wwwxf	Geneva 2	Switzerland	Germany
xnraq	Brussels	Belgium	France

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

	Smallest Distance	Average Distance	Largest Distance
EXISTING	104.032 km	7750.565 km	19325.937 km
PROPOSED	0.054 km (-99.9%)	7905.954 km (+2%)	19325.937 km

This proposal slightly increases decentralisation, considered purely in terms of geographic distance, on average at least (and therefore there’s a slight theoretical increase in localised disaster resilience).

Subnet characteristic counts →

	Continents	Countries	Data Centers	Owners	Node Providers	Node Operator
EXISTING	6	25	34	34	34	34
PROPOSED	6	23 (-8.7%)	34	34	34	34

This proposal slightly reduces decentralisation in terms of jurisdiction diversity.

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

	Continent	Country	Data Center	Owner	Node Provider	Node Operator
EXISTING	14	3	1	1	1	1
PROPOSED	15 (+7.14%)	3	1	1	1	1

See here for acceptable limits → Motion 135700

The above subnet information is illustrated below, followed by a node reference table:

Map Description

• Red marker represents a removed node (transparent center for overlap visibility)

• Green marker represents an added node

• Blue marker represents an unchanged node

• Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)

• Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used)

• Black dotted line connects to a small black marker that shows where the IP address indicates the node is located (according to ipinfo.io). This is only displayed if it conflicts with where IC records indicate the node is located. See Country Discrepancies section above for more info.

Node Changes

Action	Node	Status		Continent	Country	Data Center	Owner	Node Provider	Node Operator
Remove	dofld	UP		Asia	Georgia	Tbilisi 1 (tb1)	Cloud9	George Bassadone	yhfy4
Remove	4ilsj	UP		Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	lis4o
Remove	qpt6h	UP		Asia	Sri Lanka	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	ywjtr
Add	dtf67	UNASSIGNED		Asia	Hong Kong	HongKong 4 (hk4)	hkntt	Web3game	dg7of
Add	bv2x3	UNASSIGNED		Asia	Sri Lanka	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	ywjtr
Add	u3ahx	UNASSIGNED		Europe	Portugal	Lisbon 1 (li1)	Dotsi	Artem Horodyskyi	y2spu

Other Nodes

Node	Status		Continent	Country	Data Center	Owner	Node Provider	Node Operator
hrhn3	UP		Oceania	Australia	Melbourne 2 (mn2)	NEXTDC	Icaria Systems Pty Ltd	l5lhp
j3pcf	UP		Oceania	Australia	New South Wales 1 (ns1)	Latitude.sh	Conic Ventures	h6fpp
xnraq	UP		Europe	Belgium	Brussels (br1)	Digital Realty	Allusion	mjeqs
f7hyn	UP		North America	Canada	Quebec l1 (mtl1)	Leaseweb	Marvelous Web3	ueggl
m6pbx	UP		North America	Canada	Vancouver (bc1)	Cyxtera	Blockchain Development Labs	feb2q
wwwxf	UP		Europe	Switzerland	Geneva 2 (ge2)	SafeHost	Extragone SA	5atxd
y7vmg	UP		Europe	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Stiftung	rzskv
7pvxh	UP		South America	Colombia	Bogota 1 (bg1)	EdgeUno	Geeta Kalwani	74vhn
5irn3	UP		Europe	Czechia	Praha 2 (pa2)	Coolhousing	Vladyslav Popov	6hl6v
izmdg	UP		Europe	Czechia	South Moravian Region 1 (bn1)	Master Internet	Lukas Helebrandt	zc635
yyjdt	UP		Europe	Estonia	Tallinn 1 (ta1)	InfonetDC	Maksym Ishchenko	z7r2x
pbva7	UP		Europe	Spain	Madrid 1 (ma1)	Ginernet	Bohatyrov Volodymyr	wzrq6
oobdg	UP		Europe	France	Paris 1 (pr1)	Celeste	Carbon Twelve	g3nqx
phgey	UP		Asia	Hong Kong	HongKong 1 (hk1)	Unicom	Pindar Technology Limited	vzsx4
efnid	UP		Asia	India	Greater Noida 1 (gn1)	Yotta	ACCUSET SOLUTIONS	slaxf
dnt7y	UP		Asia	India	Navi Mumbai 1 (nm1)	Rivram	Rivram Inc	mpmyf
qnn43	UP		Asia	Japan	Tokyo (ty1)	Equinix	Starbase	cqjev
7pch3	UP		Asia	Korea (the Republic of)	Seoul 1 (sl1)	Megazone Cloud	Neptune Partners	ukji3
zk7wk	UP		Europe	Lithuania	Vilnius 1 (bt1)	Baltneta	MB Patrankos šūvis	mbnsu
2xph2	UP		North America	Panama	Panama City 1 (pc1)	Navegalo	Bianca-Martina Rohner	qaes5
catzb	UP		Europe	Poland	Warszawa 3 (wa3)	DataHouse	Ivanov Oleksandr	rhuve
6hqi5	UP		Europe	Portugal	Lisbon 2 (li2)	Edgoo Networks	Bitmoon	nvocp
r7few	UP		Europe	Romania	Bucharest (bu1)	M247	Iancu Aurel	c5ssg
i5xgw	UP		Asia	Singapore	Singapore 2 (sg2)	Telin	OneSixtyTwo Digital Capital	qffmn
pm6hc	UP		Europe	Slovenia	Ljubljana 2 (lj2)	Anonstake	Anonstake	eu5wc
vcl5k	UP		Europe	Slovenia	Maribor (mb1)	Posita.si	Fractal Labs AG	3xiew
dwcjo	UP		North America	United States of America (the)	Jacksonville (jv1)	Tierpoint	Rivonia Holdings LLC	stqij
oh5wh	UP		North America	United States of America (the)	Las Vegas (lv1)	Flexential	87m Neuron, LLC	gsps3
ct3c3	UP		North America	United States of America (the)	Utah 1 (dr1)	FiberState	Privoxy Solutions, LLC	nhr3z
nxeqo	UP		Africa	South Africa	Cape Town 1 (ct1)	Africa Data Centres	Illusions In Art (Pty) Ltd	2aemz
5osj4	UP		Africa	South Africa	Gauteng 3 (jb3)	Xneelo	Wolkboer (Pty) Ltd	ymenq

---

You may wish to follow the CO.DELTA known neuron (coming soon) if you found this analysis helpful.

CO.DELTA △

We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:

• Look: We observe the details and context of NNS proposals
• Test: We test and verify the claims made by those proposals
• Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.

Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.

---

Note that this analysis involved data provided by the IC-API, which is not open source. I’m in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.

[MalithHatananchchige]

Proposal 135838 Review | Malith H - CO.DELTA △

VOTE: YES

TLDR:

The proposal was initially to replace a node in Colombo(Srilanka) which was degraded, as pointed out here the node is recovered and is healthy. However the other two nodes that seem to be on a critical subnet pointed out by here by @Lorimer. I vote to adopt.

Provider Changes

| Removed | Added |

|------------|------------|

| Geodd Pvt Ltd | Geodd Pvt Ltd |

| George Bassadone | Web3game |

| GeoNodes LLC | Artem Horodyskyi |

Location Changes

| Removed | Added |

|------------|------------|

| Asia, Colombo 1 | Asia, Colombo 1 |

| Asia, Tbilisi 1 | Asia, HongKong 4 |

| Asia, Tel Aviv 1 | Europe, Lisbon 1 |

Nodes Removed 3

| Node ID | Status | Provider | Data Center | Location |

|—|—|—|—|—|

| qpt6h… | UP | Geodd Pvt Ltd | cm1 | Colombo 1 |

| dofld… | UP | George Bassadone | tb1 | Tbilisi 1 |

| 4ilsj… | UP | GeoNodes LLC | tv1 | Tel Aviv 1 |

Nodes Added 3

| Node ID | Status | Provider | Data Center | Location |

|—|—|—|—|—|

| bv2x3… | UNASSIGNED | Geodd Pvt Ltd | cm1 | Colombo 1 |

| dtf67… | UNASSIGNED | Web3game | hk4 | HongKong 4 |

| u3ahx… | UNASSIGNED | Artem Horodyskyi | li1 | Lisbon 1 |

Issues:

ISSUE: Node qpt6h… is not degraded or dead as claimed.

ISSUE: Node dofld… is not degraded or dead as claimed.

ISSUE: Node 4ilsj… is not degraded or dead as claimed.

Passes:

Node qpt6h…: Remove from Subnet check passed.

Node dofld…: Remove from Subnet check passed.

Node 4ilsj…: Remove from Subnet check passed.

Node bv2x3…: Replacement Status check passed.

Node dtf67…: Replacement Status check passed.

Node u3ahx…: Replacement Status check passed.

You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.

CO.DELTA

We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:

• Look: We observe the details and context of NNS proposals

• Test: We test and verify the claims made by those proposals

• Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.

Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.

[ZackDS]

Proposal #135838 — Zack | CodeGov

Vote: Adopted

Reason:
The proposal replaces dead Offline status node qpt6h that was since then recovered and Malith provided a detailed report so by the time it will execute it will replace 3 healthy Active status nodes with unassigned healthy Awaiting status nodes.
We really need more clusters ASAP not just the ONE.

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

[LaCosta]

Proposal 135838 – LaCosta | CodeGov

Vote: REJECT

The proposal replaces one previous dead node along with to other nodes on subnet x33ed:

• previous dead node qpt6h Dashboard Status: Active, node dofld Dashboard Status: Active and node node 4ilsj Dashboard Status: Active

with nodes:

• node bv2x3 Dashboard Status: Awaiting, node dtf67 Dashboard Status: Awaiting and node u3ahx Dashboard Status: Awaiting

There is no impact in the nakamoto coefficients regarding the country metric, although the subnet lost 2 different countries because of the replacement.

Regarding business rules with the inclusion of Node provider Clusters in the dre tool, it shows up as a collusion of Node Providers that control 3 nodes in the subnet. I particularly don’t like this approach but worse was that I can’t find no Governance Proposal regarding making this cluster official. @sat was there any motion regarding the creation of this cluster?

For this reasons I have voted to reject.

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

[alexu]

The DFINITY Foundation is voting ADOPT on proposals 135838 and 135839 that finalize a series of proposals that temporarily reduce the number of nodes from connected Node Providers in critical subnets. These proposals swap a few nodes belonging to a set of Node Providers out of the critical subnets, treating them as single “cluster.” This connection among the Node Providers is public information, declared by the group (Geonodes LLC, George Bassadone, and Bianca-Martina Rohner) themselves: George and Bianca are both linked to Geonodes LLC due to co-ownership.

While these and previous proposals are made as a short-term precautionary measure, recent discussions have identified the need to establish a clear policy defining what constitutes independence among node providers and taking into account during subnet allocation. More concrete suggestions on the policy and its implementation will be discussed with the Node Providers and the rest of the community.

[timk11]

Thanks @alexu for this explanation. For any similar proposals that might come up, could I ask if you could add something under “Motivation:” to indicate that this is the reason, and include a forum link to an explanation of the particular cluster? If it was the same cluster again, your post here would probably suffice. Discussion of NPs of concern is now scattered across numerous threads in the forum, so this will help us find the necessary supporting information without having to search around.