Improvements to Node Provider Remuneration


The NNS is designed to maximize node decentralization. As highlighted in the developer forum post “The State and Direction of Decentralization & Nodes on the Internet Computer”, there have been various gaps between design and implementation that are being addressed in the node decentralization roadmap.

Over the next few days, there will be NNS proposals that will close one of those gaps: node provider remuneration. These NNS proposals are to upgrade the NNS so current node providers’ remuneration is much more transparent, automated, and standardized as NNS was originally designed.

This is an important step towards removing human factors in the NNS towards the goal of making the Internet Computer the most decentralized blockchain in the world. It is important to be intellectually honest about the shortcomings between design and implementation (without any delusions) so we can fulfill the IC’s potential.


As of January 28, 2022, there are

Node Provider Remuneration: The Design Intent

The NNS is designed so node providers are remunerated in ICP for the well-behaving nodes they have in the network. This amount of ICP they receive is pegged to XDR. The NNS and the open market set heterogeneous but transparent standards for what node providers are paid.

The long-term design goal is to create a healthy network that incentivizes node providers to have necessary hardware available and ready in data centers. The constraint is to make sure that node providers would not be paid so much that it creates unnecessary ICP minting (inflation).

Closing the gap between design and implementation: The NNS Proposals

The current state of the world is a combination of the following:

  1. NNS proposals are submitted to pay node providers (the NNS mints and pays node providers). Community votes on these. This is good and as intended.
  2. NNS proposals are submitted on the node providers’ behalf. This is not what is intended and instead, these proposals will be automated to remove human components.
  3. The node providers are paid varying rates (the biggest reason is geography). The variance of rates is ok by itself, but the intent is that there would be set and transparent standards (e.g. “Nodes in Germany” vs “Nodes in Chile”) that currently do not exist. These new NNS proposals will create a starting point for transparent & standardized rates for node providers all over the world. More areas will be added, for example.

Table of Standards

Using the historical information from the last 8 months since network Genesis in May 2021, the following standards are being proposed in the NNS proposals:

Region node category XDR reward per month per node
US 0 873.36375
US/FL 0 1087.24875
US/GA 0 1087.24875
US/CA 0 1087.24875
CA (Canada) 0 891.1875
EU (European Union) 0 1087.24875
AP (Asia Pacific) 0 1212.015
US (United States) 2 1604.1375
CA (Canada) 2 1782.375
EU (European Union) 2 2174.4975
AP (Asia/Pacific) 2 2424.03

Please note: This table is for existing (Generation 1) node providers. For the subsequent generation of node providers, the payout rates may change.


The relevant NNS Proposals will be added to this forum thread once live.

What we are asking the community

We are asking the IC community to review these NNS proposals, ask questions, vote ACCEPT or REJECT.


Relevant Questions

1. Why did it take so long to automate and standardize NNS proposals for node provider remuneration?

The intent was to standardize and automate earlier. The simple reason for the delay is that network stability and decentralizing other parts of the NNS jumped the priority queue once the network became real and live.

As recognized in “The State and Direction of Decentralization & Nodes on the Internet Computer”, there are gaps between the design and implementation and they are being tackled systematically.

2. How was this table of payout rates derived?

The table was derived by looking at the average costs to obtain equipment and run Internet Computer nodes across different regions. The geographical distribution of the nodes is extremely critical to the decentralization goal of IC.

3. Can I vote “REJECT” on these changes?

Yes, one most certainly can. That is the purpose of algorithmic on-chain governance.

4. Where is the documentation about how I can add myself as a node provider?

As stated in “The State and Direction of Decentralization & Nodes on the Internet Computer”, there have been many node providers onboarded, but the experience was not smooth (requiring lots of fixes, patches, and technical know-how). Rather than invest documentation and patches into a system that was unsatisfactory, the team decided to bridge all the gaps between design and implementation. The current plan is to clean up all the technical debt so node providers can add themselves to the network in a frictionless way. The team is 100% focused on improving this so it matches the original goal. As this completes, there will be updated documentation.

5. What is the node decentralization roadmap?

Q4 2021

  • (A) Reproducible builds: Reproducible replica software builds are planned to be available to the public in November 2021. This initiative has its own separate communication because it touches many parts.

Q1 2022

  • (B) Autonomous node deployment and operation: In early 2022, a new deployment process will be introduced based on the reproducible builds (A). Over the subsequent weeks, existing node providers will be asked to update their deployments using the new process.
  • (C) Independent node provider registration: In early 2022, future node providers will be able to register via the NNS frontend dapp. In parallel with the onboarding of the currently backlogged nodes, a limited number of new DCs and nodes will be added to the network using the new deployment method (B).
  • In order to get started with autonomous node deployments (B) before the NNS-driven DC allocation is in place (D), a small set of new node providers will be onboarded using (C).

Q2/Q3 2022

  • (D) NNS-driven DC allocation: The NNS-controlled DC allocation mechanism will be introduced and control all future node additions. With this step and a new node hardware, see (F), an accelerated network growth is unleashed.
  • (E) Availability of node hardware: Different hardware options are currently being investigated. This blocker might be overcome in two steps
    1. Minor extensions to the Genesis hardware setup to overcome current availability limitations.
    2. Larger extensions that incorporate additional hardware technologies such as SEV-SNP.

6. What are the current blockers for anyone to contribute nodes to the IC?

To see updates you can follow the latest demo of milestones for the roadmap.

The following blockers must be addressed before the IC’s network growth can be further accelerated:

  • (A) Reproducible builds: The community, including node providers, shall be able to build the replica software in a deterministic manner. This enables the community to verify that IC update proposals indeed correspond to the source code version specified in the NNS proposal.
    • Completed Q4 2021.
  • (B) Autonomous node deployment and operation: Empower node providers to install and maintain nodes without any support from the ICA.
  • (C) Independent node provider registration: New node providers shall be able to register directly in the NNS frontend dapp. They will be able to submit a proposal to become a new node provider, without the support of the ICA.
    • In progress
  • (D) NNS-driven DC allocation: Node providers can participate in NNS-controlled mechanism to elect new data centers. This process shall incentivise the addition of new DCs that further decentralize the IC’s network. Furthermore, it balances inflationary and deflationary forces.
  • (E) Availability of node hardware: A new generation of ICA-specified node hardware is planned that shall guarantee global availability and provide a better choice between hardware providers. Furthermore, the next generation shall include the SEV-SNP technology to further improve the security of nodes.

The conversation leads for any questions are @Luis @samuelburri


Furthermore, the next generation shall include the SEV-SNP technology to further improve the security of nodes.

What is the plan to make the already onboarded nodes to support SEV-SNP? Is that possible or only nodes being newly added will support this?


The first three node types are running on AMD Rome. They already support SEV-ES. The next node types with AMD Milan will support SEV-SNP.