Proposal: Node Rewards, Replica Geolocation, Cycle-Tiers

Hello Dfinity Community,

This topic is to discuss an improvement in the way ICP handles nodes and node rewards. Currently, we allocate full rewards to nodes, irrespective of whether they are actively providing cycles to the network. While this approach was initially intended to foster network growth and address the absence of an alternative system, it presents certain challenges and hinders transparency in assessing network demand.

I believe we can solve this in a way that reduces latency in the network, gives Dev’s more control, and more fairly rewarding Nodes in expensive or cheaper areas.

Problem Statement:

  • All nodes receive 100% rewards, regardless of their actual contribution to the network.
  • This approach, though well-intentioned, obscures the true demand for network resources.
  • Fails to create a relation between network demand and node availability.
  • Causes confusion in the community, as seen in topics like Node Providers - Over Compensated & Under Used, with even talks about the Node Provider Inflation Spiral.
  • Canister Replicas are currently attributed to nodes at random, which gives devs no control over where their node replicas are hosted.
  • We can’t continue rewarding nodes that way indefinetly. The sooner we start talking about this, the better.

The Proposed Solution:
To successfully transition to a reward model based on cycles, we need to address several key aspects.

1. Rewards Based on Cycles:
Reward nodes based on the amount of cycles they contribute to the network, replacing the current flat fee system.

This should be relatively easy to implement since we are already tracking cycles. However, if this was implemented “as is”, it would cause an imbalance. Nodes that are underocupied would stop earning rewards, while other nodes might receive disproportionately high rewards.

2. Dynamic Node Allocation:
To ensure efficient resource utilization, we must enable canister replicas to be automatically relocated to nodes that are underutilized.

It also make sense to detect where most requests to a canister come from and, based on that, automatically move replicas to nodes closer to their target users.
For example: if most requests to a dApp come from New York, move one or more replicas closer to that location, to better serve those users.

This is crucial for reducing latency and enhancing the overall health of the network, especially for latency-sensitive applications such as streaming, exchanges, and gaming.

3. Prioritize the highest bidder:
The shift towards allocating nodes based on cycles and geolocation will lead to increased demand for nodes in high-density areas, while Nodes in remote areas may see less demand, causing potential imbalances.

To mitigate this, I propose a fee-based priority system, similar to how BTC prioritizes transactions from users willing to pay higher fees.

Allow developers to select their desired level of performance by choosing how much they are willing to pay for cycles (low, average, high). This empowers devs to optimize their applications for performance and cost. This flexibility means that latency-insensitive applications can naturally gravitate towards nodes in more cost-effective locations.

This would also naturaly inflate the price of Cycles during periods where there aren’t enough nodes, and have prices fall during periods of low cycle utilization.

4. Allow for Node Subsidies
The reality is that, at the moment, it still makes sense to subsidise nodes (pay out rewards even though there is no demand). If we paid out rewards based on cycles today, most nodes would abandon the network, and we might end with not enough nodes during the next crypto bull market.

This means that this system needs to allow Dfinity to pay out these Subsidies in transparent manner. For example: garantee Nodes a minimum payout.

It would be great if this was done in a transparent manner, so the community can see:

  • how much was paid out for real cycles
  • how much has been paid in subsidies

Why These Changes Matter:

  • Price fluctuation in cycles (like BTC transaction fee fluctuation) would incentive new nodes to be created only when the network needs it, while also slowing the rate of node creation when there aren’t dApps burning cycles.
  • Node location significantly impacts network latency and overall network performance.
  • A priority-based fee model incentivizes nodes in high-demand locations and optimizes resource allocation. Otherwise we might end up with too many nodes in cheaper remote locations like Alaska.
  • This change enhances transparency and aligns with Dfinity’s vision for a decentralized internet.
  • Competing with legacy cloud services requires embracing CDN-like capabilities. ICP’s goal is to replace legacy cloud services like Amazon and Cloudflare. Their key advantage lies in Content Delivery Networks (CDNs), which allow developers to serve data from data centers nearest to end users.
    If we implement a solution that automatically moves severs closer to users, we would be a better solution than Amazon or Cloudflare.
    Cloudflare’s CDN nework map for reference:

This proposal seeks to enhance the ICP network’s efficiency, transparency, and competitiveness. It allows us to better cater to the needs of developers and users alike, ultimately positioning Dfinity as a leader not only in the decentralized internet space, but also as a leading CDN provider.

By implementing these changes, we can provide a more robust and responsive network that benefits everyone involved.

Dfinity community, I invite you to join us in discussing and refining these ideas. Does this make sense at all and am I overlooking anything?


Great write up and in-depth.

thanks for taking the initiative to do this!

1 Like

I would like to know, how i will get tokens after participating in a project on launchpad, thanks

Hello @BRosso, it looks like you posted into this topic by accident?

I’d recommend that you start a new fresh topic to ask that.

The offer is good. I think justice would be achieved if a small contribution was added in favor of the knot providers.
The following thought should be added to the proposal. Due to the hardware investment made by node providers, 20% of the total reward during the period should be distributed to all node providers in accordance with their hardware capacities. The remaining 80% reward must be distributed as described in the offer.


I felt the need to explain the rates I wrote above. The return on investment made by node providers must occur within a certain period of time (years), regardless of the operation of the network. Like all investors, the ability of node providers to make a profit must depend on the high level of functioning of the network. However, the current node provider reward system guarantees that node providers make profits without taking any risks. At the rates I propose, the depreciation of node providers is guaranteed within a certain period of time, but like all investors, their profit depends on the high rate of operation of the network.
My expectation is that the community will turn this discussion into a proposal as soon as possible and submit it to a vote on NNS. If this proposal passes the vote and comes into force, it will definitely place ICP at the center of the web3 ecosystem in the coming years.

1 Like

Gonna drop a comment here because I like this idea and I don’t want this discussion to be forgotten. I don’t have the ability to invite people to discussion but I’d like to see this talked about more.


From a separate perspective, specifically with regards to training AI models, this system presents a unique opportunity. AI model training is known for its extensive compute time requirements. However, it also possesses a degree of flexibility in timing due to its generally non-urgent nature. This characteristic aligns well with the proposed system, where developers can choose their desired level of performance based on the fee they are willing to pay.

By strategically scheduling AI training during periods of low node utilization, we can benefit from lower costs, as these times would correspond to lower priority usage. This approach not only makes economic sense but also contributes to a more efficient use of the IC’s resources. Keeping the nodes active, even at a lower priority, ensures closer to optimal efficiency, maximizing the overall utility of the network.

Additionally, this model could incentivize the development of AI applications that are inherently more flexible in their compute requirements, further aligning with the dynamic nature of node availability and cost. It’s a win-win scenario where cost-effectiveness meets resource optimization.