Node Providers - Over Compensated & Under Used

Please note that aside from raw data, this article is purely speculative with the intention of provoking thought & conversation. This article is not financial advice, and does not venture beyond the scope of research. Please note that not all figures will be exact, as most math was done backwards based on current metrics.


- Nodes on the Internet Computer operate at a 100x+ inefficiency, with self imposed limitations of 300GB while having the capacity to store 30+ TB

-The Internet Computer burns .84% of what is rewarded to Node Providers on a monthly basis via Cycles Burnt

-Of the 36 Subnets, with a total storage capacity of 10.8 TiB, only 3.55 TiB is utilized, representing an inefficiency of 70%+

On September 11th 2023, I published the article “Node Provider Inflation Spiral” within $ICP forums, of which, can be referenced below:

This conversation sparked great interest, earning acknowledgment from members of the DFINITY Foundation as a valid concern that should be addressed. Subsequently, this sparked the interest of multiple Node Providers, most notably, @DavidM & @dfisher ,
who voiced multiple valid points & concerns, from not only the perspective of a Node Provider, but from the perspective of an individual attempting to safeguard the Internet Computer Network.

With this being said, a perspective recurringly raised by vocal node providers, is the importance of not correlating a subnet & its nodes’ reward rate, to total subnet useage.

This concern was raised due to the fact that Node Providers can not pick the subnet they’re in, and therefor are consequenced with the potential of contributing to an underused subnet - earning lesser rewards in contrast to the previous system.

This again, sparked my interest:

if Node Providers can not contribute to the network at scale without fear of contributing to an unused subnet, is the network over burdened with Nodes, or are Cycles not being burnt proportional to the true cost of running the network?

The first question to address is whether unused subnets should be compensated - taking us down a difficult road to navigate.

On one hand, if a Subnet is not being used, it is not contributing to the cycle burnt rate, and therefor only has the potential to increase inflation under the current reward scheme.

On the other hand, we have to consider why this inflation trade off is made. The Internet Computer is completely reliant on Subnets of Nodes to scale - if left without room to grow, there will come a time in which the network has to scramble to provide Nodes in time for dApps, which can take months, given Nodes are hosted in Data Centers.

As such, the line of determination in regards to what Nodes should and should not be compensated is cloudier than presumed.

However, something that the Internet Computer Network as a whole has agreed on, is that Node Providers providing degraded, or lesser services, are deserving of reward slashings. I believe a similar system could be translated to unused Nodes & Subnets, although that’s not what we’re here to discuss.

From here, we can begin to determine the disparity in total Node Provider Reward Distributions & Cycles Burnt, in contrast to the network state overtime.

Referencing the ICP Burn Chart, it can be noted that the Internet Computer has a cumulative burn rate of 136822 ICP - of which, 136,215 ICP come from transaction burns (presumably burning conversion transactions), while 607 ICP comes from transaction fees.

Next, we can reference the Cycle Burn Chart for a more accurate gauge of the cumulative monthly burn of ICP over the last 3 months:

The cycle burn chart indicates that on average, 5.1B Cycles were burnt each second over the last 3 months, which equates to 440.64T Cycles burnt a day.

For simplicities sake, we’ll convert this to an ICP amount before extrapolating to a monthly basis.

This can be done by first dividing the daily cycle burn rate by the SDR exchange rate to determine the daily fiat expenditure of the network.

440.64T Cycles / 1T = 440.64 SDR (• 1.31 = 581.17 USD$)

This can then be extrapolated to an ICP amount by utilizing a 90 day average of the ICP token price, of 3.5$.

581.17 USD$ / 3.5$ = 166.0485 ICP

Now that we have determined the network burns 166 ICP / day across a 3 month average, we can extrapolate this to estimate a monthly network burn of roughly 4957.45 ICP.

In contrast, the previous article “Node Provider Inflation Spiral” depicted that the Internet Computer Protocol minted 500k+ (on the lower end) ICP each month, during this timeframe, reaching an all time high distribution of nearly ~600k ICP tokens last month.

Utilizing Augusts Node Provider Reward Distribution data, we can determine that of the 583,577 ICP minted to compensate Node Providers, only .84% of it was correspondingly burnt via Cycles, showcasing a disparity of 99.16% between Node Provider payouts & ICP burnt via cycles.

Turning our attention back to Network State, it can be observed within the following article that Gen1 Node Machines have a storage capacity of 28.8 TB & 30.72 TB

Alternatively, Gen2 Node Machines have a storage capacity of 32 TB.

In contrast to their abundant storage potential, according to public documentation & official forums, subnets are seemingly limited to a capacity of 300GB.

With this information laid out, we can continue to the Network State:

As of present, the current Network State is 3.55 TiB of a total 10.8 TiB, across 36 subnets - which equates to roughly .098 TiB per Subnet (the math is not so simple, but this is useful to depict network load), or roughly 30% of each Subnets maximum capacity in correspondence to current self imposed limitations.

This goes to show that the issue is not so simple as “are we over paying or over onboarding Node Providers?” - it’s a combination of both, with Cycles burning less than 1% of what Node Providers are compensated monthly, while Nodes are operating at seemingly a 70% inefficiency.

Which raises the question:

Is over compensating Node Providers while over on-boarding worth the burden it’s brought upon the network?


Going to tag relevant parties before this thread spins out of control, so that we can work towards a solution ASAP:

@bjoernek @Kyle_Langham @dominicwilliams


Good afternoon @diegop & @Ang !

It seems as though bad actors are attempting to circumvent this thread in which directly addresses concerns to the networks tokenomics & sustainability.

It would be a shame if such an important topic, was allowed to be taken off-topic, as so many others in the past. Thanks!


In a previous ICP.lab there were very interesting discussions about how to use this excess space. I know that there are(or at least were) proactive discussions about how to use this space in a more generic and generalized web3 way that would burn more cycles.


Do we really want to figure out how to spend more money rather then save it?

1 Like

Hmmm…I think we want to offer more ways to utilize the space that has been allocated. If each rack has a bunch of excess storage and the IC offers a competitive price for storage, this seems like a win right? Currently, node providers are paid if the space sits idle. If we use the space and it burns cycles, that is deflationary for ICP right?

FileCoin/Arweav/Storj storage is 1 terabyte (TB) of data on for between $0.19 to $4.00 per month. Seems like ICP could compete with that if there are 31.7 TB of empty space sitting around on each subnet. Plus ICP storage would be computable on canisters, so it probably isn’t a direct comparison.


I agree. Since the node provider cost seems pretty fixed in the medium term, we may as well encourage full utilization.

This can possibly also have a marketing effect if the cost on IC is drastically lower than alternatives. However as the usage gets closer to full utilization, the cost should rise with it.

1 Like

Is over compensating Node Providers while over on-boarding worth the burden it’s brought upon the network?

No its not. There are zero users who use this network and therefore there is no need to run a fat big machine. Its like using a jumbo jet to transport 3 people. the single most problem this project has, it is not able to generate interest in the crypto community. These people are users who would use the network and burn ICP to reduce inflation significantly. The tokenomics are wrong and need to be changed according to present real world usage data we have.

1 Like

Legitimate concerns, imo. It would indeed be better if network costs and revenues were closer together. Just curious, from my non-developer perspective, did you consider:

We ‘retail investors’ don’t care whether we have to pay 0.0001 ICP/TX or 0.01 ICP/TX (at current price levels). My fear of rising network costs:

  • Push away existing parties with high cyclical use. Do you know which parties have the largest consumption and are at risk of not being able to bear these costs?
  • That we are uninteresting for new (large) parties, because we cannot compete with cloud services such as AWS and AZURE and/or other blockchains.

To get closer to a solution, my questions are the following:

  • Do you want to go down the path of changing network costs? Business parties want clarity about these costs and do not like uncertainty upfront on their investment. Stability would serve us long-term.
  • The current ≈ 5000 TX/second is not on the retail side. What are they?
  • Is it possible to distinguish transactions in some way (token transfers, storage, validation, etc.) in order to possibly apply different rates?
  • Have you thought about doing a long-term cost-benefit analysis (2 years?) for the available scenarios? That will be a lot of assumptions, but gives us a better understanding of the path ahead.

AccumulatingICP made some relevant points here. It would appear that the network can’t scale to compensate the node providers while burning the same value regardless of the usage. It’s very concerning.

Why aren’t you concerned?

I created a discussion/proposal for how this could be solved, and would love your input int he discussion:

As far as I understand, the maximum supply limit has been created. However, this does not solve the problem. Node providers’ pricing is calculated as SDR and paid as ICP. As the price of ICP decreases, more ICP is printed and given to node providers. Of course, since node providers do not burn even 1% of the ICP they receive, they sell the ICP they have to the market and create inflation. The payment mechanics to node providers should also be applied to the burning mechanics of node providers; Most of the ICP amount they receive should be burned in the cycle and they should only keep a reasonable profit rate. This should be the basis of ICP tokenomics. In other words, if this relationship is created between the payment mechanism and the ICP usage mechanism in all purchases made with ICP, not just node providers, the drawbacks of ICP price fluctuations in SDR-related ICP payments will be eliminated.


Why aren’t officials involved in the discussion? It’s such an important matter.

It only causes Inflation when the rewards are higher than the cycles burn rate.

Maybe the tokenomics should be set up in a way that this is not possible, is that what you are saying?

For example: Node Rewards could fluctuate just like BTC transaction costs:

  • when the network is congested, rewards should increase to promote new nodes being created.
  • when the network isn’t using it’s full capacity, rewards should drop, to demotivate new node creation.

This way the rewards would always be in relation to the cycles burned, meaning it would be mathematically impossible to cause price inflation.

Did you see the post I shared in the comment above?

As far as I understand, we are saying the same thing. Payments of node providers are fixed in SDR, but since this payment is made with ICP, when the ICP price drops, this payment is made by prıntıng more ICP. However, the burning cycle of node providers is fixed. Even if they receive a lot of ICP payments, since their cycle burn rate is the same as the previous period, they create ICP inflation by selling the remaining ICP to the market without burning in their wallets. I suggest creating a mechanic by correlating the burning speed of node provider with the ICP paid. In other words, when the price of ICP decreases, so the burning rate should be increased close to the same rate to prevent this excess ICP from being released to the market

I read your offer. What I wrote is a little different. Your proposal aims to optimize the efficiency of nodes. However, I say that node providers earn speculative income through ICP price fluctuations. I say this speculative income must be prevented

Theoretially, my proposal solves 2 things at once:

  • the efficiency of nodes
  • but also the inflation issues.

The main issue at the moment is that, liek you said, ICP’s rewards are fixed in SDR and never fluctuate.
However, the whole balance of ICP depends on two factors:

  • ICP is burned by app developers who (purchase ICP to burn into cycles).
  • and ICP is generated to reward the nodes that provide those cicles.

This works nicely if there is a balance between the amount of cycles dApps purchase, and the number of nodes providing cycles. As long as those are in balance, there would be no inflation, no matter what the price of ICP. Because the same way you need more ICP to reward nodes, developers also have to spend more ICP to purchase cycles.

But there is nothing making sure that there is a balance between those two:

  • if there is MORE demand from dapps, it starts burning ICP faster.
  • however, and here’s the kicker: if there are too many nodes, they keep generating ICP tokens, but those tokens arent used by any apps because there is no demand for it.
  • and there is nothing stopping more and more nodes from being added to the network. There is a vote to decide on new nodes, but once a node has been accepted, it receives 100% rewards even if the network goes through a bear market, and even if all dApps stopped running. Nodes just keep getting rewards regardless. This is, in my eyes, an oversight.

To solve that, ICP would need to have a system in place that works like a free market regulating itself:

  • if there’s a shortage of bananas on the market, the price goes up.
  • if there are too many bananas on the market, the price drops.

In the same way, it should lower the rewards when there is no demand for nodes, and it should increase the rewards as we get closer to a shortage of nodes. That’s what my post is all about.

So let me give some examples of how something like that could work:

  • if the node usage is getting close to 100% of capacity, node rewards would be at an all time high. This would incentive new nodes from being created since everyone wants to reap those “sweet sweet inflated rewards”.
  • but if there are too many nodes, for example: only 10% of the available capacity being used, then rewards would be lower. This would stop new nodes from being created, since the rewards would not cover the costs of running those nodes.

This needs a lot more discussion to make sure it is solid. But I dont see a future where ICP doesn’t use a system that allows the rewards to be self-regulating in real time. And it would completely solve the issues described here (if it works :sweat_smile:)

Thank you very much for your events. Of course, everyone writing here wants ICP to get rid of this inflation spiral. This study must definitely be put to vote. I also have a small voting right. I’m looking forward to voting.