Internet Computer Wiki - User contributions [en]

Node Provider Node Swapping Guide

2026-02-16T14:52:44Z

Alexander.ufimtsev: /* 🚧 Node swapping will be enabled for all the subnets in Q1 2026. It is now live for non-system subnets and can be used! */

==='''Node swapping is now live for all the subnets!'''===

==Introduction==
Node providers run nodes on the Internet Computer and receive rewards depending on how well their nodes perform. Only nodes that contribute to the overall performance of the node provider are the nodes that are part of a subnet. Those nodes are called ''assigned''. All other nodes that are not part of any subnet and are not utilized don't contribute to the overall performance of the node provider. Those nodes are called ''unassigned''.

It is in the node providers best interest to keep the ''assigned'' nodes as well maintained and as operational as possible since that is how they can maximize their rewards. To achieve that over time, the node providers can utilize the '''node swapping''' feature.

==Node swapping==
Node swapping feature is used to ''swap'' an ''assigned'' node for an ''unassigned'' node owned by the same ''node operator''.

=====Example=====
A node provider notices that one of his nodes is performing poorly. In order to maximize their rewards, they want to act quickly and remove the ''assigned'' node from a subnet for a different ''unassigned'' node '''within the same data center'''. They use the '''node swapping feature''' to do that without '''any proposals or governance'''. After performing the swap they can perform maintenance on the node and see why it failed in the first place.

==Performing a node swap==
To perform a node swap one has to follow the following steps:

'''IMPORTANT''': if the node is turned off before it gracefully leaves the subnet it will appear as malicious to the consensus which can result in rewards penalty!

#Find the principal ID of an ''assigned'' node that should be removed from a subnet. To do that one can use various tools, but for the sake of this example we will show examples from [https://dashboard.internetcomputer.org/ the public dashboard].[[File:Node provider dead node part of a subnet.png|left|frameless|1000x1000px|Degraded node with its node ID and health status]]
#Find the principal ID of an ''unassigned'' node that should be added to a subnet in place of an ''assigned'' node picked in the previous step. To do that one can click on the data center (below the '''DC ID''' "to1" for this example) of the node from the previous step which will take them to the view which contains all the node machines from the same data center. From there, pick the one that isn't ''assigned'' to any subnet (the '''subnet ID''' column should contain a '-').[[File:Unassigned nodes in the same data center.png|left|frameless|1111x1111px]]
#Using ic-admin utility to perform a node swap:<syntaxhighlight lang="bash">
# Uncomment this if the node operator identity is behind a private key file
#AUTH=(
# "--secret-key-pem"
# <path-to-key-pem>
#)

# Uncomment this if node operator identity is behind an hsm
#AUTH=(
# "--use-hsm"
# "--slot"
# <hsm-key-slot>
# "--key-id"
# <hsm-key-id>
# "--pin"
# <hsm-pin>
#)

ic-admin --nns-urls https://ic0.app ${AUTH[@]} swap-node-in-subnet-directly \
--old-node-id <principal-from-step-1> \
--new-node-id <principal-from-step-2>

</syntaxhighlight>
#After the response from the call is successful the node doesn't leave the subnet immediately. There is '''graceful leaving period''' that needs to be awaited. It takes around 15-20 minutes depending on the subnet. If the logs of the node are observed through the BMC console there are two messages that need to show in order for the node to completely leave the subnet ''gracefully''. The first log that indicates that the node noticed that the swapping was requested looks like the following:<syntaxhighlight lang="bash">
Node started leaving subnet <subnet-id>.
</syntaxhighlight>After some time the node will show the following log which indicates it left the subnet:<syntaxhighlight lang="bash">
Node gracefully left a subnet <subnet-id>
</syntaxhighlight>
#After the second log appears it is safe to turn off the node and proceed to do maintenance.

== Limitations and constraints==
To ensure fair and safe use of the swapping feature there are some limitations and constraints about the usage of the feature that need to be shared.

=====Ownership and locality constraints =====
A node provider '''can''' only perform a swap of two nodes if and only if the following ''locality'' constraints are met:

#The ''old node'' is an ''assigned'' node (it is a part of a subnet) and the ''new node'' is an ''unassigned'' node (it isn't a part of any subnet).
#Both ''old'' and ''new'' nodes are owned by the same '''node provider''' and are located in the same '''data center'''. Furthermore they have to be owned by the same '''node operator.''' This is needed to ensure that the ''decentralization'' doesn't change when the swaps are performed.

=====Rate limiting constraints=====
A node provider '''can''' only perform a swap of two nodes if and only if the following ''rate limiting'' constraints are met:

# The '''subnet''' which the ''old'' node is a part of hasn't had a swap in the last '''4 hours''' - this limit is here to protect the subnet from losing its state from too many swaps happening at the same time.
#The '''node provider''' performing the swap hasn't made a swap on the '''subnet''' which the ''old'' node is a part of in the last '''24 hours''' - this limit is here to protect other node providers from being unable to swap nodes because one node provider is constantly swapping nodes within the '''2 hour''' limit of the 1st constraint.

Node Provider Node Swapping Guide

2026-02-05T17:52:31Z

Alexander.ufimtsev:

===🚧 '''Node swapping will be enabled for all the subnets in Q1 2026. It is now live for non-system subnets and can be used!'''===

==Introduction==
Node providers run nodes on the Internet Computer and receive rewards depending on how well their nodes perform. Only nodes that contribute to the overall performance of the node provider are the nodes that are part of a subnet. Those nodes are called ''assigned''. All other nodes that are not part of any subnet and are not utilized don't contribute to the overall performance of the node provider. Those nodes are called ''unassigned''.

It is in the node providers best interest to keep the ''assigned'' nodes as well maintained and as operational as possible since that is how they can maximize their rewards. To achieve that over time, the node providers can utilize the '''node swapping''' feature.

==Node swapping==
Node swapping feature is used to ''swap'' an ''assigned'' node for an ''unassigned'' node owned by the same ''node operator''.

=====Example=====
A node provider notices that one of his nodes is performing poorly. In order to maximize their rewards, they want to act quickly and remove the ''assigned'' node from a subnet for a different ''unassigned'' node '''within the same data center'''. They use the '''node swapping feature''' to do that without '''any proposals or governance'''. After performing the swap they can perform maintenance on the node and see why it failed in the first place.

==Performing a node swap==
To perform a node swap one has to follow the following steps:

'''IMPORTANT''': if the node is turned off before it gracefully leaves the subnet it will appear as malicious to the consensus which can result in rewards penalty!

#Find the principal ID of an ''assigned'' node that should be removed from a subnet. To do that one can use various tools, but for the sake of this example we will show examples from [https://dashboard.internetcomputer.org/ the public dashboard].[[File:Node provider dead node part of a subnet.png|left|frameless|1000x1000px|Degraded node with its node ID and health status]]
#Find the principal ID of an ''unassigned'' node that should be added to a subnet in place of an ''assigned'' node picked in the previous step. To do that one can click on the data center (below the '''DC ID''' "to1" for this example) of the node from the previous step which will take them to the view which contains all the node machines from the same data center. From there, pick the one that isn't ''assigned'' to any subnet (the '''subnet ID''' column should contain a '-').[[File:Unassigned nodes in the same data center.png|left|frameless|1111x1111px]]
#Using ic-admin utility to perform a node swap:<syntaxhighlight lang="bash">
# Uncomment this if the node operator identity is behind a private key file
#AUTH=(
# "--secret-key-pem"
# <path-to-key-pem>
#)

# Uncomment this if node operator identity is behind an hsm
#AUTH=(
# "--use-hsm"
# "--slot"
# <hsm-key-slot>
# "--key-id"
# <hsm-key-id>
# "--pin"
# <hsm-pin>
#)

ic-admin --nns-urls https://ic0.app ${AUTH[@]} swap-node-in-subnet-directly \
--old-node-id <principal-from-step-1> \
--new-node-id <principal-from-step-2>

</syntaxhighlight>
#After the response from the call is successful the node doesn't leave the subnet immediately. There is '''graceful leaving period''' that needs to be awaited. It takes around 15-20 minutes depending on the subnet. If the logs of the node are observed through the BMC console there are two messages that need to show in order for the node to completely leave the subnet ''gracefully''. The first log that indicates that the node noticed that the swapping was requested looks like the following:<syntaxhighlight lang="bash">
Node started leaving subnet <subnet-id>.
</syntaxhighlight>After some time the node will show the following log which indicates it left the subnet:<syntaxhighlight lang="bash">
Node gracefully left a subnet <subnet-id>
</syntaxhighlight>
#After the second log appears it is safe to turn off the node and proceed to do maintenance.

== Limitations and constraints==
To ensure fair and safe use of the swapping feature there are some limitations and constraints about the usage of the feature that need to be shared.

=====Ownership and locality constraints =====
A node provider '''can''' only perform a swap of two nodes if and only if the following ''locality'' constraints are met:

#The ''old node'' is an ''assigned'' node (it is a part of a subnet) and the ''new node'' is an ''unassigned'' node (it isn't a part of any subnet).
#Both ''old'' and ''new'' nodes are owned by the same '''node provider''' and are located in the same '''data center'''. Furthermore they have to be owned by the same '''node operator.''' This is needed to ensure that the ''decentralization'' doesn't change when the swaps are performed.

=====Rate limiting constraints=====
A node provider '''can''' only perform a swap of two nodes if and only if the following ''rate limiting'' constraints are met:

# The '''subnet''' which the ''old'' node is a part of hasn't had a swap in the last '''4 hours''' - this limit is here to protect the subnet from losing its state from too many swaps happening at the same time.
#The '''node provider''' performing the swap hasn't made a swap on the '''subnet''' which the ''old'' node is a part of in the last '''24 hours''' - this limit is here to protect other node providers from being unable to swap nodes because one node provider is constantly swapping nodes within the '''2 hour''' limit of the 1st constraint.

Node Provider Node Swapping Guide

2025-12-19T15:54:02Z

Alexander.ufimtsev:

===🚧 '''Node swapping will be enabled for all the subnets in January 2026. It is now live for non-system subnets and can be used!'''===

==Introduction==
Node providers run nodes on the Internet Computer and receive rewards depending on how well their nodes perform. Only nodes that contribute to the overall performance of the node provider are the nodes that are part of a subnet. Those nodes are called ''assigned''. All other nodes that are not part of any subnet and are not utilized don't contribute to the overall performance of the node provider. Those nodes are called ''unassigned''.

It is in the node providers best interest to keep the ''assigned'' nodes as well maintained and as operational as possible since that is how they can maximize their rewards. To achieve that over time, the node providers can utilize the '''node swapping''' feature.

==Node swapping==
Node swapping feature is used to ''swap'' an ''assigned'' node for an ''unassigned'' node owned by the same ''node operator''.

=====Example=====
A node provider notices that one of his nodes is performing poorly. In order to maximize their rewards, they want to act quickly and remove the ''assigned'' node from a subnet for a different ''unassigned'' node '''within the same data center'''. They use the '''node swapping feature''' to do that without '''any proposals or governance'''. After performing the swap they can perform maintenance on the node and see why it failed in the first place.

==Performing a node swap==
To perform a node swap one has to follow the following steps:

'''IMPORTANT''': if the node is turned off before it gracefully leaves the subnet it will appear as malicious to the consensus which can result in rewards penalty!

#Find the principal ID of an ''assigned'' node that should be removed from a subnet. To do that one can use various tools, but for the sake of this example we will show examples from [https://dashboard.internetcomputer.org/ the public dashboard].[[File:Node provider dead node part of a subnet.png|left|frameless|1000x1000px|Degraded node with its node ID and health status]]
#Find the principal ID of an ''unassigned'' node that should be added to a subnet in place of an ''assigned'' node picked in the previous step. To do that one can click on the data center (below the '''DC ID''' "to1" for this example) of the node from the previous step which will take them to the view which contains all the node machines from the same data center. From there, pick the one that isn't ''assigned'' to any subnet (the '''subnet ID''' column should contain a '-').[[File:Unassigned nodes in the same data center.png|left|frameless|1111x1111px]]
#Using ic-admin utility to perform a node swap:<syntaxhighlight lang="bash">
# Uncomment this if the node operator identity is behind a private key file
#AUTH=(
# "--secret-key-pem"
# <path-to-key-pem>
#)

# Uncomment this if node operator identity is behind an hsm
#AUTH=(
# "--use-hsm"
# "--slot"
# <hsm-key-slot>
# "--key-id"
# <hsm-key-id>
# "--pin"
# <hsm-pin>
#)

ic-admin --nns-urls https://ic0.app ${AUTH[@]} swap-node-in-subnet-directly \
--old-node-id <principal-from-step-1> \
--new-node-id <principal-from-step-2>

</syntaxhighlight>
#After the response from the call is successful the node doesn't leave the subnet immediately. There is '''graceful leaving period''' that needs to be awaited. It takes around 15-20 minutes depending on the subnet. If the logs of the node are observed through the BMC console there are two messages that need to show in order for the node to completely leave the subnet ''gracefully''. The first log that indicates that the node noticed that the swapping was requested looks like the following:<syntaxhighlight lang="bash">
Node started leaving subnet <subnet-id>.
</syntaxhighlight>After some time the node will show the following log which indicates it left the subnet:<syntaxhighlight lang="bash">
Node gracefully left a subnet <subnet-id>
</syntaxhighlight>
#After the second log appears it is safe to turn off the node and proceed to do maintenance.

== Limitations and constraints==
To ensure fair and safe use of the swapping feature there are some limitations and constraints about the usage of the feature that need to be shared.

=====Ownership and locality constraints =====
A node provider '''can''' only perform a swap of two nodes if and only if the following ''locality'' constraints are met:

#The ''old node'' is an ''assigned'' node (it is a part of a subnet) and the ''new node'' is an ''unassigned'' node (it isn't a part of any subnet).
#Both ''old'' and ''new'' nodes are owned by the same '''node provider''' and are located in the same '''data center'''. Furthermore they have to be owned by the same '''node operator.''' This is needed to ensure that the ''decentralization'' doesn't change when the swaps are performed.

=====Rate limiting constraints=====
A node provider '''can''' only perform a swap of two nodes if and only if the following ''rate limiting'' constraints are met:

# The '''subnet''' which the ''old'' node is a part of hasn't had a swap in the last '''4 hours''' - this limit is here to protect the subnet from losing its state from too many swaps happening at the same time.
#The '''node provider''' performing the swap hasn't made a swap on the '''subnet''' which the ''old'' node is a part of in the last '''24 hours''' - this limit is here to protect other node providers from being unable to swap nodes because one node provider is constantly swapping nodes within the '''2 hour''' limit of the 1st constraint.

Node Provider Reward Configuration Guide

2025-11-25T15:55:12Z

Alexander.ufimtsev: fixed max-rewardable-nodes

After onboarding all your nodes, you must submit a reward configuration proposal in order to start receiving node rewards. If you do not do this, you will not receive node rewards. Proposals must be executed prior to the [https://next-rewards-gnj.caffeine.xyz/ next minting date] in order to be included.

In the next code block:

*Replace the <code>NEURON_ID</code> value with your neuron ID from the NNS Frontend Dapp (step 3.6 from the [[Node Provider Onboarding]]).
*Replace the <code>NODE_OPERATOR_PRINCIPAL</code> value with your node operator principal (step 7.1 from the [[Node Provider Onboarding]]).
*Replace <code>NODE_1_MACHINE_ID</code>, <code>NODE_2_MACHINE_ID</code> ... <code>NODE_N_MACHINE_ID</code> with the node machine IDs for all N of your node machines (found on the [https://dashboard.internetcomputer.org/ dashboard])
*Replace <code>NODE_COUNT</code> with the number of nodes you are setting a reward configuration for. *Important : ''If you adding nodes to a previous node allocation or updating a previous node operator record, you have to make sure the total node count should be accounted for'' ''in the'' <code>NODE_COUNT</code> ''parameter.''

==== 1. Create the proposal ====
<syntaxhighlight lang="shell">
$ NEURON_ID = XXXXXXXXXXXXXXXXXXXX
$ NODE_OPERATOR_PRINCIPAL = xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-update-node-operator-config \
--proposer $NEURON_ID \
--summary "Set rewards for the following nodes:

* NODE_1_MACHINE_ID
* NODE_2_MACHINE_ID
* ...
* NODE_N_MACHINE_ID
" \
--node-operator-id $NODE_OPERATOR_PRINCIPAL \
--max-rewardable-nodes '{"type3.1": NODE_COUNT}'
</syntaxhighlight>

The default reward configuration for Gen2 nodes is <code>type3.1</code>. If a different node configuration is applicable to your node models, replace this value.

Example reward configuration proposal for 3 Gen2 nodes:
<syntaxhighlight lang="shell">
$ NEURON_ID = 13419667327548602649
$ NODE_OPERATOR_PRINCIPAL = uqquy-76uhn-2mys5-dh54e-85ntr-sr953-redif-zkte3-94ndi-st2i1-93t
$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-update-node-operator-config \
--proposer $NEURON_ID \
--summary "Set rewards for the following nodes:

* sed94-atzdo-rltqy-tmnhr-fvspg-fat3p-sdbjp-7q3jg-dgfcq-zrlap-cqe
* uq4uy-76uhn-2mys5-dh54e-85ntr-sr953-redif-zkte3-94ndi-st2i1-93t-sdjsl-vjlfn-6duch-vskdu-26pf5-cwibg-zooqk-sdn2e-cgugm-tae
* 39esy-hmrb2-nfvao-t42co-tqfed-y3i7c-xqxyp-idt2w-wgmgr-l4x7l-gae
" \
--node-operator-id $NODE_OPERATOR_PRINCIPAL \
--max-rewardable-nodes '{"type3.1": 3}'
</syntaxhighlight>

==== 2. Find the proposal on https://dashboard.internetcomputer.org/governance and wait until it has been executed. ====

Node Provider Onboarding

2025-11-25T15:51:46Z

Alexander.ufimtsev: changed node-allowance to max-rewardable-nodes

Learn how to be accepted by the NNS as a Node Provider and onboard your nodes to the IC.

Please allocate up to a week to complete this guide, as it may take several days for a proposal to be accepted by the NNS, and you may have to submit multiple NNS proposals.

'''Note that the following steps do not need to be performed on the node machine itself.''' You can complete them on your personal laptop.

If you encounter issues through any of these steps, check the [[Node Provider Troubleshooting]] page. If that does not solve your problem, you are encouraged to ask for assistance in the [[Node Provider Matrix channel]].

For regular operations after onboarding, please refer to [[Node Provider Maintenance Guide|Node Provider Maintenance Guide.]]

== '''<big>Requirements</big>''' ==
* Assure your node(s) meet the [[Node Provider Machine Hardware Guide|Node Provider Machine Hardware requirements.]]
* View the [[Node Provider Networking Guide|Node Provider Networking Guide.]]
* Setup a [https://www.ledger.com/ hardware wallet].
*[https://shop.nitrokey.com/shop/product/nkhs2-nitrokey-hsm-2-7/ NitroKey HSM] (Optional, legacy—not recommended).
* 26 ICP (25 of which are to be staked for the NNS proposal deposit).
* Basic understanding of [[Neurons 101|neurons]], [https://internetcomputer.org/docs/current/tokenomics/nns/nns-staking-voting-rewards staking], and [[Governance of the Internet Computer|governance]] proposals, such as understanding what it means to stake a neuron for 8 years.

== 1. Install the required tools ==
===''' A. Install ic-admin '''===

<code>ic-admin</code> is the tool used to create and submit NNS proposals. You can install it by running the following in a terminal:

==== MacOS ====
<syntaxhighlight lang="shell">
curl -L "https://github.com/dfinity/ic/releases/latest/download/ic-admin-x86_64-darwin.gz" -o - | gunzip > ic-admin && chmod 0755 ./ic-admin

</syntaxhighlight>

==== Linux ====
NOTE: The instructions below have been tested with the Ubuntu 20.04 release<syntaxhighlight lang="shell">
curl -L "https://github.com/dfinity/ic/releases/latest/download/ic-admin-x86_64-linux.gz" -o - | gunzip > ic-admin && chmod 0755 ./ic-admin
</syntaxhighlight>

===''' B. Install dfx '''===

#<code>dfx</code> is a CLI tool used to generate neuron hotkeys, among other things such as canister deployment and management. <syntaxhighlight lang="shell">
$ sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh)"

</syntaxhighlight>
#Verify that <code>dfx</code> is up to date. <syntaxhighlight lang="shell">
$ export PATH=$HOME/bin:$PATH
$ dfx upgrade
$ dfx --version
</syntaxhighlight>

==2. Create Node Provider hotkey ==

#Create an identity for the Node Provider '''hotkey''' <syntaxhighlight lang="shell">
$ dfx identity new --storage-mode=plaintext node-provider-hotkey

Created identity: "node-provider-hotkey".

$ dfx --identity node-provider-hotkey identity get-principal

xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
# example node-provider-hotkey: wuyst-x5tpn-g5wri-mp3ps-vjtba-de3xs-w5xgb-crvek-tucbe-o5rqi-mae

</syntaxhighlight>'''You will need the Node Provider hotkey in the next steps.'''

'''Note''': The Node Provider hotkey is NOT the Node Provider principal. This is the hotkey that is used for the NNS proposal submissions only.

'''Note''': You may be prompted to enter a passphrase when creating your identity and accessing your identity principal. Take note of the passphrase you choose.

==3. Create and Manage Neuron via NNS Frontend Dapp and Internet Identity==

#Send at least 26 ICP tokens to your hardware wallet address.
#Navigate to the Neurons tab and create a Neuron by staking at least 26 ICP from your hardware wallet. Staking more ICP is acceptable, but 25 is the minimum needed for this process, and you must have a little more for transaction fees.
#IMPORTANT! Confirm the transaction on your hardware wallet.
#:[[File:-docs-stake_neuron_1.png|1024px|stake neuron]]
#After the Neuron has been created successfully, confirm to "Add NNS Dapp as hotkey" in the dialogue and on your hardware wallet, and close the dialog after the action completes.
#:[[File:-docs-stake_neuron_2.png|1024px|neuron id]]
#Set the dissolve delay to at least 6 months, and confirm the choice in the dialogue and on your hardware wallet. After the action completes, you can close the "Follow Neurons".
#:[[File:dissolve_delay.png|480px|neuron id]]
#You will now see a Neuron listed with its ID. Copy the Neuron ID, since you will need it in the next steps to place the necessary proposals.
#:[[File:Neuron id.png|1024px]]

==4. Add hotkeys==

#Select the Neuron you just created to open Neuron management view and press “Add hotkey” button.
#:[[File:Hotkey 1.png|873x873px]]
# A dialog will pop up where you can enter the hotkey you generated in step 2.1 (output from command <code>dfx --identity node-provider-hotkey identity get-principal</code>). This will allow you to submit NNS proposals using <code>ic-admin</code> and will not be used for anything else. 
#:Press the '''confirm''' button and confirm the transactions on your hardware wallet. 
#:[[File:Hotkey 2.png|899x899px]]
#Get the Ledger Hardware Wallet Principal Id: Navigate back to ICP page and select your Ledger hardware wallet account. You will need to use this Ledger Hardware Wallet principal as the Node Provider principal in order to get the rewards directly into the secure hardware wallet.
#:[[File:Node provider principal 1.png|1024px]]
#:[[File:Node provider principal 2.png|800px]]
#Copy and save this Node Provider principal by clicking on the copy icon after the principal id. You'll need it in the next steps. <syntaxhighlight lang="shell">
$ NODE_PROVIDER_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
# Input ledger Hardware Wallet principal, from the NNS FrontEnd dapp https://nns.ic0.app/

# example: $ NODE_PROVIDER_PRINCIPAL=fharn-5vyi2-4xb4a-64yyi-3jpmj-pga23-mxy25-d5uim-fqcro-eoefh-tae
</syntaxhighlight>

==5. Choose onboarding path (HSM vs no HSM)==
Onboarding '''without''' a NitroKey HSM is the current onboarding path. In particular, node providers onboarding [[Node Provider Machine Hardware Guide|Gen 2 hardware]] must onboard '''without''' a NitroKey HSM. If you will be onboarding '''without''' a NitroKey HSM, continue to the next step.

If the legacy procedure is required for your onboarding (which should only be the case in rare and exceptional situations), follow the [[NitroKey HSM onboarding instructions]] and then '''return to step 8.'''

==6. Setup the Node Operator keys ==
#'''''Ensure dfx is at least version 0.14.''''' Node Operator keys created with older versions of dfx '''will fail to join the IC'''. Run:<syntaxhighlight lang="bash">
$ dfxvm update
$ dfx --version
</syntaxhighlight>
#Create a new principal with dfx:<syntaxhighlight lang="shell">
$ dfx identity new --storage-mode=plaintext node_operator
</syntaxhighlight>
#Confirm <code>node_operator</code> identity was created successfully:<syntaxhighlight lang="shell">
$ dfx identity list
</syntaxhighlight>This list ''should'' contain <code>node_operator</code>.
#Copy new key to a known location:<syntaxhighlight lang="shell">
$ cp ~/.config/dfx/identity/node_operator/identity.pem ./node_operator_private_key.pem
</syntaxhighlight>
#Check the contents of the <code>node_operator_private_key.pem</code> file and double check that it contains the following contents. It is imperative that the first line has <code>-----BEGIN EC PRIVATE KEY-----</code>. If it does not, make sure you use the latest <code>dfx</code> version and that you followed the instructions precisely.<syntaxhighlight lang="shell">
❯ cat ./node_operator_private_key.pem
-----BEGIN EC PRIVATE KEY-----
[3 lines of base64 encoded private key, e.g. n2Nhp68YcQpuS0u96r...]
-----END EC PRIVATE KEY-----
</syntaxhighlight>Note: you must retain access to the <code>node_operator_private_key.pem</code> file for when you onboard nodes in '''[https://wiki.internetcomputer.org/wiki/Node_Provider_Roadmap#Milestone_Five:_Node_Machine_Onboarding roadmap milestone five.]'''

==7. Get the node operator principal==

#Get the principal:<syntaxhighlight lang="shell">
$ NODE_OPERATOR_PRINCIPAL=$(dfx --identity node_operator identity get-principal)
$ echo $NODE_OPERATOR_PRINCIPAL

uqquy-76uhn-2mys5-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
</syntaxhighlight>
'''You will need the node operator principal in the next steps.'''

==8. Register your Node Provider principal to the network==
In the next codeblock:
*Replace the <code>NODE_PROVIDER_NAME</code> value with the name of the entity that will provide the nodes.
*Replace the <code>NODE_PROVIDER_PRINCIPAL</code> value with the Ledger Hardware Wallet principal that you got from the NNS Frontend Dapp (step 4.4)
*Replace the <code>NEURON_ID</code> value with your neuron ID from the NNS Frontend Dapp (step 3.6)

*'''''IMPORTANT:''''' Please make sure that you also update the <code>--summary</code> and include a link to the forum discussion, your company's web page, and/or to another place that can convince the voting community that you are making a legitimate request. You must also include the file hash for the [[Node Provider Self-declaration|self declaration and proof of identity documents]], or the proposal will be rejected. This way you will avoid the community voting NO to your proposal and you losing your staked ICPs.

##Create the Proposal <syntaxhighlight lang="shell">
$ NODE_PROVIDER_NAME="My Company"
$ NODE_PROVIDER_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ NEURON_ID=XXXXXXXXXXXXXXXXXXXX
$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-add-or-remove-node-provider add \
--proposer $NEURON_ID \
--proposal-title "Register a node provider '${NODE_PROVIDER_NAME}'" \
--summary "Register a node provider '${NODE_PROVIDER_NAME}', in line with the announcement and discussion at <https://forum.dfinity.org/t/...>. The self-declaration documentation is available at <https://wiki.internetcomputer.org/wiki/...> with SHA256 hash <SHA256>. The proof of identity is available at <https://wiki.internetcomputer.org/wiki/...> with SHA256 hash <SHA256>." \
--node-provider-pid "$NODE_PROVIDER_PRINCIPAL"
</syntaxhighlight>Note: make sure <code>${NODE_PROVIDER_NAME}</code> is presented in single quotes, so the IC dashboard can pick up and display the correct Node Provider name.
#Find the proposal on https://dashboard.internetcomputer.org/governance and '''wait until it is executed before proceeding to next step.'''
#In order to expedite the speed of your proposal's approval, it is best to create a post in this [https://forum.dfinity.org/t/new-node-provider-proposals/16643/69 forum thread] to raise awareness of your proposal. You can use this as a [https://docs.google.com/document/d/1nKy5hKiF72a4NCHvpgij-Np9pbtR5KOBbF1W6qr-nds/edit?usp=sharing template] for the post.

''See guide for [[Troubleshooting Failed NNS proposals]]''

==9. Register your datacenter to the network (if necessary)==
#Search for your data center on https://dashboard.internetcomputer.org/centers.
#*If you found the datacenter that is hosting your nodes, remember its ID, and skip the following section. Otherwise, proceed with the registration of a new DC record.
#:[[File:dc_id.png|1041x1041px|alt=]]
===Create a data center record for a new DC===
In the next block of code:
*Replace the <code>NEURON_ID</code> value with your neuron ID from the NNS Frontend Dapp (step 3.6)
*Replace the JSON fields from the <code>–data-centers-to-add</code> argument and their corresponding values in <code>--summary</code>:
**<code>"id"</code> represents the city that your datacenter is in and is formulated as a combination of two letters representing the city and an incrementing number. Search data center IDs on https://dashboard.internetcomputer.org, and find a combination of two letters that’s not yet registered.
***''If the city or region where the new DC is located, has already been "named" by another DC in the same city or region, then pick the same letters and increment the number.''
***''If there is no other DC in this city or region, then pick a new letter-abbreviation that is not used yet and give it the number 1.''
***Examples:
****dl1 (Dallas, no IDs with “dl” prefix)
****zh10 (Zurich, numbers 0-9 are already registered)
***:[[File:dc_id.png|1024px]]
**<code>"region"</code> represents the local region of a datacenter and is formulated as a three-part string divided by commas. The three parts making the string are continent, country code, and region, in the given order. Examples:
***North America,US,Florida
***Europe,DE,Bavaria
***Asia,SG,Singapore
**:[[File:datacenter_region.png|1024px]]
**<code>"owner"</code> The entity that provides your datacenter facilities.
***Search https://dashboard.internetcomputer.org for existing data center providers.
***If there’s match, make sure you use the same exact some name for your datacenter.
***Otherwise, name the data center owner to your best knowledge.
**:[[File:datacenter_owner.png|1024px]]
**<code>"gps"</code> GPS coordinates.
***Find your datacenter on https://www.google.com/maps/.
***Right click on location, and select the GPS coordinates (first item in the menu) in order to copy them.
**:[[File:maps.png|310x310px|alt=Getting GPS coordinates|Getting GPS coordinates]]

#Create the proposal. **Make sure you include in the text of the proposal, a link to your forum post with additional details and reference so the community can easily find additional information and ask questions. <syntaxhighlight lang="shell">
$ NEURON_ID=XXXXXXXXXXXXXXXXXXXX
$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-add-or-remove-data-centers \
--summary "Register a Flexential datacenter as dl1 in North America,US,Texas" \
--skip-confirmation \
--proposer $NEURON_ID \
--data-centers-to-add '{
"id": "dl1",
"region": "North America,US,Texas",
"owner": "Flexential",
"gps": [
33.00803, -96.66614
]
}'
</syntaxhighlight>'''Remember to replace all the values of both the arguments <code>–data-centers-to-add</code> and <code>--summary</code>'''
#Find the proposal on https://dashboard.internetcomputer.org/governance and wait until it's executed before proceeding to next step.
#In order to expedite the speed of your proposal's approval, it is best to create a post in this [https://forum.dfinity.org/t/new-node-provider-proposals/16643/69 forum thread] to raise awareness of your proposal. You can use this as a [https://docs.google.com/document/d/1Hg0tI9O5__Tp4qKrNKuTADsQT7Z47I6aAFXbiDimG_U/edit?usp=sharing template] for the post.

''See guide for [[Troubleshooting Failed NNS proposals]]''

==10. Create a node operator record==
'''''IMPORTANT''':'' Before submitting the Node Operator record, please go through the description of [[Validation of Candidate Node Machines]] to validate whether additional node machines are needed for decentralization of the IC-network.

*Create a pdf with the outcome of running the optimization model and the steps that allow the community to reproduce the validation check.
*Include the pdf in the wiki page that includes the NP documents (self-declaration and proof-of-identity document)
*Include a link to the pdf as well as the hash of the document in the Node Operator record proosal.

In the next codeblock:
*Replace the <code>NEURON_ID</code> value with your neuron ID from the NNS Frontend Dapp (step 3.6).
*Replace the <code>NODE_PROVIDER_PRINCIPAL</code> value with the Ledger Hardware Wallet principal that you got from the NNS Frontend Dapp (step 4.4).
*Replace the <code>NODE_OPERATOR_PRINCIPAL</code> value with your node operator principal (step 7.1). '''Important''': if you are adding an additional node operator record because you will deploy nodes in another data center, please make sure to create a new node operator principal first (steps 6 and 7). A node operator principal can only be tied to 1 data center.
*Replace the <code>NODE_PROVIDER_NAME</code> value with the name of the entity that will provide the nodes.
*Replace the <code>REWARDABLE_NODES</code> variable value with number of nodes you are providing.
*Replace the <code>DC_ID</code> variable value with id of your datacenter.

#Create the proposal: <syntaxhighlight lang="shell">
$ NEURON_ID=XXXXXXXXXXXXXXXXXXXX
$ NODE_PROVIDER_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ NODE_OPERATOR_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ NODE_PROVIDER_NAME="My Company"
$ REWARDABLE_NODES='{"type3.1": 1}'
$ DC_ID=dl1

$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-add-node-operator \
$NODE_PROVIDER_PRINCIPAL \
--summary "Node provider '$NODE_PROVIDER_NAME' is adding $NODE_ALLOWANCE nodes in the $DC_ID data center. The result of the canidate node machine validation and exact configuration run is available at <https://wiki.internetcomputer.org/wiki/...> with SHA256 hash <SHA256>." \
--proposer $NEURON_ID \
--node-operator-principal-id $NODE_OPERATOR_PRINCIPAL \
--max-rewardable-nodes $REWARDABLE_NODES \
--dc-id $DC_ID
</syntaxhighlight>
#Find the proposal on https://dashboard.internetcomputer.org/governance and wait until it's executed before proceeding to next step.

''See guide for [[Troubleshooting Failed NNS proposals]]''

Node Provider Remuneration

2025-11-24T00:24:16Z

Alexander.ufimtsev: Added PBR

== Rewards ==

Node Providers receive rewards (remuneration) for owning node machines that run in the Internet Computer network. Node Provider rewards are set by the NNS DAO, with changes only possible through NNS proposals adopted by the Internet Computer community.

The '''NNS mints Node Provider Rewards every ~2,629,700 seconds''', which is 1/12th of a year. You can find the last and next minting dates [https://next-rewards-gnj.caffeine.xyz/ here].

The NNS uses the 30-day moving average price of ICP in Special Drawing Rights (XDR), an international reserve asset created by the International Monetary Fund (IMF). This value is tracked on the [https://dashboard.internetcomputer.org Internet Computer Dashboard] as part of the [https://dashboard.internetcomputer.org/network Network Overview], on the "Conversion Rate" chart. (See [[How the 30-Day Moving Average Is Calculated]].) Rewards for the previous month are converted to ICP and transferred to account of the principal registered by the Node Provider in the [[Node Provider Onboarding|Node Onboarding]] process.

These are the current rewards, but reward changes can be proposed to the NNS and adopted by voters at any time.

== Remuneration models ==
The NNS distributes rewards depending on:

* The generation of the node hardware (gen-1/gen-2)
* Geographic location
* The total number of nodes a provider operates 
Different hardware generations lead to varying capital expenditures (CAPEX) and operating expenditures (OPEX), which can also fluctuate based on geographic location. Furthermore, certain locations are deemed more valuable for enhancing network decentralization, resulting in higher rewards for Node Providers in those areas.

Two [[Node Provider Machine Hardware Guide|node machine hardware generations]] are currently recognized: gen-1 and gen-2. Each hardware generation is associated with its own remuneration model. Some cost estimates are provided for the current 2nd generation, but keep in mind that actual hardware and operational expenses may differ.
{| class="wikitable"
|Hardware Type
|Remuneration Model
|-
|Gen-1
|Gen-1 type-0
|-
|Gen-1 + storage upgrade
|Gen-1 type-1
|-
|Gen-2
|V2: Gen-2 remuneration
V2.2: Gen-2 remuneration update
|-
|Gen-3
|V3: Gen-3 remuneration
|}In the future, a remuneration model will be proposed that includes both automated incentives, rewards, and penalties.

== Initial Gen-1 Remuneration Model ==

Nodes purchased prior to Genesis were considered Gen-1 nodes. All nodes started out as type-0 with the following calculations:

{| class="wikitable"
|'''TYPE-0'''
|Reward per month (in XDR)
|-
|USA
|873
|-
|US - FL/GA/CA
|1087
|-
|EU
|1087
|-
|Asia
|1212
|}

After the first nodes were up and running, the decision was made to increase the storage capacity of all nodes to support larger subnet states. Thus, a type-1 table was created to reward for the additional costs that the extra storage incurred. Rewards were also broken down further by country. These type-1 values include both the original equipment costs incurred by Gen-1 Node Providers, their operating costs, and the varied costs that Node Providers incurred to purchase the additional storage, ship it to their data centers, and get it installed in each server.

{| class="wikitable"
|'''TYPE-1'''
|Total rewards per node (in XDR)
|-
|US - FL/GA/CA
|1600
|-
|US - other
|1499
|-
|Canada
|1624
|-
|Slovenia
|1720
|-
|Switzerland
|1696
|-
|EU - other
|1584
|-
|Singapore
|1842
|-
|Japan
|1773
|}
An [[Proposed Gen-1 Remuneration Model|Interim Gen-1 Remuneration Model]] was initially approved for when the original 48-month agreements are completed, but it has since been replaced with the Gen-1.1 Remuneration Model.

== Gen-1.1 Remuneration Model ==
This section presents the remuneration model for Gen-1 servers which are continuing to run as IC nodes beyond their initial 48 months.

With the adoption of [https://dashboard.internetcomputer.org/proposal/132553 motion proposal #132553] as discussed in [https://forum.dfinity.org/t/proposal-update-interim-gen-1-node-provider-remuneration-after-48-months/35001 this forum post], a new post-48-month remuneration model was adopted for Gen1 node machines. This remuneration model implements fixed and lower rewards for Gen1 node machines after 48 months of operation, with a maximum of 42 nodes per node provider. The expected length of time that these rewards will remain in force is 24 months.

With the adoption of [https://dashboard.internetcomputer.org/proposal/135253 motion proposal 135253] as discussed in [https://forum.dfinity.org/t/proposal-update-interim-gen-1-node-provider-remuneration-after-48-months/35001/208 this forum post], an extra 10% of the highest Gen-1.1 rewards was given to the node providers that chose to relocate their nodes to a non-EU member state.
{| class="wikitable"
!TYPE-1.1
!Reward per node per month (in XDR)
|-
|US - FL/GA/CA
|1072
|-
|US - other
|1004
|-
|Canada
|1088
|-
|Slovenia
|1152
|-
|Switzerland
|1136
|-
|EU - other
|1061
|-
|Singapore
|1234
|-
|Japan
|1188
|-
|Non-EU (relocation)
|1357
|}
As part of that approved motion proposal:

* Excess nodes may be sold to another NP while keeping the nodes in the same data center.
* Excess nodes may be sold to an optimal NP with the nodes moved to a new country and data center.
* No node provider can have more than 42 nodes.
The steps that the new NP must follow are outlined here: [[Steps for Gen-1 Node onboarding after 48 months]]

== Gen-2 Remuneration Model ==

This section presents the remuneration model for 2nd generation Node Providers.

Based on the feedback from Node Providers and the community, discussed in this [https://forum.dfinity.org/t/the-state-and-direction-of-decentralization-nodes-on-the-internet-computer/9170/128?u=svenf forum post], the Gen2 remuneration model is based on the following principles:
* Higher rewards for the first nodes of a new Node Provider in order to attract more Node Providers in an effort to improve ownership decentralization.
* More refined rewards for nodes in new geographies, like South America, Africa, Asia and Australia, to stimulate further geographical decentralization.

The node reward model is parametrized by:
*'''Geography multiplier (mult)''': This multiplier will be lower, namely 2, for regions with many nodes (e.g. Europe and North America), and higher, namely 3, for regions where there are currently limited nodes present (such as Africa and South America)
*'''Reduction coefficient (r)''': The node reward of the n-th node of a Node Provider is multiplied by r ^ (n-1). The reduction coefficient r is dependent on the geography of the Node Provider. As a result, the first nodes of a Node Provider get attractive rewards, but it is increasingly less attractive to add additional nodes.

The rewards are furthermore dependent on estimated capital and operational expenses that vary based on geographies. A table with the concrete numbers follows below.

In summary, for a geography '''g''', let
* mult('''g''') be the geography multiplier
* cost('''g''') be the total costs over 4 years for acquiring and maintaining a gen 2 node in g in XDR
* r('''np''', '''g''') be the reduction coefficient

The monthly reward for the n-th node of a Node Provider ('''np''') in geography '''g''' are defined as follows:
reward('''g, n''') = cost('''g''') * mult('''g''') * r('''np, g''') ^ (n-1) / (4 * 12)
If a Node Provider has nodes in more than one type or geography but within the same country, the NNS knows that they are in the same country and counts the combined total of nodes, each according to their own type and geography.

The total costs over 4 years are multiplied by the geography multiplier, multiplied by the reduction coefficient, and divided by 4 years times 12 months. As a result, rewards for nodes in new geographies and for Node Providers with few nodes are higher. Thereby, a geographical and ownership decentralization is incentivized. The following table shows the geography-dependent values and the monthly reward for the first node onboarded.

{| class="wikitable"
|Geography
|Total cost over 4 years
|Multiplier
|Monthly reward for 1st node (in XDR)
|Reduction coefficient r
|-
|USA
|31034
|2
|1294
|0.7
|-
|US - FL/GA/CA
|37031
|2
|1542
|0.7
|-
|EU
|36996
|2
|1542
|0.95
|-
|Asia Singapore/Japan
|40508
|2
|1688
|0.7
|-
|Asia non Singapore
|40508
|3
|2532
|0.98
|-
|South Africa
|43986
|3
|2748
|0.98
|}

Note that the reduction coefficient r('''np, g''') is applied per (Node Provider + Country) pair. This means if there is more than one Node Provider in the same country, r('''np, g''') is calculated separately for them. For instance: Node Provider A has 10 nodes in France (EU); reduction coefficient for the 1st node of Node Provider A is 0.95, and for the 10th node is 0.95 ^ 9 = 0.63. If there is Node Provider B with 10 nodes in France (EU) as well, they will get the same rewards as Node Provider A.

As an example, the below table shows the calculation of the rewards of the 1st to the 10th node for a Node Provider in South Africa.
reward('''south africa, n''')
= cost('''south africa''') * mult('''south africa''') * r('''south africa''') ^ ('''n'''-1) / (4 * 12)
= ( 21’455 + 22’531) * 3 * 0.98 ^ ('''n'''-1) / (4 * 12)
= 2748 * 0.98 ^ ('''n'''-1)
{| class="wikitable"
|N-th node
|Multiplier (rounded)
|Monthly remuneration (rounded, in XDR)
|-
|Node 1
|0.98 ^ (1-1) =1
|2748
|-
|Node 2
|0.98 ^ (2-1) =0.98
|2693
|-
|Node 3
|0.98 ^ (3-1) =0.96040
|2639
|-
|Node 4
|0.98 ^ (4-1) =0.941192
|2586
|-
|Node 5
|0.98 ^ (5-1) =0.92236816
|2534
|-
|Node 6
|0.98 ^ (6-1) =0.9039207968
|2483
|-
|Node 7
|0.98 ^ (7-1) =0.885842309
|2434
|-
|Node 8
|0.98 ^ (8-1) = 0.8681255332
|2385
|-
|Node 9
|0.98 ^ (9-1) =0.8507630226
|2337
|-
|Node 10
|0.98 ^ (10-1) =0.8337477621
|2291
|}

[[File:Profit margin for each additional node graph for remuneration V2.png|1000px]]

The above figure shows the additional cash flow (investments minus costs) a Node Provider receives for adding an additional node for three regions (South Africa, Europe and USA) that can be calculated based on the Version 2 remuneration model. Note that the calculation does not take into account the time value of the cash flows (i.e. discounted value), but purely the cash flows or rewards and expenses.

What is visible from this graph is that adding additional nodes only generates additional cash flow for a specific number of nodes, in a specific region. For example, in Europe adding up to approximately 15 nodes will generate additional cash flow, whereas for the US region, this is only 2 nodes.

Potential new Node Providers can make a full calculation themselves of the Internal Rate of Return, Payback period and cash flow based on their actual CAPEX and OPEX costs. Of course, these actual CAPEX and OPEX costs may differ from the costs on which the remuneration is based, depending on the specific contracts the new Node Provider has been able to negotiate with hardware vendors and DC operators.

=== Version 2.1 Remuneration Model ===
The Version 2.1 remuneration model replaces the Version 2 remuneration for 2nd generation Node Providers. It includes the following changes compared to Version 2, based on discussion in this [https://forum.dfinity.org/t/the-state-and-direction-of-decentralization-nodes-on-the-internet-computer/9170/192 forum thread]:

* No entry for the region Asia will be used anymore. For the Asia region, specific country entries will be used.
* Specific entries for Hong Kong and India will be added to the remuneration table.
* The multiplier is set to a value of 2 for all countries. In future, this might be updated through a new NNS proposal if the community determines that the risk premium for projects should be different for different countries (for example, if the risk of running in node in one specific country is higher than the risk of running in node in another country, this might validate a different multiplier).
* A limit is set to the number of nodes in new countries for which the remuneration applies. Once this is reached, the reduction coefficient for additional nodes will be adjusted to allow adding only one or two nodes for this country, similar to existing countries like the U.S. and Switzerland. Currently, the limit of number of nodes per country is set to 50 nodes, which allows NP’s to add a node in that specific country to every available subnet and have a small set of additional nodes in case nodes are unhealthy or require maintenance.
* Version 2 was relevant for a limited time period in 2023. Version 2.1 became the current model as of May 2023.

The following table shows the geography-dependent values and the monthly reward for the first node onboarded based on the Remuneration Version 2.1.

With this latest update, there are sufficient node machines for running the current load of canisters on every subnet, and for the decentralisation of the subnets measured in Nakamoto coefficients; no new country entries will be added. Work is in progress on an IC Topology Roadmap for the next half year and the next year, with the objective to assess how many node machines and where new node machines are required for further growth and decentralisation of the IC network. Based on that it will be discussed on the IC forum what changes to make to the Node Provider remuneration table and subsequent proposals will be submitted to the NNS for the community to vote upon.

{| class="wikitable"
|Geography
|Total costs over 4 years
|Multiplier
|Monthly reward for 1st node (in XDR)
|Reduction coefficient r
|-
|US
|31034
|2
|1294
|0.7
|-
|US California
|37031
|2
|1543
|0.7
|-
|Canada
|37031
|2
|1543
|0.7
|-
|Germany
|36996
|2
|1542
|0.7
|-
|Switzerland
|36996
|2
|1542
|0.7
|-
|France
|36996
|2
|1542
|0.7
|-
|Belgium
|36996
|2
|1542
|0.7
|-
|Slovenia
|36996
|2
|1542
|0.7
|-
|Europe (other than above)
|36996
|2
|1542
|0.95
|-
|Israel
|49500
|2
|2063
|0.95
|-
|Japan
|40508
|2
|1688
|0.7
|-
|Singapore
|40508
|2
|1688
|0.7
|-
|Hong Kong
|46141
|2
|1922
|0.95
|-
|India
|50377
|2
|2100
|0.95
|-
|South Korea
|51774
|2
|2158
|0.95
|-
|Sri Lanka
|52800
|2
|2200
|0.95
|-
|Georgia
|57455
|2
|2394
|0.95
|-
|South Africa
|55455
|2
|2310
|0.95
|-
|Australia
|47000
|2
|1958
|0.95
|-
|New Zealand
|47000
|2
|1958
|0.95
|-
|Panama
|51774
|2
|2158
|0.95
|-
|Costa Rica
|51774
|2
|2158
|0.95
|-
|Colombia
|57455
|2
|2394
|0.95
|-
|Argentina (proposed)
|57455
|2
|2394
|0.95
|}

== Reward calculator ==
For your convenience, we prepared the following [https://www.calconic.com/calculator-widgets/ic-node-provider-rewards/659d42a6d96fa70029e56629?layouts=true calculator for the node rewards]

== Trustworthy Node Metrics ==
In February 2024, Trustworthy Node Metrics were introduced on the IC, in an attempt to provide greater visibility into node performance, stability, and reliability. These metrics could potentially be used to influence node rewards in the future.

There is a forum post here https://forum.dfinity.org/t/trustworthy-node-metrics-for-useful-work/22989, then

Blog post on Medium here: https://medium.com/dfinity/dont-trust-verify-new-node-metrics-on-the-internet-computer-367cc154a572

And technical documentation and instructions here: https://dfinity.github.io/dre/trustworthy-metrics/trustworthy-metrics.html
== Performance-based Rewards ==
Introduction of Performance-based Rewards (PBR) incentivizes Node Provider to keep their nodes healthy and prominently address any issue with the hardware or connectivity, as well as proactively communicate any problems that appear to be within the IC-OS stack. See the [[Performance-based Rewards]] for the details.

Performance-based Rewards

2025-11-24T00:21:40Z

Alexander.ufimtsev: Added a page on Performance-based Rewards

===Introduction===
The ICP network incentivizes node providers to contribute their nodes by paying them ‘'''node rewards'''’. These rewards have been static to date, regardless of node performance. Introduction of Performance-based Rewards (PBR) incentivizes Node Provider to keep their nodes healthy and prominently address any issue with the hardware or connectivity, as well as proactively communicate any problems that appear to be within the IC-OS stack.

===How do Performance-based Rewards V1 Work?===
PBR treats the current Node rewards as the base maximum each eligible node can achieve in a month, i.e. 100%. It is then augmented with Node Trustworthy Metrics to show how each node has performed each month. In particular, Trustworthy Metrics depend on ‘''Block Maker Failure Rate''’. In short, the Nodes in a subnet are given an equal number of chances to make a block to keep the subnet running. However, if a node isn’t reachable or starved of resources (CPU, RAM, Disk I/O), it won’t be able to create a block, thereby increasing the ‘''Block Maker Failure Rate''’. This statistic is collected regularly by the NNS, which uses it to compute the performance reduction score between 0 and 100%. As illustrated below, the reward reduction is 0 for failure rates up to 10%, then increases linearly to 80% at a failure rate of 60%, and finally stays at 80% for higher failure rates.
[[File:Reward reduction vs failure rates.png|thumb|alt=|center]]

==== PBR and Unassigned Nodes. ====
If nodes do not belong to any subnet, they do not participate in block-making activities, making it impossible to use Trustworthy Metrics for their performance. As a result, unassigned nodes are getting rewards based on the average performance of the assigned nodes for each node provider. Each node provider will have at least one assigned node to calculate the average score.

==== Calculating Failure Rate ====
For each node in a subnet, the system calculates:
Node Failure Rate = Failed Blocks / (Proposed Blocks + Failed Blocks)

==== Subnet Performance ====
Multiple nodes in each subnet can fail to make blocks. To make the calculation fair and not punish everyone, each subnet calculates its overall performance using 75th Percentile. So, the subnet uses the node that is slower than 3/4 of all nodes to set its performance. For example, in a hypothetical subnet with four nodes with failure rates [0.99%, 4.76%, 16.67%, 33.33%] (sorted), the 3rd-slowest node (failure rate:16.67%) will be used as the overall subnet performance.

==== Relative Performance ====
Once Subnet Performance is computed, a relative performance metric for each node can be derived.
Relative Performance = Max(0, Node Failure Rate - Subnet Performance)
For example, the Node failure rate is 33.33%, and the subnet performance is 16.67%. So, relative node performance is therefore (33.33%- 16.67%) = 16.66%. This reduces each node's failure rate by the failure rate of the subnets it is in, making the score fairer for everyone.

==== Performance Multiplier ====
To derive a performance multiplier for the relative node performance, the following formula is used:
If Relative Performance < 10%:
 Performance Multiplier = 1.0 (No penalty)
Else If Relative Performance ≥ 60%:
 Performance Multiplier = 0.2 (Maximum penalty - 80% reduction)
Else:
 Performance Multiplier = 1.0 - ((Relative Performance - 10%) / (60% - 10%)) × 80%
If we use our example:
*Relative performance: 16.66%
*Since 10% ≤ 16.66% < 60%:
*Penalty = ((16.66% - 10%) / (60% - 10%)) × 80% = 10.66%
*Performance Multiplier = 1.0 - 10.66% = 89.34%
Therefore, the node will get 89.34% of its possible rewards for its Generation and location remuneration.

=== Working with Performance Data ===
Both commercial, free and open source tools are available for retrieving node performance data.

==== Command Line Tool (Open Source) ====
PBR support has been fully integrated into ‘dre’ tool (https://github.com/dfinity/dre). You can obtain it for Linux and MacOS by downloading it from (https://github.com/dfinity/dre/releases). In case you already have dre tool installed, you can upgrade it by running <code>dre upgrade</code>.

===== Current Rewards =====
To display current node rewards, run <code>dre node-rewards ongoing</code>. This will display a list of node provider principals, current projected rewards vs the base (100% potential), and the difference between them. It will also display a list of underperforming nodes.

===== Past Rewards =====
To display rewards for the previous month, run ‘dre node-rewards past-rewards YYYY-MM, where YYYY is a year and MM is a month you are interested in.

<code>dre node-rewards past-rewards 2025-10</code>

This will display a breakdown for each node provider for each day within that reward period.

===== Exporting data as CSV =====
It might be more comfortable to export the data into a spreadsheet. For that, there is <code>--csv-detailed-output-path</code> parameter. If specified, it will use the specified folder (you can use a dot (.) for the current folder or select another). It will create a folder with details for all nodes and all node providers.

Open the folder and find the sub-folder for your node provider principal. Within that folder, you will find a variety of CSV files:
1. rewards_summary: One record for each day, showing:
* The rewards_total_xdr_permyriad value of rewards earned
* The number of nodes found in the registry
* The first five characters of the ID of nodes that were underperforming that day, if any
2. base_rewards: One record for each day for each type of node showing:
* The monthly_xdr_permyriad value for that area from the rewards table
* The daily_xdr_permyriad value (monthly / 30.4375)
* The node reward type (if NP has more than one type registered, then there will be more than one record for each day
* The region that is called from the rewards table
3. base_rewards_type3:
*
4. A file for each node that was registered in the NNS that month, which records for each day:
* The node type
* The region it’s registered to
* The DC
* The subnet it was assigned to that day, if any
* subnet_assigned_fr_percent
* Number of blocks proposed for that subnet
* Number of blocks failed for that subnet
* original_fr_percent
* relative_fr_percent
* extrapolated_fr_percent
* performance_multiplier_percent
* rewards_reduction_percent = The penalty percentage applied that day
* base_rewards_xdr_permyriad = Base rewards from the rewards table
* adjusted_rewards_xdr_permyriad = Adjusted rewards after penalty applied
* Node status assigned or not

=== Analyzing Node Penalties and Their Impact on Rewards: ===

# Download the CSV and locate the folder for your own NP principal
# Use the Rewards Summary file to identify which nodes had issues that month quickly
# Please open the file for that particular node to see which day(s) it had issues, the block failure rate for that day, and how the NNS calculated the penalty for that day. Details on the exact formulas that are used are provided in the first section of this document.

File:Reward reduction vs failure rates.png

2025-11-24T00:11:16Z

Alexander.ufimtsev:

The graph of Reward reduction vs failure rates

George Bassadone

2025-10-24T11:11:35Z

Alexander.ufimtsev:

=== Proof of Identity: ===
[[File:Proof of Identity George Bassadone.pdf|thumb|1479x1479px]]

==== Self Declaration document: ====
[[File:Self-declaration form Signed.pdf|thumb|1485x1485px]]
Compliance Assessment
[[File:15 09 Compliance Assessment George Bassadone signed.pdf|thumb]]

Bianca-Martina Rohner

2025-09-05T14:57:04Z

Alexander.ufimtsev:

== Self-declaration ==
SHA256 hash: ca3973712c4d7947b0b835368ca0648696d52ff6e7ed69a7c92766c1da51e0ce
[[File:BMR self declaration.pdf|center|thumb|1133x1133px|

]]

== Identity document ==
SHA 256 hash: 2c1fa30253103788b7c6510bb1fc66fd4e11b9e9df163ec936c9a460b377ade2

[[File:BMR identity proof.pdf|center|thumb|1133x1133px]]

== Candidate Node Validation ==

Panama node machines
[[File:Optimization Model Panama.pdf|center|thumb|1132x1132px|Optimization Model Panama]]Compliance Assessment

== Compliance document ==
[[File:NEW_25_08_Compliance_Assesment_Bianca_Martina_Rohner_signiert.pdf|thumb|Compliance assessment]]

Node Provider Onboarding

2025-09-02T15:52:37Z

Alexander.ufimtsev: changed the rules for picking DC name that is more consistent.

Learn how to be accepted by the NNS as a Node Provider and onboard your nodes to the IC.

Please allocate up to a week to complete this guide, as it may take several days for a proposal to be accepted by the NNS, and you may have to submit multiple NNS proposals.

'''Note that the following steps do not need to be performed on the node machine itself.''' You can complete them on your personal laptop.

If you encounter issues through any of these steps, check the [[Node Provider Troubleshooting]] page. If that does not solve your problem, you are encouraged to ask for assistance in the [[Node Provider Matrix channel]].

For regular operations after onboarding, please refer to [[Node Provider Maintenance Guide|Node Provider Maintenance Guide.]]

== '''<big>Requirements</big>''' ==
* Assure your node(s) meet the [[Node Provider Machine Hardware Guide|Node Provider Machine Hardware requirements.]]
* View the [[Node Provider Networking Guide|Node Provider Networking Guide.]]
* Setup a [https://www.ledger.com/ hardware wallet].
*[https://shop.nitrokey.com/shop/product/nkhs2-nitrokey-hsm-2-7/ NitroKey HSM] (Optional, legacy—not recommended).
* 26 ICP (25 of which are to be staked for the NNS proposal deposit).
* Basic understanding of [[Neurons 101|neurons]], [https://internetcomputer.org/docs/current/tokenomics/nns/nns-staking-voting-rewards staking], and [[Governance of the Internet Computer|governance]] proposals, such as understanding what it means to stake a neuron for 8 years.

== 1. Install the required tools ==
===''' A. Install ic-admin '''===

<code>ic-admin</code> is the tool used to create and submit NNS proposals. You can install it by running the following in a terminal:

==== MacOS ====
<syntaxhighlight lang="shell">
curl -L "https://github.com/dfinity/ic/releases/latest/download/ic-admin-x86_64-darwin.gz" -o - | gunzip > ic-admin && chmod 0755 ./ic-admin

</syntaxhighlight>

==== Linux ====
NOTE: The instructions below have been tested with the Ubuntu 20.04 release<syntaxhighlight lang="shell">
curl -L "https://github.com/dfinity/ic/releases/latest/download/ic-admin-x86_64-linux.gz" -o - | gunzip > ic-admin && chmod 0755 ./ic-admin
</syntaxhighlight>

===''' B. Install dfx '''===

#<code>dfx</code> is a CLI tool used to generate neuron hotkeys, among other things such as canister deployment and management. <syntaxhighlight lang="shell">
$ sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh)"

</syntaxhighlight>
#Verify that <code>dfx</code> is up to date. <syntaxhighlight lang="shell">
$ export PATH=$HOME/bin:$PATH
$ dfx upgrade
$ dfx --version
</syntaxhighlight>

==2. Create Node Provider hotkey ==

#Create an identity for the Node Provider '''hotkey''' <syntaxhighlight lang="shell">
$ dfx identity new --storage-mode=plaintext node-provider-hotkey

Created identity: "node-provider-hotkey".

$ dfx --identity node-provider-hotkey identity get-principal

xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
# example node-provider-hotkey: wuyst-x5tpn-g5wri-mp3ps-vjtba-de3xs-w5xgb-crvek-tucbe-o5rqi-mae

</syntaxhighlight>'''You will need the Node Provider hotkey in the next steps.'''

'''Note''': The Node Provider hotkey is NOT the Node Provider principal. This is the hotkey that is used for the NNS proposal submissions only.

'''Note''': You may be prompted to enter a passphrase when creating your identity and accessing your identity principal. Take note of the passphrase you choose.

==3. Create and Manage Neuron via NNS Frontend Dapp and Internet Identity==

#Send at least 26 ICP tokens to your hardware wallet address.
#Navigate to the Neurons tab and create a Neuron by staking at least 26 ICP from your hardware wallet. Staking more ICP is acceptable, but 25 is the minimum needed for this process, and you must have a little more for transaction fees.
#IMPORTANT! Confirm the transaction on your hardware wallet.
#:[[File:-docs-stake_neuron_1.png|1024px|stake neuron]]
#After the Neuron has been created successfully, confirm to "Add NNS Dapp as hotkey" in the dialogue and on your hardware wallet, and close the dialog after the action completes.
#:[[File:-docs-stake_neuron_2.png|1024px|neuron id]]
#Set the dissolve delay to at least 6 months, and confirm the choice in the dialogue and on your hardware wallet. After the action completes, you can close the "Follow Neurons".
#:[[File:dissolve_delay.png|480px|neuron id]]
#You will now see a Neuron listed with its ID. Copy the Neuron ID, since you will need it in the next steps to place the necessary proposals.
#:[[File:Neuron id.png|1024px]]

==4. Add hotkeys==

#Select the Neuron you just created to open Neuron management view and press “Add hotkey” button.
#:[[File:Hotkey 1.png|873x873px]]
# A dialog will pop up where you can enter the hotkey you generated in step 2.1 (output from command <code>dfx --identity node-provider-hotkey identity get-principal</code>). This will allow you to submit NNS proposals using <code>ic-admin</code> and will not be used for anything else. 
#:Press the '''confirm''' button and confirm the transactions on your hardware wallet. 
#:[[File:Hotkey 2.png|899x899px]]
#Get the Ledger Hardware Wallet Principal Id: Navigate back to ICP page and select your Ledger hardware wallet account. You will need to use this Ledger Hardware Wallet principal as the Node Provider principal in order to get the rewards directly into the secure hardware wallet.
#:[[File:Node provider principal 1.png|1024px]]
#:[[File:Node provider principal 2.png|800px]]
#Copy and save this Node Provider principal by clicking on the copy icon after the principal id. You'll need it in the next steps. <syntaxhighlight lang="shell">
$ NODE_PROVIDER_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
# Input ledger Hardware Wallet principal, from the NNS FrontEnd dapp https://nns.ic0.app/

# example: $ NODE_PROVIDER_PRINCIPAL=fharn-5vyi2-4xb4a-64yyi-3jpmj-pga23-mxy25-d5uim-fqcro-eoefh-tae
</syntaxhighlight>

==5. Choose onboarding path (HSM vs no HSM)==
Onboarding '''without''' a NitroKey HSM is the current onboarding path. In particular, node providers onboarding [[Node Provider Machine Hardware Guide|Gen 2 hardware]] must onboard '''without''' a NitroKey HSM. If you will be onboarding '''without''' a NitroKey HSM, continue to the next step.

If the legacy procedure is required for your onboarding (which should only be the case in rare and exceptional situations), follow the [[NitroKey HSM onboarding instructions]] and then '''return to step 8.'''

==6. Setup the Node Operator keys ==
#'''''Ensure dfx is at least version 0.14.''''' Node Operator keys created with older versions of dfx '''will fail to join the IC'''. Run:<syntaxhighlight lang="bash">
$ dfxvm update
$ dfx --version
</syntaxhighlight>
#Create a new principal with dfx:<syntaxhighlight lang="shell">
$ dfx identity new --storage-mode=plaintext node_operator
</syntaxhighlight>
#Confirm <code>node_operator</code> identity was created successfully:<syntaxhighlight lang="shell">
$ dfx identity list
</syntaxhighlight>This list ''should'' contain <code>node_operator</code>.
#Copy new key to a known location:<syntaxhighlight lang="shell">
$ cp ~/.config/dfx/identity/node_operator/identity.pem ./node_operator_private_key.pem
</syntaxhighlight>
#Check the contents of the <code>node_operator_private_key.pem</code> file and double check that it contains the following contents. It is imperative that the first line has <code>-----BEGIN EC PRIVATE KEY-----</code>. If it does not, make sure you use the latest <code>dfx</code> version and that you followed the instructions precisely.<syntaxhighlight lang="shell">
❯ cat ./node_operator_private_key.pem
-----BEGIN EC PRIVATE KEY-----
[3 lines of base64 encoded private key, e.g. n2Nhp68YcQpuS0u96r...]
-----END EC PRIVATE KEY-----
</syntaxhighlight>Note: you must retain access to the <code>node_operator_private_key.pem</code> file for when you onboard nodes in '''[https://wiki.internetcomputer.org/wiki/Node_Provider_Roadmap#Milestone_Five:_Node_Machine_Onboarding roadmap milestone five.]'''

==7. Get the node operator principal==

#Get the principal:<syntaxhighlight lang="shell">
$ NODE_OPERATOR_PRINCIPAL=$(dfx --identity node_operator identity get-principal)
$ echo $NODE_OPERATOR_PRINCIPAL

uqquy-76uhn-2mys5-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
</syntaxhighlight>
'''You will need the node operator principal in the next steps.'''

==8. Register your Node Provider principal to the network==
In the next codeblock:
*Replace the <code>NODE_PROVIDER_NAME</code> value with the name of the entity that will provide the nodes.
*Replace the <code>NODE_PROVIDER_PRINCIPAL</code> value with the Ledger Hardware Wallet principal that you got from the NNS Frontend Dapp (step 4.4)
*Replace the <code>NEURON_ID</code> value with your neuron ID from the NNS Frontend Dapp (step 3.6)

*'''''IMPORTANT:''''' Please make sure that you also update the <code>--summary</code> and include a link to the forum discussion, your company's web page, and/or to another place that can convince the voting community that you are making a legitimate request. You must also include the file hash for the [[Node Provider Self-declaration|self declaration and proof of identity documents]], or the proposal will be rejected. This way you will avoid the community voting NO to your proposal and you losing your staked ICPs.

##Create the Proposal <syntaxhighlight lang="shell">
$ NODE_PROVIDER_NAME="My Company"
$ NODE_PROVIDER_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ NEURON_ID=XXXXXXXXXXXXXXXXXXXX
$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-add-or-remove-node-provider add \
--proposer $NEURON_ID \
--proposal-title "Register a node provider '${NODE_PROVIDER_NAME}'" \
--summary "Register a node provider '${NODE_PROVIDER_NAME}', in line with the announcement and discussion at <https://forum.dfinity.org/t/...>. The self-declaration documentation is available at <https://wiki.internetcomputer.org/wiki/...> with SHA256 hash <SHA256>. The proof of identity is available at <https://wiki.internetcomputer.org/wiki/...> with SHA256 hash <SHA256>." \
--node-provider-pid "$NODE_PROVIDER_PRINCIPAL"
</syntaxhighlight>Note: make sure <code>${NODE_PROVIDER_NAME}</code> is presented in single quotes, so the IC dashboard can pick up and display the correct Node Provider name.
#Find the proposal on https://dashboard.internetcomputer.org/governance and '''wait until it is executed before proceeding to next step.'''
#In order to expedite the speed of your proposal's approval, it is best to create a post in this [https://forum.dfinity.org/t/new-node-provider-proposals/16643/69 forum thread] to raise awareness of your proposal. You can use this as a [https://docs.google.com/document/d/1nKy5hKiF72a4NCHvpgij-Np9pbtR5KOBbF1W6qr-nds/edit?usp=sharing template] for the post.

''See guide for [[Troubleshooting Failed NNS proposals]]''

==9. Register your datacenter to the network (if necessary)==
#Search for your data center on https://dashboard.internetcomputer.org/centers.
#*If you found the datacenter that is hosting your nodes, remember its ID, and skip the following section. Otherwise, proceed with the registration of a new DC record.
#:[[File:dc_id.png|1041x1041px|alt=]]
===Create a data center record for a new DC===
In the next block of code:
*Replace the <code>NEURON_ID</code> value with your neuron ID from the NNS Frontend Dapp (step 3.6)
*Replace the JSON fields from the <code>–data-centers-to-add</code> argument and their corresponding values in <code>--summary</code>:
**<code>"id"</code> represents the city that your datacenter is in and is formulated as a combination of two letters representing the city and an incrementing number. Search data center IDs on https://dashboard.internetcomputer.org, and find a combination of two letters that’s not yet registered.
***''If the city or region where the new DC is located, has already been "named" by another DC in the same city or region, then pick the same letters and increment the number.''
***''If there is no other DC in this city or region, then pick a new letter-abbreviation that is not used yet and give it the number 1.''
***Examples:
****dl1 (Dallas, no IDs with “dl” prefix)
****zh10 (Zurich, numbers 0-9 are already registered)
***:[[File:dc_id.png|1024px]]
**<code>"region"</code> represents the local region of a datacenter and is formulated as a three-part string divided by commas. The three parts making the string are continent, country code, and region, in the given order. Examples:
***North America,US,Florida
***Europe,DE,Bavaria
***Asia,SG,Singapore
**:[[File:datacenter_region.png|1024px]]
**<code>"owner"</code> The entity that provides your datacenter facilities.
***Search https://dashboard.internetcomputer.org for existing data center providers.
***If there’s match, make sure you use the same exact some name for your datacenter.
***Otherwise, name the data center owner to your best knowledge.
**:[[File:datacenter_owner.png|1024px]]
**<code>"gps"</code> GPS coordinates.
***Find your datacenter on https://www.google.com/maps/.
***Right click on location, and select the GPS coordinates (first item in the menu) in order to copy them.
**:[[File:maps.png|310x310px|alt=Getting GPS coordinates|Getting GPS coordinates]]

#Create the proposal. **Make sure you include in the text of the proposal, a link to your forum post with additional details and reference so the community can easily find additional information and ask questions. <syntaxhighlight lang="shell">
$ NEURON_ID=XXXXXXXXXXXXXXXXXXXX
$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-add-or-remove-data-centers \
--summary "Register a Flexential datacenter as dl1 in North America,US,Texas" \
--skip-confirmation \
--proposer $NEURON_ID \
--data-centers-to-add '{
"id": "dl1",
"region": "North America,US,Texas",
"owner": "Flexential",
"gps": [
33.00803, -96.66614
]
}'
</syntaxhighlight>'''Remember to replace all the values of both the arguments <code>–data-centers-to-add</code> and <code>--summary</code>'''
#Find the proposal on https://dashboard.internetcomputer.org/governance and wait until it's executed before proceeding to next step.
#In order to expedite the speed of your proposal's approval, it is best to create a post in this [https://forum.dfinity.org/t/new-node-provider-proposals/16643/69 forum thread] to raise awareness of your proposal. You can use this as a [https://docs.google.com/document/d/1Hg0tI9O5__Tp4qKrNKuTADsQT7Z47I6aAFXbiDimG_U/edit?usp=sharing template] for the post.

''See guide for [[Troubleshooting Failed NNS proposals]]''

==10. Create a node operator record==
'''''IMPORTANT''':'' Before submitting the Node Operator record, please go through the description of [[Validation of Candidate Node Machines]] to validate whether additional node machines are needed for decentralization of the IC-network.

*Create a pdf with the outcome of running the optimization model and the steps that allow the community to reproduce the validation check.
*Include the pdf in the wiki page that includes the NP documents (self-declaration and proof-of-identity document)
*Include a link to the pdf as well as the hash of the document in the Node Operator record proosal.

In the next codeblock:
*Replace the <code>NEURON_ID</code> value with your neuron ID from the NNS Frontend Dapp (step 3.6).
*Replace the <code>NODE_PROVIDER_PRINCIPAL</code> value with the Ledger Hardware Wallet principal that you got from the NNS Frontend Dapp (step 4.4).
*Replace the <code>NODE_OPERATOR_PRINCIPAL</code> value with your node operator principal (step 7.1). '''Important''': if you are adding an additional node operator record because you will deploy nodes in another data center, please make sure to create a new node operator principal first (steps 6 and 7). A node operator principal can only be tied to 1 data center.
*Replace the <code>NODE_PROVIDER_NAME</code> value with the name of the entity that will provide the nodes.
*Replace the <code>NODE_ALLOWANCE</code> variable value with number of nodes you are providing.
*Replace the <code>DC_ID</code> variable value with id of your datacenter.

#Create the proposal: <syntaxhighlight lang="shell">
$ NEURON_ID=XXXXXXXXXXXXXXXXXXXX
$ NODE_PROVIDER_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ NODE_OPERATOR_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ NODE_PROVIDER_NAME="My Company"
$ NODE_ALLOWANCE=8
$ DC_ID=dl1

$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-add-node-operator \
$NODE_PROVIDER_PRINCIPAL \
--summary "Node provider '$NODE_PROVIDER_NAME' is adding $NODE_ALLOWANCE nodes in the $DC_ID data center. The result of the canidate node machine validation and exact configuration run is available at <https://wiki.internetcomputer.org/wiki/...> with SHA256 hash <SHA256>." \
--proposer $NEURON_ID \
--node-operator-principal-id $NODE_OPERATOR_PRINCIPAL \
--node-allowance $NODE_ALLOWANCE \
--dc-id $DC_ID
</syntaxhighlight>
#Find the proposal on https://dashboard.internetcomputer.org/governance and wait until it's executed before proceeding to next step.

''See guide for [[Troubleshooting Failed NNS proposals]]''

DFINITY Stiftung

2025-08-22T14:10:27Z

Alexander.ufimtsev: added audit results

====Self-declaration====
Also see [[DFINITY Foundation]].
[[File:CHE189770146-19.12.2024-Merkmale DFINITY Stiftung.pdf|thumb|alt=|none]]
[[File:DFINITY Self-declaration (1) (1).pdf|thumb|alt=|none]]

====Audit Results====
[[File:CERTIFICATE_OF_COMPLIANCE_Dfinity_Foundation_Final_signed.pdf|thumb|alt=|none]]
====Swiss registration====
[[File:DFINITY Stiftung Central Business Index listing.pdf|thumb|alt=|none]]

==== Handover document to Zarety LLC for 42 of the nodes in BO1 and AT1 that we sold to Zarety. ====
[[File:Complete with Docusign Zarety DFINITY node.pdf|none|thumb]]

==== Handover document to Blue Ant LLC for the 42 nodes in AT1 and MR1 that we sold to Blue Ant ====
[[File:Enzo's copy of 2024.12 - DFINITY node hand over statement (1).pdf|none|thumb]]

File:CERTIFICATE OF COMPLIANCE Dfinity Foundation Final signed.pdf

2025-08-22T13:56:04Z

Alexander.ufimtsev: DFINITY Stiftung Audit

== Summary ==
DFINITY Stiftung Audit

Node Provider Self Declarations

2025-08-22T13:40:07Z

Alexander.ufimtsev:

<blockquote>'''''NOTE: Please try to keep entries in this document alphabetically sorted, to reduce conflicts in edits.'''''

</blockquote>

[[0X52]]

[[100 Count Holdings, LLC]]

[[43rd Big Idea Films, LLC]]

[[87m Neuron, LLC]]

[[ACCUSET SOLUTIONS]]

[[Arceau NP LLC]]

[[Aitubi AG]]

[[Aksinia Stavskaya]]

[[Altimist Ltd]]

[[ALLUSION BV]]

[[AlpineDC SA]]

[[User:Alpha.agentic|ANTHONY ISAAKIDIS]]

[[ANYPOINT PTY LTD]]

[[AVRVM AG]]

[[Artem Horodyskyi|ARTEM HORODYSKIY]]

[[Bianca-Martina Rohner]]

[[Bigger Capital|Bigger Capital Pty Ltd]]

[[Bitapp]]

[[Bitmoon]]

[[Blockchain Development Labs Inc]]

[[BlockFinance LLC]]

[[Blocktech Ventures LLC]]

[[BLP22, LLC]]

[[Blueant LLC]]

[[Bohatyrov Volodymyr]]

[[Buldakova Rehina]]

[[CarbonTwelve]]

[[CocoMango LLC]]

[[Conic Ventures]]

[[Coplus Limited]]

[[CoreLedger]]

[[Decentralized Entities Foundation]]

[[DENODE|DeNoDe]]

[[DFINITY Stiftung]]

[[DragginCorp SARL]]

[[Eastman_Ventures_Pty_Ltd|Eastan_Ventures_Pty_Ltd]]

[[Exaion]]

[[Extragone]]

[[User:FenexLLC|FenexLLC]]

[[Ferndale International]]

[[Fractal Labs, LLC]]

[[Geeta Kalwani]]

[[GeoNodes LLC]]

[[George Bassadone]]

[[Geodd Pvt Ltd]]

[[Giant Leaf, LLC]]

[[User:James Wang|HashQuark]]

[[HoneyComb Capital]]

[[Iancu-Aurel|Iancu Aurel]]

[[Icaria_Systems_Pty_Ltd|Icaria_Systes_Pty_Ltd]]

[[Icswitch]]

[[Illusions in Art Ltd]]

[[InfoObjects Inc]]

[[Ivanov Oleksandr]]

[[Karel Frank]]

[[Katerina Karapuz]]

[[Kontrapunt (Pty) Ltd]]

[[Krishna Enterprises]]

[[Krzysztof Żelazko]]

[[Louise Velayo]]

[[Ludens LLC]]

[[Lukas Helebrandt]]

[[Marvelous Web3]]

[[Maksym Ishchenko]]

[[MB Patrankos šūvis]]

[[:File:NODE-PROVIDER-SELF.pdf|ML SOLUTIONS LTD]]

[[ML_MIST]]

[[Michael_and_Dominik_Peterer]]

[[User:Miguel.mencia|Miguel Mencia Gijon]]

[[MI Servers]]

[[Mariano Stoll]]

[[Neptune Partners]]

[[NODAL CAPITAL]]

[[NODAO]]

[[NOKU SA]]

[[Nova_LCC]]

[[NoviSystems|NoviSystems, LLC]]

[[Nataliia Nykyforak]]

[[Natalia Kulesha]]

[[Nikola Nikov]]

[[OneSixtyTwo Digital Capital]]

[[User:Soekawat|Origin Game]]

[[ParaFi Technologies NS LLC]]

[[User:Protocol16|Protocol16 (Philip Hur)]]

[[PindarTechnologyLimited]]

[[User:Powermetacorp|Power Meta Corporation]]

[[Privoxy Solutions, LLC.]]

[[Quantum Node Ltd.]]

[[Reist Telecom AG]]

[[Rivonia Holdings, LLC]]

[[Rivram Inc]]

[[Stamper Co., Ltd.]]

[[senseLAN]]

[[Serenity lotus limited]]

[[Starbase]]

[[Swiss Datalink AG]]

[[Sygnum]]

[[Technical University of Munich]]

[[Tenderloin Ventures AG|Tenderloin Ventures AG (Tomahawk.vc)]]

[[Timur Rakhimzhan]]

[[Uvaca Labs LLC]]

[[VirtualHiveLtd|Virtual Hive Ltd]]

[[Vladyslav Popov]]

[[Wolkboer (Pty) Ltd]]

[[WMA Investments Limited]]

[[Yannick Endrion]]

[[Zaboo d.o.o.]]

[[Zarety LLC]]

[[Zondax AG]]

[[User:Web3game|Web3game]]

[[User:Zenithcode|Zenith Code LLC]]

[https://wiki.internetcomputer.org/wiki/User:ZTLC_PTE_Ltd ZTLC_PTE_Ltd]

<references />

ParaFi Technologies NS LLC

2025-07-10T18:51:54Z

Alexander.ufimtsev: correcting hash

==Self-Declaration==
SHA256 hash of ParaFi_Technologies_NS_LLC_Identity_and_Compliance_Declarations.pdf: b79709b72e8f9c7785df50641f6cd692eef8b52f798f6f55f07b2ab71990131d
[[File:ParaFi_Technologies_NS_LLC_Identity_and_Compliance_Declarations.pdf|center|thumb|Self-Declaration|link=Special:FilePath/ParaFi_Technologies_NS_LLC_Identity_and_Compliance_Declarations.pdf]]

==Proof of Identity==
SHA256 hash of ParaFi_Technologies_NS_LLC_Certificate_of_Formation.pdf: 1cff8bc8fcc7e5db249a21de52971ac72338782fb6f247387c80b87abdd0d536
[[File:ParaFi_Technologies_NS_LLC_Certificate_of_Formation.pdf|center|thumb|Proof of Identity|link=Special:FilePath/ParaFi_Technologies_NS_LLC_Certificate_of_Formation.pdf]]

==Node Machine Handover Statement==
SHA256 Hash of ParaFi_Technologies_NS_LLC_Node_Machine_Handover_Statement.pdf: 35844c0ba1eb6acb584ab5ce674347bc81321d741d7a6ec8e4572e7fe04a8c7a
[[File:ParaFi_Technologies_NS_LLC_Node_Machine_Handover_Statement.pdf|center|thumb|Node Handover Statement]]

==Assessment of Independence==
SHA256 Hash of ParaFi_Technologies_NS_LLC_Assessment_of_Independence.pdf: 142b3326d53ddb5ec88d88723bb64d1ef7618d4735b740d051c6264f08f00a45
[[File:ParaFi_Technologies_NS_LLC_Assessment_of_Independence.pdf|center|thumb|Assessment of Independence]]

==Compliance Assessment==
SHA256 Hash of ParaFi_Technologies_NS_LLC_Compliance_Assessment.pdf:
4bc6501bb7e9379cf55ca2a90c0e206ef521f69029eafcab8aac2ad59ed6ccab
[[File:ParaFi_Technologies_NS_LLC_Compliance_Assessment.pdf|center|thumb|Compliance Assessment]]

File:ParaFi Technologies NS LLC Compliance Assessment.pdf

2025-07-10T18:46:41Z

Alexander.ufimtsev: ParaFi Technologies NS LLC Compliance Assessment / Certificate of Compliance

== Summary ==
ParaFi Technologies NS LLC Compliance Assessment / Certificate of Compliance

Node Provider Self Declarations

2025-07-08T13:10:50Z

Alexander.ufimtsev: adding icswitch

<blockquote>'''''NOTE: Please try to keep entries in this document alphabetically sorted, to reduce conflicts in edits.'''''

</blockquote>

[[0X52]]

[[100 Count Holdings, LLC]]

[[43rd Big Idea Films, LLC]]

[[87m Neuron, LLC]]

[[ACCUSET SOLUTIONS]]

[[Arceau NP LLC]]

[[Aitubi AG]]

[[Aksinia Stavskaya]]

[[Altimist Ltd]]

[[ALLUSION BV]]

[[User:Alpha.agentic|ANTHONY ISAAKIDIS]]

[[ANYPOINT PTY LTD]]

[[AVRVM AG]]

[[Artem Horodyskyi|ARTEM HORODYSKIY]]

[[Bianca-Martina Rohner]]

[[Bigger Capital|Bigger Capital Pty Ltd]]

[[Bitapp]]

[[Bitmoon]]

[[Blockchain Development Labs Inc]]

[[BlockFinance LLC]]

[[Blocktech Ventures LLC]]

[[BLP22, LLC]]

[[Blueant LLC]]

[[Bohatyrov Volodymyr]]

[[Buldakova Rehina]]

[[CarbonTwelve]]

[[CocoMango LLC]]

[[Conic Ventures]]

[[Coplus Limited]]

[[Decentralized Entities Foundation]]

[[DENODE|DeNoDe]]

[[DFINITY Stiftung]]

[[DragginCorp SARL]]

[[Eastman_Ventures_Pty_Ltd|Eastan_Ventures_Pty_Ltd]]

[[Exaion]]

[[Extragone]]

[[User:FenexLLC|FenexLLC]]

[[Ferndale International]]

[[Fractal Labs, LLC]]

[[Geeta Kalwani]]

[[GeoNodes LLC]]

[[George Bassadone]]

[[Geodd Pvt Ltd]]

[[Giant Leaf, LLC]]

[[User:James Wang|HashQuark]]

[[HoneyComb Capital]]

[[Iancu-Aurel|Iancu Aurel]]

[[Icaria_Systems_Pty_Ltd|Icaria_Systes_Pty_Ltd]]

[[Icswitch]]

[[Illusions in Art Ltd]]

[[InfoObjects Inc]]

[[Ivanov Oleksandr]]

[[Karel Frank]]

[[Katerina Karapuz]]

[[Kontrapunt (Pty) Ltd]]

[[Krishna Enterprises]]

[[Krzysztof Żelazko]]

[[Louise Velayo]]

[[Ludens LLC]]

[[Lukas Helebrandt]]

[[Marvelous Web3]]

[[Maksym Ishchenko]]

[[MB Patrankos šūvis]]

[[:File:NODE-PROVIDER-SELF.pdf|ML SOLUTIONS LTD]]

[[ML_MIST]]

[[Michael_and_Dominik_Peterer]]

[[MI Servers]]

[[Mariano Stoll]]

[[Neptune Partners]]

[[NODAL CAPITAL]]

[[NODAO]]

[[Nova_LCC]]

[[NoviSystems|NoviSystems, LLC]]

[[Nataliia Nykyforak]]

[[Natalia Kulesha]]

[[Nikola Nikov]]

[[OneSixtyTwo Digital Capital]]

[[User:Soekawat|Origin Game]]

[[ParaFi Technologies NS LLC]]

[[Paul Creasey]]

[[User:Protocol16|Protocol16 (Philip Hur)]]

[[PindarTechnologyLimited]]

[[User:Powermetacorp|Power Meta Corporation]]

[[Privoxy Solutions, LLC.]]

[[Quantum Node Ltd.]]

[[Reist Telecom AG]]

[[Rivonia Holdings, LLC]]

[[Rivram Inc]]

[[Stamper Co., Ltd.]]

[[Serenity lotus limited]]

[[Starbase]]

[[Sygnum]]

[[Technical University of Munich]]

[[Tenderloin Ventures AG|Tenderloin Ventures AG (Tomahawk.vc)]]

[[Timur Rakhimzhan]]

[[Uvaca Labs LLC]]

[[VirtualHiveLtd|Virtual Hive Ltd]]

[[Vladyslav Popov]]

[[Wolkboer (Pty) Ltd]]

[[WMA Investments Limited]]

[[Yannick Endrion]]

[[Zaboo d.o.o.]]

[[Zarety LLC]]

[[Zondax AG]]

[[User:Web3game|Web3game]]

[[User:Zenithcode|Zenith Code LLC]]

[https://wiki.internetcomputer.org/wiki/User:ZTLC_PTE_Ltd ZTLC_PTE_Ltd]

<references />

ML MIST

2025-06-02T15:13:34Z

Alexander.ufimtsev: added placeholder

placeholder for ML MIST provider page

Node Provider Self Declarations

2025-06-02T15:12:56Z

Alexander.ufimtsev: added ml mist

<blockquote>'''''NOTE: Please try to keep entries in this document alphabetically sorted, to reduce conflicts in edits.'''''

</blockquote>

[[0X52]]

[[100 Count Holdings, LLC]]

[[43rd Big Idea Films, LLC]]

[[87m Neuron, LLC]]

[[ACCUSET SOLUTIONS]]

[[Arceau NP LLC]]

[[Aitubi AG]]

[[Aksinia Stavskaya]]

[[Altimist Ltd]]

[[ALLUSION BV]]

[[User:Alpha.agentic|ANTHONY ISAAKIDIS]]

[[ANYPOINT PTY LTD]]

[[AVRVM AG]]

[[Artem Horodyskyi|ARTEM HORODYSKIY]]

[[Bianca-Martina Rohner]]

[[Bigger Capital|Bigger Capital Pty Ltd]]

[[Bitapp]]

[[Bitmoon]]

[[Blockchain Development Labs Inc]]

[[BlockFinance LLC]]

[[Blocktech Ventures LLC]]

[[BLP22, LLC]]

[[Blueant LLC]]

[[Bohatyrov Volodymyr]]

[[Buldakova Rehina]]

[[CarbonTwelve]]

[[CocoMango LLC]]

[[Conic Ventures]]

[[Coplus Limited]]

[[Decentralized Entities Foundation]]

[[DENODE|DeNoDe]]

[[DFINITY Stiftung]]

[[DragginCorp SARL]]

[[Eastman_Ventures_Pty_Ltd|Eastan_Ventures_Pty_Ltd]]

[[Exaion]]

[[Extragone]]

[[User:FenexLLC|FenexLLC]]

[[Ferndale International]]

[[Fractal Labs, LLC]]

[[Geeta Kalwani]]

[[GeoNodes LLC]]

[[George Bassadone]]

[[Geodd Pvt Ltd]]

[[Giant Leaf, LLC]]

[[User:James Wang|HashQuark]]

[[HoneyComb Capital]]

[[Iancu-Aurel|Iancu Aurel]]

[[Icaria_Systems_Pty_Ltd|Icaria_Systes_Pty_Ltd]]

[[Illusions in Art Ltd]]

[[InfoObjects Inc]]

[[Ivanov Oleksandr]]

[[Karel Frank]]

[[Katerina Karapuz]]

[[Kontrapunt (Pty) Ltd]]

[[Krishna Enterprises]]

[[Krzysztof Żelazko]]

[[Louise Velayo]]

[[Ludens LLC]]

[[Lukas Helebrandt]]

[[Marvelous Web3]]

[[Maksym Ishchenko]]

[[MB Patrankos šūvis]]

[[:File:NODE-PROVIDER-SELF.pdf|ML SOLUTIONS LTD]]

[[ML_MIST]]

[[Michael_and_Dominik_Peterer]]

[[MI Servers]]

[[Mariano Stoll]]

[[Neptune Partners]]

[[NODAL CAPITAL]]

[[NODAO]]

[[Nova_LCC]]

[[NoviSystems|NoviSystems, LLC]]

[[Nataliia Nykyforak]]

[[Natalia Kulesha]]

[[Nikola Nikov]]

[[OneSixtyTwo Digital Capital]]

[[User:Soekawat|Origin Game]]

[[Paul Creasey]]

[[User:Protocol16|Protocol16 (Philip Hur)]]

[[PindarTechnologyLimited]]

[[User:Powermetacorp|Power Meta Corporation]]

[[Privoxy Solutions, LLC.]]

[[Quantum Node Ltd.]]

[[Reist Telecom AG]]

[[Rivonia Holdings, LLC]]

[[Rivram Inc]]

[[Stamper Co., Ltd.]]

[[Serenity lotus limited]]

[[Starbase]]

[[Sygnum]]

[[Technical University of Munich]]

[[Tenderloin Ventures AG|Tenderloin Ventures AG (Tomahawk.vc)]]

[[Timur Rakhimzhan]]

[[Uvaca Labs LLC]]

[[VirtualHiveLtd|Virtual Hive Ltd]]

[[Vladyslav Popov]]

[[Wolkboer (Pty) Ltd]]

[[WMA Investments Limited]]

[[Yannick Endrion]]

[[Zaboo d.o.o.]]

[[Zarety LLC]]

[[Zondax AG]]

[[User:Web3game|Web3game]]

[[User:Zenithcode|Zenith Code LLC]]

[https://wiki.internetcomputer.org/wiki/User:ZTLC_PTE_Ltd ZTLC_PTE_Ltd]

<references />

Zarety LLC

2025-04-03T09:49:46Z

Alexander.ufimtsev:

[[:File:Proof-of-identity.pdf|File:Proof-of-identity.pdf]]:4f9983a12136922e80784bfa3781a7795d3f6dda14401c653b63e5818a87b36b
[[File:Proof-of-identity.pdf|thumb|alt=|none]]
 

[[:File:Self-declaration-zarety-llc.pdf|File:Self-declaration-zarety-llc.pdf]]:31b5d8004094e572dd6b97e0c08884d2bf45210eb595b54bec63772ae67f38d7
[[File:Self-declaration-zarety-llc.pdf|thumb]]
 

[[File:Candidate machine validation with and without zarety.pdf|thumb|Candidate machine validation with and without Zarety LLC]]
 

[[:File:Complete with Docusign Zarety DFINITY node.pdf|Machine Handover Statement]]:4be7d546c58a1372ba845759df01208af573b6b484b45a600f756930d5a67040

Blueant LLC

2025-04-03T09:45:16Z

Alexander.ufimtsev: added link to enzo's handover copy

<syntaxhighlight lang="bash">
$ wget https://mywikis-wiki-media.s3.us-central-1.wasabisys.com/internetcomputer/Proof-of-identity-blue-ant.pdf 2>/dev/null && sha256sum Proof-of-identity-blue-ant.pdf
9bbcedcf3502b1940bb0fcd1dd3d1d91cd1408149a5791764aea2ca50c44ddee Proof-of-identity-blue-ant.pdf

$ wget https://mywikis-wiki-media.s3.us-central-1.wasabisys.com/internetcomputer/Self-declaration-blue-ant.pdf 2>/dev/null && sha256sum Self-declaration-blue-ant.pdf
d17d67f24487ee09485ec94af646c9a7dc39f063e6ccffdbc8ca10324d26bbfc Self-declaration-blue-ant.pdf

$ wget https://mywikis-wiki-media.s3.us-central-1.wasabisys.com/internetcomputer/Candidate_machine_validation_blue_ant.pdf 2>/dev/null && sha256sum Candidate_machine_validation_blue_ant.pdf
2191051518408b9247897bee4b108c6340239b7a9623e17260c6836b41df80d5 Candidate_machine_validation_blue_ant.pdf

$ wget https://mywikis-wiki-media.s3.us-central-1.wasabisys.com/internetcomputer/Enzo%27s_copy_of_2024.12_-_DFINITY_node_hand_over_statement_%281%29.pdf 2>/dev/null && sha256sum "Enzo's_copy_of_2024.12_-_DFINITY_node_hand_over_statement_(1).pdf"
e60d4ee43be50b00edf7fa83cb1283fc9d1c4e85d6387fa568256ff692c2025c Enzo's_copy_of_2024.12_-_DFINITY_node_hand_over_statement_(1).pdf

</syntaxhighlight>[[File:Proof-of-identity-blue-ant.pdf|thumb|proof of identity]]
[[File:Self-declaration-blue-ant.pdf|thumb|self declaration]]
[[File:Candidate machine validation blue ant.pdf|thumb|candidate machine validation]]
[[File:Enzo's_copy_of_2024.12_-_DFINITY_node_hand_over_statement_(1).pdf|thumb|handover document]]

Node Provider Remuneration

2025-04-01T13:49:24Z

Alexander.ufimtsev: added the remuneration for Gen-1.1 NPs that chose to relocate their nodes to a non-EU state

== Rewards ==

Node Providers receive rewards (remuneration) for owning node machines that run in the Internet Computer network. Node Provider rewards are set by the NNS DAO, with changes only possible through NNS proposals adopted by the Internet Computer community.

The '''NNS mints Node Provider Rewards every ~2,629,700 seconds''', which is 1/12th of a year. It uses the 30-day moving average price of ICP in Special Drawing Rights (XDR), an international reserve asset created by the International Monetary Fund (IMF). This value is tracked on the [https://dashboard.internetcomputer.org Internet Computer Dashboard] on the "Conversion Rate" chart. (See [[How the 30-Day Moving Average Is Calculated]].) Rewards for the previous month are converted to ICP and transferred to account of the principal registered by the Node Provider in the [[Node Provider Onboarding|Node Onboarding]] process.

These are the current rewards, but reward changes can be proposed to the NNS and adopted by voters at any time.

== Remuneration models ==
The NNS distributes rewards depending on:

* The generation of the node hardware (gen-1/gen-2)
* Geographic location
* The total number of nodes a provider operates 
Different hardware generations lead to varying capital expenditures (CAPEX) and operating expenditures (OPEX), which can also fluctuate based on geographic location. Furthermore, certain locations are deemed more valuable for enhancing network decentralization, resulting in higher rewards for Node Providers in those areas.

Two [[Node Provider Machine Hardware Guide|node machine hardware generations]] are currently recognized: gen-1 and gen-2. Each hardware generation is associated with its own remuneration model. Some cost estimates are provided for the current 2nd generation, but keep in mind that actual hardware and operational expenses may differ.
{| class="wikitable"
|Hardware Type
|Remuneration Model
|-
|Gen-1
|Gen-1 type-0
|-
|Gen-1 + storage upgrade
|Gen-1 type-1
|-
|Gen-2
|V2: Gen-2 remuneration
V2.2: Gen-2 remuneration update
|-
|Gen-3
|V3: Gen-3 remuneration
|}In the future, a remuneration model will be proposed that includes both automated incentives, rewards, and penalties.

== Initial Gen-1 Remuneration Model ==

Nodes purchased prior to Genesis were considered Gen-1 nodes. All nodes started out as type-0 with the following calculations:

{| class="wikitable"
|'''TYPE-0'''
|Reward per month (in XDR)
|-
|USA
|873
|-
|US - FL/GA/CA
|1087
|-
|EU
|1087
|-
|Asia
|1212
|}

After the first nodes were up and running, the decision was made to increase the storage capacity of all nodes to support larger subnet states. Thus, a type-1 table was created to reward for the additional costs that the extra storage incurred. Rewards were also broken down further by country. These type-1 values include both the original equipment costs incurred by Gen-1 Node Providers, their operating costs, and the varied costs that Node Providers incurred to purchase the additional storage, ship it to their data centers, and get it installed in each server.

{| class="wikitable"
|'''TYPE-1'''
|Total rewards per node (in XDR)
|-
|US - FL/GA/CA
|1600
|-
|US - other
|1499
|-
|Canada
|1624
|-
|Slovenia
|1720
|-
|Switzerland
|1696
|-
|EU - other
|1584
|-
|Singapore
|1842
|-
|Japan
|1773
|}
An [[Proposed Gen-1 Remuneration Model|Interim Gen-1 Remuneration Model]] was initially approved for when the original 48-month agreements are completed, but it has since been replaced with the Gen-1.1 Remuneration Model.

== Gen-1.1 Remuneration Model ==
This section presents the remuneration model for Gen-1 servers which are continuing to run as IC nodes beyond their initial 48 months.

With the adoption of [https://dashboard.internetcomputer.org/proposal/132553 motion proposal #132553] as discussed in [https://forum.dfinity.org/t/proposal-update-interim-gen-1-node-provider-remuneration-after-48-months/35001 this forum post], a new post-48-month remuneration model was adopted for Gen1 node machines. This remuneration model implements fixed and lower rewards for Gen1 node machines after 48 months of operation, with a maximum of 42 nodes per node provider. The expected length of time that these rewards will remain in force is 24 months.

With the adoption of [https://dashboard.internetcomputer.org/proposal/135253 motion proposal 135253] as discussed in [https://forum.dfinity.org/t/proposal-update-interim-gen-1-node-provider-remuneration-after-48-months/35001/208 this forum post], an extra 10% of the highest Gen-1.1 rewards was given to the node providers that chose to relocate their nodes to a non-EU member state.
{| class="wikitable"
!TYPE-1.1
!Reward per node per month (in XDR)
|-
|US - FL/GA/CA
|1072
|-
|US - other
|1004
|-
|Canada
|1088
|-
|Slovenia
|1152
|-
|Switzerland
|1136
|-
|EU - other
|1061
|-
|Singapore
|1234
|-
|Japan
|1188
|-
|Non-EU (relocation)
|1357
|}
As part of that approved motion proposal:

* Excess nodes may be sold to another NP while keeping the nodes in the same data center.
* Excess nodes may be sold to an optimal NP with the nodes moved to a new country and data center.
* No node provider can have more than 42 nodes.
The steps that the new NP must follow are outlined here: [[Steps for Gen-1 Node onboarding after 48 months]]

== Gen-2 Remuneration Model ==

This section presents the remuneration model for 2nd generation Node Providers.

Based on the feedback from Node Providers and the community, discussed in this [https://forum.dfinity.org/t/the-state-and-direction-of-decentralization-nodes-on-the-internet-computer/9170/128?u=svenf forum post], the Gen2 remuneration model is based on the following principles:
* Higher rewards for the first nodes of a new Node Provider in order to attract more Node Providers in an effort to improve ownership decentralization.
* More refined rewards for nodes in new geographies, like South America, Africa, Asia and Australia, to stimulate further geographical decentralization.

The node reward model is parametrized by:
*'''Geography multiplier (mult)''': This multiplier will be lower, namely 2, for regions with many nodes (e.g. Europe and North America), and higher, namely 3, for regions where there are currently limited nodes present (such as Africa and South America)
*'''Reduction coefficient (r)''': The node reward of the n-th node of a Node Provider is multiplied by r ^ (n-1). The reduction coefficient r is dependent on the geography of the Node Provider. As a result, the first nodes of a Node Provider get attractive rewards, but it is increasingly less attractive to add additional nodes.

The rewards are furthermore dependent on estimated capital and operational expenses that vary based on geographies. A table with the concrete numbers follows below.

In summary, for a geography '''g''', let
* mult('''g''') be the geography multiplier
* cost('''g''') be the total costs over 4 years for acquiring and maintaining a gen 2 node in g in XDR
* r('''np''', '''g''') be the reduction coefficient

The monthly reward for the n-th node of a Node Provider ('''np''') in geography '''g''' are defined as follows:
reward('''g, n''') = cost('''g''') * mult('''g''') * r('''np, g''') ^ (n-1) / (4 * 12)
If a Node Provider has nodes in more than one type or geography but within the same country, the NNS knows that they are in the same country and counts the combined total of nodes, each according to their own type and geography.

The total costs over 4 years are multiplied by the geography multiplier, multiplied by the reduction coefficient, and divided by 4 years times 12 months. As a result, rewards for nodes in new geographies and for Node Providers with few nodes are higher. Thereby, a geographical and ownership decentralization is incentivized. The following table shows the geography-dependent values and the monthly reward for the first node onboarded.

{| class="wikitable"
|Geography
|Total cost over 4 years
|Multiplier
|Monthly reward for 1st node (in XDR)
|Reduction coefficient r
|-
|USA
|31034
|2
|1294
|0.7
|-
|US - FL/GA/CA
|37031
|2
|1542
|0.7
|-
|EU
|36996
|2
|1542
|0.95
|-
|Asia Singapore/Japan
|40508
|2
|1688
|0.7
|-
|Asia non Singapore
|40508
|3
|2532
|0.98
|-
|South Africa
|43986
|3
|2748
|0.98
|}

Note that the reduction coefficient r('''np, g''') is applied per (Node Provider + Country) pair. This means if there is more than one Node Provider in the same country, r('''np, g''') is calculated separately for them. For instance: Node Provider A has 10 nodes in France (EU); reduction coefficient for the 1st node of Node Provider A is 0.95, and for the 10th node is 0.95 ^ 9 = 0.63. If there is Node Provider B with 10 nodes in France (EU) as well, they will get the same rewards as Node Provider A.

As an example, the below table shows the calculation of the rewards of the 1st to the 10th node for a Node Provider in South Africa.
reward('''south africa, n''')
= cost('''south africa''') * mult('''south africa''') * r('''south africa''') ^ ('''n'''-1) / (4 * 12)
= ( 21’455 + 22’531) * 3 * 0.98 ^ ('''n'''-1) / (4 * 12)
= 2748 * 0.98 ^ ('''n'''-1)
{| class="wikitable"
|N-th node
|Multiplier (rounded)
|Monthly remuneration (rounded, in XDR)
|-
|Node 1
|0.98 ^ (1-1) =1
|2748
|-
|Node 2
|0.98 ^ (2-1) =0.98
|2693
|-
|Node 3
|0.98 ^ (3-1) =0.96040
|2639
|-
|Node 4
|0.98 ^ (4-1) =0.941192
|2586
|-
|Node 5
|0.98 ^ (5-1) =0.92236816
|2534
|-
|Node 6
|0.98 ^ (6-1) =0.9039207968
|2483
|-
|Node 7
|0.98 ^ (7-1) =0.885842309
|2434
|-
|Node 8
|0.98 ^ (8-1) = 0.8681255332
|2385
|-
|Node 9
|0.98 ^ (9-1) =0.8507630226
|2337
|-
|Node 10
|0.98 ^ (10-1) =0.8337477621
|2291
|}

[[File:Profit margin for each additional node graph for remuneration V2.png|1000px]]

The above figure shows the additional cash flow (investments minus costs) a Node Provider receives for adding an additional node for three regions (South Africa, Europe and USA) that can be calculated based on the Version 2 remuneration model. Note that the calculation does not take into account the time value of the cash flows (i.e. discounted value), but purely the cash flows or rewards and expenses.

What is visible from this graph is that adding additional nodes only generates additional cash flow for a specific number of nodes, in a specific region. For example, in Europe adding up to approximately 15 nodes will generate additional cash flow, whereas for the US region, this is only 2 nodes.

Potential new Node Providers can make a full calculation themselves of the Internal Rate of Return, Payback period and cash flow based on their actual CAPEX and OPEX costs. Of course, these actual CAPEX and OPEX costs may differ from the costs on which the remuneration is based, depending on the specific contracts the new Node Provider has been able to negotiate with hardware vendors and DC operators.

=== Version 2.1 Remuneration Model ===
The Version 2.1 remuneration model replaces the Version 2 remuneration for 2nd generation Node Providers. It includes the following changes compared to Version 2, based on discussion in this [https://forum.dfinity.org/t/the-state-and-direction-of-decentralization-nodes-on-the-internet-computer/9170/192 forum thread]:

* No entry for the region Asia will be used anymore. For the Asia region, specific country entries will be used.
* Specific entries for Hong Kong and India will be added to the remuneration table.
* The multiplier is set to a value of 2 for all countries. In future, this might be updated through a new NNS proposal if the community determines that the risk premium for projects should be different for different countries (for example, if the risk of running in node in one specific country is higher than the risk of running in node in another country, this might validate a different multiplier).
* A limit is set to the number of nodes in new countries for which the remuneration applies. Once this is reached, the reduction coefficient for additional nodes will be adjusted to allow adding only one or two nodes for this country, similar to existing countries like the U.S. and Switzerland. Currently, the limit of number of nodes per country is set to 50 nodes, which allows NP’s to add a node in that specific country to every available subnet and have a small set of additional nodes in case nodes are unhealthy or require maintenance.
* Version 2 was relevant for a limited time period in 2023. Version 2.1 became the current model as of May 2023.

The following table shows the geography-dependent values and the monthly reward for the first node onboarded based on the Remuneration Version 2.1.

With this latest update, there are sufficient node machines for running the current load of canisters on every subnet, and for the decentralisation of the subnets measured in Nakamoto coefficients; no new country entries will be added. Work is in progress on an IC Topology Roadmap for the next half year and the next year, with the objective to assess how many node machines and where new node machines are required for further growth and decentralisation of the IC network. Based on that it will be discussed on the IC forum what changes to make to the Node Provider remuneration table and subsequent proposals will be submitted to the NNS for the community to vote upon.

{| class="wikitable"
|Geography
|Total costs over 4 years
|Multiplier
|Monthly reward for 1st node (in XDR)
|Reduction coefficient r
|-
|US
|31034
|2
|1294
|0.7
|-
|US California
|37031
|2
|1543
|0.7
|-
|Canada
|37031
|2
|1543
|0.7
|-
|Germany
|36996
|2
|1542
|0.7
|-
|Switzerland
|36996
|2
|1542
|0.7
|-
|France
|36996
|2
|1542
|0.7
|-
|Belgium
|36996
|2
|1542
|0.7
|-
|Slovenia
|36996
|2
|1542
|0.7
|-
|Europe (other than above)
|36996
|2
|1542
|0.95
|-
|Israel
|49500
|2
|2063
|0.95
|-
|Japan
|40508
|2
|1688
|0.7
|-
|Singapore
|40508
|2
|1688
|0.7
|-
|Hong Kong
|46141
|2
|1922
|0.95
|-
|India
|50377
|2
|2100
|0.95
|-
|South Korea
|51774
|2
|2158
|0.95
|-
|Sri Lanka
|52800
|2
|2200
|0.95
|-
|Georgia
|57455
|2
|2394
|0.95
|-
|South Africa
|55455
|2
|2310
|0.95
|-
|Australia
|47000
|2
|1958
|0.95
|-
|New Zealand
|47000
|2
|1958
|0.95
|-
|Panama
|51774
|2
|2158
|0.95
|-
|Costa Rica
|51774
|2
|2158
|0.95
|-
|Colombia
|57455
|2
|2394
|0.95
|-
|Argentina (proposed)
|57455
|2
|2394
|0.95
|}

== Reward calculator ==
For your convenience, we prepared the following [https://www.calconic.com/calculator-widgets/ic-node-provider-rewards/659d42a6d96fa70029e56629?layouts=true calculator for the node rewards]

== Trustworthy Node Metrics ==
In February 2024, Trustworthy Node Metrics were introduced on the IC, in an attempt to provide greater visibility into node performance, stability, and reliability. These metrics could potentially be used to influence node rewards in the future.

There is a forum post here https://forum.dfinity.org/t/trustworthy-node-metrics-for-useful-work/22989, then

Blog post on Medium here: https://medium.com/dfinity/dont-trust-verify-new-node-metrics-on-the-internet-computer-367cc154a572

And technical documentation and instructions here: https://dfinity.github.io/dre/trustworthy-metrics/trustworthy-metrics.html

Node Provider Self Declarations

2025-03-13T15:33:42Z

Alexander.ufimtsev: correcting link

<blockquote>'''''NOTE: Please try to keep entries in this document alphabetically sorted, to reduce conflicts in edits.'''''

</blockquote>

[[0X52]]

[[100 Count Holdings, LLC]]

[[43rd Big Idea Films, LLC]]

[[87m Neuron, LLC]]

[[ACCUSET SOLUTIONS]]

[[Arceau NP LLC]]

[[Aitubi AG]]

[[Aksinia Stavskaya]]

[[Altimist Ltd]]

[[ALLUSION BV]]

[[ANYPOINT PTY LTD]]

[[AVRVM AG]]

[[Artem Horodyskyi|ARTEM HORODYSKIY]]

[[Bianca-Martina Rohner]]

[[Bigger Capital|Bigger Capital Pty Ltd]]

[[Bitapp]]

[[Bitmoon]]

[[Blockchain Development Labs Inc]]

[[Blockchain Literacy Foundation]]

[[BlockFinance LLC]]

[[Blocktech Ventures LLC]]

[[BLP22, LLC]]

[[Blueant LLC]]

[[Bohatyrov Volodymyr]]

[[Buldakova Rehina]]

[[CarbonTwelve]]

[[CocoMango LLC]]

[[Conic Ventures]]

[[Coplus Limited]]

[[Decentralized Entities Foundation]]

[[DENODE|DeNoDe]]

[[DFINITY Stiftung]]

[[Eastman_Ventures_Pty_Ltd|Eastan_Ventures_Pty_Ltd]]

[[Exaion]]

[[Extragone]]

[[User:FenexLLC|FenexLLC]]

[[Ferndale International]]

[[Fractal Labs, LLC]]

[[Geeta Kalwani]]

[[GeoNodes LLC]]

[[George Bassadone]]

[[Geodd Pvt Ltd]]

[[Giant Leaf, LLC]]

[[User:James Wang|HashQuark]]

[[HoneyComb Capital|HoneyCob Capital]]

[[Iancu-Aurel|Iancu Aurel]]

[[Icaria_Systems_Pty_Ltd|Icaria_Systes_Pty_Ltd]]

[[Illusions in Art Ltd]]

[[InfoObjects Inc]]

[[Ivanov Oleksandr]]

[[Karel Frank]]

[[Katerina Karapuz]]

[[Kontrapunt (Pty) Ltd]]

[[Krishna Enterprises]]

[[Krzysztof Żelazko]]

[[Louise Velayo]]

[[Ludens LLC]]

[[Lukas Helebrandt]]

[[Marvelous Web3]]

[[Maksym Ishchenko]]

[[:File:NODE-PROVIDER-SELF.pdf|ML SOLUTIONS LTD]]

[[Michael_and_Dominik_Peterer]]

[[MI Servers]]

[[Mariano Stoll]]

[[Neptune Partners]]

[[NODAL CAPITAL]]

[[NODAO]]

[[Nova_LCC]]

[[NoviSystems|NoviSystems, LLC]]

[[Nataliia Nykyforak]]

[[Natalia Kulesha]]

[[Nikola Nikov]]

[[OneSixtyTwo Digital Capital]]

[[User:Soekawat|Origin Game]]

[[Paul Creasey]]

[[User:Protocol16|Protocol16 (Philip Hur)]]

[[PindarTechnologyLimited]]

[[User:Powermetacorp|Power Meta Corporation]]

[[Privoxy Solutions, LLC.]]

[[Quantum Node Ltd.]]

[[Reist Telecom AG]]

[[Rivonia Holdings, LLC]]

[[Rivram Inc]]

[[Stamper Co., Ltd.]]

[[Serenity lotus limited]]

[[Starbase]]

[[Sygnum]]

[[Technical University of Munich]]

[[Tenderloin Ventures AG|Tenderloin Ventures AG (Tomahawk.vc)]]

[[Timur Rakhimzhan]]

[[Uvaca Labs LLC]]

[[VirtualHiveLtd|Virtual Hive Ltd]]

[[Vladyslav Popov]]

[[Wolkboer (Pty) Ltd]]

[[WMA Investments Limited]]

[[Yannick Endrion]]

[[Zaboo d.o.o.]]

[[Zarety LLC]]

[[Zondax AG]]

[[User:Web3game|Web3game]]

[[User:Zenithcode|Zenith Code LLC]]

[https://wiki.internetcomputer.org/wiki/User:ZTLC_PTE_Ltd ZTLC_PTE_Ltd]

<references />

Aspire Properties

2025-03-10T16:31:26Z

Alexander.ufimtsev: correcting links due to filename clash

[[File:Aspire Self-declaration.pdf|alt=|thumb|1219x1219px]]

==Identity Proof==

Company can be verified at:

[https://arc-sos.state.al.us/cgi/corpdetail.mbr/detail?corp=000027040&page=name&file=&type=ALL&status=ALL&place=ALL&city= Alabama Secretary of State Link for Aspire Properties]

File:Aspire Self-declaration.pdf

2025-03-10T16:30:39Z

Alexander.ufimtsev:

aspire

DFINITY Stiftung

2025-02-26T11:50:32Z

Alexander.ufimtsev: spelling correction

====Self-declaration:====
Also see [[DFINITY Foundation]].
[[File:CHE189770146-19.12.2024-Merkmale DFINITY Stiftung.pdf|thumb|alt=|none]]
[[File:DFINITY Self-declaration (1) (1).pdf|thumb|alt=|none]]

====Swiss registration.====
[[File:DFINITY Stiftung Central Business Index listing.pdf|thumb|alt=|none]]

==== Handover document to Zarety LLC for 42 of the nodes in BO1 and AT1 that we sold to Zarety. ====
[[File:Complete with Docusign Zarety DFINITY node.pdf|none|thumb]]

==== Handover document to Blue Ant LLC for the 42 nodes in AT1 and MR1 that we sold to Blue Ant ====
[[File:Enzo's copy of 2024.12 - DFINITY node hand over statement (1).pdf|none|thumb]]