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.
To be honest I’m not too concerned. For these sorts of proposals we check that a handover statement has been saved in the IC Wiki and that this document matches the hash that is included in the proposal text. Within this document there is expected to be a statement that the two entities are operating independently of each other.
This of course is difficult to verify with full certainty, similarly to what we discussed about the “Sybil” issue elsewhere in the forum. However, this is where the community’s expectation currently sits with respect to the onus that is placed on node providers to behave in accordance with the declarations they have made. The potential to verify or enforce such things would vary greatly from one jurisdiction to another. There’s a whole discussion that could be had about how this fits in with the goal of a trustless decentralised system but due to time constraints I’ll be staying out of this.
Verifying the details of the transaction between the trading entities goes beyond this. Whether it necessarily needs a non-disclosure agreement or not I don’t know, but I respect that this is a private financial transaction and the parties involved may not wish to make these details public. I don’t see this as a problem.
Thanks @timk11. I think that this info is very valuable, even if it’s not immediately verifiable. A node provider would have to stick their neck out to provide fradulent information. It takes a second to ask and have it recorded, and it’s much more of a burden/risk for the NP unless they action that request honestly.
By the sounds of it, we’re not quite sure why there’s a need for a non-disclosure agreement. I think this (at the very least) would be useful information to have shared as common knowledge.
@roald-av8, you mentioned this sort of thing is common. Could you share an explanation of what this sort of obfuscation is designed to protect against?
@Lorimer I don’t quite get the point you’re making there, but I think my own point is lost unless you quote the entire paragraph.
I also think it would be best to keep this focused on systematic issues and suggestions for change, perhaps shifting from questions to an overall exposition of your thinking on this matter, rather than going down the path of singling out one person.
I understand what you are saying but I don’t think it’s very productive to be thinking this way. You raise now this “issue” about the handover of nodes, how the transaction was agreed between the two parties, if this parties are truly independent in their decision making and if the nodes are restricted in a set of rules, but the same thinking could be applied to the independence of NPs which to my knowledge you haven’t raised issues.
I don’t see any problem in raising questions in the sake of transparency but I have to quote tim on this one.
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.
I think this is a systematic issue. Asking questions like this is what helps uncover these sorts of issues. Before jumping the gun regarding suggestions, I think it makes sense to get a better handle on why things are the way they are. This is why I’m asking.
Yes, it all feeds into the discussion, and I have raised concerns.
Rather than trying to halt this line of questioning without an answer, I’d appreciate if someone in the know could provide some clear reasoning for non-disclosure agreements regarding node transfers.
What are they designed to protect against, and why can’t the terms of the transfer be declared?
Please find the information regarding the excess nodes that will be transferred to the new Node Provider: NODAO
The signed handover statement, containing the same information as below, can be found on the self declaration page of NODAO linked above.
14 node machines will be transferred from Existing Node Provider (Giant Leaf, LLC) to the New Node Provider (NODAO BV). The following details outline the specifics of this transfer:
Data Center Location:
The 14 excess node machines will be operated by the New Node Provider in the following Data Center(s):
Declaration of Independence:
Both Existing Node Provider and New Node Provider declare that they do not have any majority control in each other’s operations, financial interests, or governance decisions. Each party operates independently, with no undue influence or control over the other’s activities.
Node Deployment Confirmation:
This has not been completed yet. However, the Existing Node Provider confirms that this will be completed during the process of redeploying the nodes to the new Node Operator record of the new New Node Provider during the transition period, which is approximately between February 12 and March 15, 2025.
Reward Activation Date:
The above-mentioned nodes will have begun earning the new reward values as of February 1st, 2025.
Hi all,
Please find the information regarding the excess nodes that will be transferred to the two new Node Providers: NODAO and DeNoDe. To be concise, I have combined the information from the both handover statements in this post, but please note that there is a separate handover statement for each new Node Provider mentioned respectively. The signed handover statement, containing the same information below can be found on the respective self-declaration pages of the two new Node Providers.28 node machines will be transferred from Existing Node Provider (Allusion) to the New Node Providers: NODAO and DeNoDe. The following details outline the specifics of this transfer:
Data Center Location:
The 28 excess node machines will be operated by the New Node Providers in the following Data Center(s):
1 Rack (14 nodes) will be operated by NODAO, and the other rack of 14 nodes will be operated by DeNoDe.
Declaration of Independence:
Both Existing Node Provider and New Node Providers declare that they do not have any majority control in each other’s operations, financial interests, or governance decisions. Each party operates independently, with no undue influence or control over the other’s activities.
Node Deployment Confirmation
The Existing Node Provider confirms that two nodes have been deployed with the following configurations in Data Center(s) mentioned above:
IPv4 connectivity established
Domain name assigned and operational
Reward Activation Date: The above-mentioned nodes will begin earning the new reward values as of February 1st, 2025.
As mentioned, please find the necessary information regarding this handover on the DeNoDe self declaration page on the IC Wiki (the forum is not letting me post a link at the moment, so please refer to @Paul_DC 's post).
In a couple of days, I will submit a proposal to register my principal as a Node Provider.
NODAO will be taking over nodes from GiantLeaf and Allusion as part of our commitment to supporting the Internet Computer network. The details of NODAO and this transition can also be found on the NODAO Wiki page.
In the coming days, I will submit a proposal to register as a Node Provider.
Looking forward to contributing to the decentralization and security of the network.
~ Quint
Following the successful registration of our node provider principal via Proposal 135199 (NNS Dapp), I am reaching out once again to ask for your support on an important next step.
We have submitted Proposal 135307 (NNS Dapp) to register BlockFinance as a node operator. This proposal aims to onboard 14 nodes at the mb1 Data Center under a special arrangement that ensures the network remains the same size. These nodes are part of a transition process allowing genuine gen-1 machines to continue contributing under a new node provider.
Hi @Block23Finance , I am one of the Known Neuron Grant recipients (Aviate Labs) that reviews participant management and node admin proposals.
I was reviewing your proposal, and it appears the link to your signed Handover Statement is not available on your wiki page. As per the steps outlined by DFINITY here, this is a requirement.
I do see that the hash is already present there, so perhaps the link to the file is just pending approval, or you are yet to upload it.
Please ping me as soon as this is available on your wiki page so I and the other reviewers can continue. If this is not up there before the voting period ends, I would have to vote to reject as this is a requirement.
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.
Vote: ADOPT Review
This proposal registers a new NP DeNoDe.
Forum Introduction
Self-Declaration, Proof of Identity and Signed Node Handover documents are on the wiki, and a link is provided in the list of self declarations.
Hashes mentioned in the proposal match what is on the wiki and what I have computed locally. The same is true for the node handover statement which is not part of the proposal (and is not a requirement), but is on the self declaration page of DeNoDe.
DeNoDe entity is registered in the Belgium registry of businesses and enterprises
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.
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.
