This proposal will set rewardable nodes (type 1) to 0 for the old NO ID for PL1 DC - lz4fy-gca6y-aodk3-ncdrw-ouoqb-kgvjj-h4nul-eybyu-puwev-hkogp-fqe
This old NO ID belonged to 87m Neuron and as stated on their wiki page, this step is needed as they are transferring the nodes to a new node provider.
While it is not explicitly stated, this is inline with the steps provided on the wiki. The old NO ID should be removed/have the rewardable nodes set to 0 do avoid the scenario where the registry reflects that there are >28 rewardable nodes in PL1.
About Aviate Labs
Aviate Labs is a team dedicated to supporting node providers since 2020. Our mission is to make high-performance infrastructure management on the Internet Computer (ICP) as seamless as possible, while adhering to the principles of decentralization.
We are known for our contributions to the ecosystem, including the go-agent and developer work packages on GitHub, as well as the Node Monitortool, which alerts Node Providers as soon as any of their nodes go down.
In the NNS, our teamâRoald, Louise, and Quintâreviews and votes independently on âNode Adminâ and âParticipant Managementâ proposals. Currently we donât vote at all on other proposals.
The Aviate Labs known neuron is configured to follow our team for these topics and other trusted entities for broader proposals. We strive to be a credible and reliable Followee, committed to voting on every proposal and supporting decentralization within the ICP ecosystem.
This proposal will set rewardable nodes - type 1 to 0 for the old NO ID for DL1 DC - sambh-2izbh-p3bex-lamdj-retvw-g2uob-nptqo-bhcng-k6w44-vzenu-5ae
This old NO ID belonged to 87m Neuron and as stated on their wiki page, this step is needed as they are preforming the HSM less migration. This is inline with the steps provided on the wiki.
About Aviate Labs
Aviate Labs is a team dedicated to supporting node providers since 2020. Our mission is to make high-performance infrastructure management on the Internet Computer (ICP) as seamless as possible, while adhering to the principles of decentralization.
We are known for our contributions to the ecosystem, including the go-agent and developer work packages on GitHub, as well as the Node Monitortool, which alerts Node Providers as soon as any of their nodes go down.
In the NNS, our teamâRoald, Louise, and Quintâreviews and votes independently on âNode Adminâ and âParticipant Managementâ proposals. Currently we donât vote at all on other proposals.
The Aviate Labs known neuron is configured to follow our team for these topics and other trusted entities for broader proposals. We strive to be a credible and reliable Followee, committed to voting on every proposal and supporting decentralization within the ICP ecosystem.
This NP is adding 3 more nodes to their reward configuration for their NO record for LV1.
In a prior proposal, 8 nodes were onboarded, and so rewardable nodes were set to 8
Now 3 nodes are being onboarded, so the rewardable nodes in this proposal is correctly being set to 11. (For context, the rewardable nodes for a particular typeX.Y in a proposal overwrites the previous value and so the number in the proposal should be the cumulative value if nodes are added in batches to the reward configuration.)
All of the 3 node IDs mentioned in the proposal do appear on the dashboard for LV1.
Given the above information, I vote to adopt.
About Aviate Labs
Aviate Labs is a team dedicated to supporting node providers since 2020. Our mission is to make high-performance infrastructure management on the Internet Computer (ICP) as seamless as possible, while adhering to the principles of decentralization.
We are known for our contributions to the ecosystem, including the go-agent and developer work packages on GitHub, as well as the Node Monitortool, which alerts Node Providers as soon as any of their nodes go down.
In the NNS, our teamâRoald, Louise, and Quintâreviews and votes independently on âNode Adminâ and âParticipant Managementâ proposals. Currently we donât vote at all on other proposals.
The Aviate Labs known neuron is configured to follow our team for these topics and other trusted entities for broader proposals. We strive to be a credible and reliable Followee, committed to voting on every proposal and supporting decentralization within the ICP ecosystem.
This NP (87m Neuron) is adding 3 more nodes to their reward configuration for their NO record for DL1.
In a prior proposal, 19 nodes were onboarded, and so rewardable nodes were set to 19
Now 3 nodes are being onboarded, so the rewardable nodes in this proposal is correctly being set to 22. (For context, the rewardable nodes for a particular typeX.Y in a proposal overwrites the previous value and so the number in the proposal should be the cumulative value if nodes are added in batches to the reward configuration.)
All of the 3 node IDs mentioned in the proposal do appear on the dashboard for DL1.
Given the above information, I vote to adopt.
About Aviate Labs
Aviate Labs is a team dedicated to supporting node providers since 2020. Our mission is to make high-performance infrastructure management on the Internet Computer (ICP) as seamless as possible, while adhering to the principles of decentralization.
We are known for our contributions to the ecosystem, including the go-agent and developer work packages on GitHub, as well as the Node Monitortool, which alerts Node Providers as soon as any of their nodes go down.
In the NNS, our teamâRoald, Louise, and Quintâreviews and votes independently on âNode Adminâ and âParticipant Managementâ proposals. Currently we donât vote at all on other proposals.
The Aviate Labs known neuron is configured to follow our team for these topics and other trusted entities for broader proposals. We strive to be a credible and reliable Followee, committed to voting on every proposal and supporting decentralization within the ICP ecosystem.
Can I suggest that a shared ticksheet / spreadsheet be set up to show which node providers are handing over or keeping Gen1 nodes in which data centres using which node operator IDs and which steps they have so far completed and by means of which proposals? Keeping track of this is becoming more and more convoluted the further these changes progress, and by my understanding thereâs a lot more of it to come. I would suggest that someone from Dfinity set this up in the first instance.
(Edit - Rejected by mistake. Thereâs a distinction that I missed, as per the response below.)
This proposal, presumably from Dfinity, reverses proposal 134700 from the node provider which set rewardable_nodes for this node operator ID to 28. This is an old node operator ID, established in March 2022 through proposal 48406. By my understanding, switching to HSM-less configuration and therefore also to a new node operator ID is an optional step, which in this case has been foregone.
Thanks @louisevelayo for flagging the concerns around this proposal. I see that the node provider (@mabalaru ) has conducted a lengthy discussion in Matrix about the earlier proposal 134700 with no mention of this current proposal. My reading of this is that Dfinity has submitted this proposal without realising that the node provider intended to continue using the old node operator ID. If this is incorrect (and the rejection vote wins) it would be easy enough to resubmit the proposal with some further explanation. I have therefore considered that rejecting the proposal is the safer option.
This proposal sets rewardable type1 nodes to 0 for node operator it7v7. The relevant node provider has already requested removal of this node operator in proposal 134715, so the current proposal may even be superfluous.
This proposal sets rewardable type1 nodes to 0 for node operator lz4fy. This node operator was used by 87m Neuron for data centre PL1 prior to selling their nodes in this centre.
This proposal sets rewardable type1 nodes to 0 for node operator sambh. The relevant node provider has already requested removal of this node operator in proposal 134714, so the current proposal may even be superfluous.
These proposals set rewardable_nodes to 11 and 22 for node operators gsps3 and mw64v respectively, corresponding to the number of nodes now deployed in the associated data centres by node provider 87m Neuron.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
@timk11 please donât reject 134716! This is to set TYPE 1 rewards to zero. They have done a proposal to set type 1.1 nodes to 28 134700 which you helped us with. They arenât supposed to get both type 1 and type 1.1 rewards at the same time!
ETA⌠okay, DFINITY voted early because it is Friday, and minting will happen before anyone starts work Monday, and I have to go through and run simulations to make sure that we got all these rewards proposals correct (because yes, itâs kind of confusing.)
No, it is actually necessary no matter what, but we didnât want to require the NP to make that proposal to stop the type 1 rewards, because we were going to take care of it for them. Thatâs why we didnât include it in the sheet.
Thatâs why we submitted this proposal for BU1, and weâll do the same for all the rest of the Gen-1.a after the Feb 13 distribution, to clean things up before the type1 rewards are removed from the registry table.
Oops sorry! Iâve already cast this vote but Iâve flagged our other team members so they can cast their votes to adopt. I see that I have missed the distinction between type 1 and type 1.1 in these two proposals. Thatâs my mistake and I take responsibility for it, but can I put it out there that this is a very subtle distinction and in a proposal like this it would be well worth adding further detail to point out the distinction and to include this explanation?
@louisevelayo At the moment the type1 rewards are reset if:
node operator record is removed, or
the number of type1 nodes is explicitly set to zero
I was hoping that the NNS changes would be done in time to, additionally, adjust these rewards automatically for the offboarded nodes, but that sadly didnât happen in time yet. So weâll have to do this type of manual corrections for a bit longer.
Itâs always possible to check the currently set rewards with ic-admin get-node-operator <...>
Vote: ADOPTED
Reason: This proposal was intentionally adopted based on the discussion by @timk11 and @katiep above as well as the important justification provided by DFINITY for voting already. The remaining reviewers on the CodeGov team will be casting their votes as time permits.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org
Adding 3 nodes to the reward configuration for their NO record for dl1.
Prior proposal #134667 onboarded 19, updating to type1.1:22.
All node ID belong to NO.
About Aviate Labs
Aviate Labs is a team dedicated to supporting node providers since 2020. Our mission is to make high-performance infrastructure management on the Internet Computer (ICP) as seamless as possible, while adhering to the principles of decentralization.
We are known for our contributions to the ecosystem, including the Go Agent and developer work packages on GitHub, as well as the Node Monitortool, which alerts Node Providers as soon as any of their nodes go down.
In the NNS, our teamâRoald, Louise, and Quintâreviews and votes independently on âNode Adminâ and âParticipant Managementâ proposals. Currently we donât vote at all on other proposals.
The Aviate Labs known neuron is configured to follow our team for these topics and other trusted entities for broader proposals. We strive to be a credible and reliable Followee, committed to voting on every proposal and supporting decentralization within the ICP ecosystem.
Sets the rewardable_nodestype1 of Node Operator it7v7 to 0. This comes following the Steps for Gen-1 Node onboarding after 48 months where the NP 87m Neuron set the new node operator with new rewardable nodes and new node type type1.1 in proposal 134666 and now sets the rewardable_nodes of the old NO as 0.
Sets the rewardable_nodestype1 of Node Operator lz4fy to 0. This comes following the Steps for Gen-1 Node onboarding after 48 months where the NP 87m Neuron set the new node operator with new rewardable nodes and new node type type1.1 in proposal 134672 and now sets the rewardable_nodes of the old NO as 0.
Sets the rewardable_nodestype1 of Node Operator sambh to 0. This comes following the Steps for Gen-1 Node onboarding after 48 months where the NP 87m Neuron set the new node operator with new rewardable nodes and new node type type1.1 in proposal 134667 and now sets the rewardable_nodes of the old NO as 0.
Proposal 134666 set the rewardable_nodestype1.1 of the Node Operator gsps3 to 8. This proposal adds 3 more nodes to the reward configuration making it 11.
Proposal 134667 set the rewardable_nodestype1.1 of the Node Operator mw64v to 19. This proposal adds 3 more nodes to the reward configuration making it 22.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Voted to adopt proposal 134774. As explained in the proposal text, this proposal is needed in order to reinstate rewards that were accidentally removed by proposal 134716.
There were two proposals that updated the config of Node Operator c5ssg. Proposal 134700 changed the rewardable_nodestype1.1 to 28 and proposal 134716 changed the rewardable_nodestype1 to 0. The problem was that proposal 134716 was executed after and reverted the changes of proposal 134700. So this proposal replicates proposal 134700 to reinstate itâs changes.
Using the ic-admin tool one can verify that indeed this changes were reverted.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Currently the NP has a total of 28 Gen-1 nodes all in the fr2 DC controlled by NO 3nu7r-l6i5c-jlmhi-fmmhm-4wcw4-ndlwb-yovrx-o3wxh-suzew-hvbbo-7qe which match the proposed number of nodes and the DC mentioned in the proposal.
The NP made some mistakes in the summary of the proposal and explained them in this post. The mistakes were addressed promptly by the NP and since they donât affect the payload, Iâve voted to adopt. Thanks for the clarifications @DavidB.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
