Tokenomics series: Projection of cycle demand and required network capacity of the IC


In a series of articles, we aim to present an ICP tokenomics framework that enables us to analyze the relationship between various factors influencing the supply and demand of ICP. This framework will offer a quantitative basis for assessing the state of ICP tokenomics over time and evaluating potential changes.

In this first article, our focus is on the demand for cycles, which are utilized to pay for operations on the Internet Computer (IC). By extrapolating the observed historical growth in cycle demand, we can estimate the required number of node machines in the IC network to support this demand.

Through a comparison of the current required and available nodes on the IC, we estimate that we currently have an excess capacity of approximately eight times the demand.

Based on the historical growth-rate factor of cycles, which stands at 4.76 year-on-year, we define three scenarios with low, medium, and high year-on-year growth rate factors. Under these scenarios, the projected number of nodes required on the IC will range from 8,000 to 200,000 node machines in six years’ time. The timeframe for a significant ramp-up of new additional nodes falls between the end of 2025 and the end of 2027.

Recap of cycles and node machines

ICP tokens can be used to pay for the usage of the IC. By converting ICP tokens to cycles, developers can pay for installing smart contracts, known as canisters on the IC, and cover the resources those canisters utilize (storage, CPU, and bandwidth). The conversion rate of ICP to cycles is pegged to a basket of fiat currencies (XDR), resulting in fluctuations based on the market price of ICP. This ensures predictability in the cost for developers to acquire fuel for running their applications.

Subnets & node machines
The IC consists of multiple subnet blockchains. Each subnet consists of some number of decentralized, independently owned and controlled node machines that run the software components of the Internet Computer blockchain protocol. Running multiple subnets in parallel allows for unlimited scalability of the IC. The Network Nervous System (NNS) plays a crucial role in coordinating the subnets by assigning nodes to specific subnets and determining the protocol version they should run.

Given the varying security, size, and feature requirements of different canisters, not all subnets have the same configuration. For instance, the system subnet hosting the NNS does not charge any cycles for its canisters as they should be accessible in all circumstances.

The Internet Computer (IC) currently comprises 35 subnets with 549 active node machines, and there is a total of 1235 available node machines. Most subnets are composed of 13 nodes, with a few exceptions. Notably, the NNS subnet consists of 39 nodes, the II subnet consists of 28 nodes, and the SNS subnet consists of 33 nodes.

Historical development of cycle burn-rate

The graph below illustrates the development of the burn rate in trillion cycles since the beginning of last year. We use trillion [T] cycles as the unit because 1 T cycles cost 1 XDR.

From the graph, it is evident that the burn rate has shown a significant and relatively steady increase over the analyzed time period. It’s important to note that the drop from Dec '22 to Jan '23 can be largely attributed to an efficiency improvement, specifically the introduction of timers. These timers allow canisters to perform periodic tasks at a lower frequency than heartbeats.

From Jan '22 to Apr '23, the amount of cycles burned increased by a factor of 7.04, which corresponds to a monthly increase factor of 1.14 (calculated as 7.04 raised to the power of 1/15) or a yearly increase factor of 4.76 (calculated as 1.14 raised to the power of 12).

Development of burn-rate capacity of subnets & nodes

Recalling our earlier analysis on the cycle burn-rate capacity of nodes on the Internet Computer:

  • The current maximum burn-rate capacity of a 13-node subnet on the Internet Computer is 7,800T cycles per month, equivalent to 600T cycles per node per month.
  • By implementing performance optimizations and enhancements in the cycle pricing framework, the burn-rate capacity could increase by a factor of 20 within 4 years.
  • Assuming an average subnet utilization of 30%, the current average capacity of a node is 180T cycles per month, and the projected capacity in 4 years is 3,600T cycles per month.

For our analysis, we assume that burn-rate capacity grows via a constant growth factor from 180T cycles currently to 3,600T cycles in four years.

It is important to note that this analysis assumes no significant increase in the hardware performance of the node machines. This assumption is reasonable since the IC already operates on highly powerful node machines, and any hardware performance improvements are expected to be relatively small compared to the aforementioned enhancements.

Projecting the cycle burn rate and required IC capacity

Based on the historical observations from the previous section, we can derive estimates for the future growth of the cycle burn rate.

Several key factors influence the future cycle burn rate, including the increasing usage of existing operations, the introduction of new features, and potential pricing changes such as the implementation of charges for queries. Given the challenge of forecasting growth development accurately, we recommend applying a range of scenarios for the analysis. For our projection horizon, we consider the time period until May 2029, which is eight years after genesis.

Medium-growth scenario: In this scenario, we assume that the cycle burn rate will increase by a factor of 4.76 year-on-year, aligning with the observed historical growth.

Low-growth scenario: In this scenario, we assume a more conservative increase in the cycle burn rate by a factor of 3.5 year-on-year. To determine this factor, we sort the 15 monthly returns from Jan '22 to Apr '23, excluding the top 5 and bottom 5 values. The average of the remaining 5 returns is 1.11 month-on-month or 3.5 year-on-year. This represents a 25% reduction compared to the observed historical growth.

High-growth scenario: In this scenario, we anticipate a more accelerated increase in the cycle burn rate, driven by the introduction of new features such as the launch and operation of many SNS DAOs or the growing usage of chain-key Bitcoin. We assume a factor of 6 year-on-year, which is 25% higher compared to the observed historical growth and thus symmetrical to the low-growth scenario.

Using these scenarios, we can project the number of nodes required to support the projected cycle demand. We divide the projected monthly cycle demand of the IC by the average burn-rate capacity of a node, round up to the closest multiple of 13 as the assumed number of nodes in subnets, and then add the number of 80 nodes in system subnets for which no cycles are charged. It is important to note that this calculation could be further refined, for example, by including spare subnets to accommodate sudden increases in demand.

According to our calculation as of Apr '23, sustaining the current cycle burn rate of 13.3K T cycles per month would require 158 nodes. Comparing this to the current number of available nodes on the IC, which is 1235, we currently have a surplus compute capacity of a factor of 7.8 (1235/158).

The following graph depicts the required number of nodes at the end of the projected time horizon, May 2029, for the three selected growth scenarios (low/medium/high).

Based on the scenario projections, we can determine the point in time when the number of required nodes exceeds the current number of available nodes on the IC, which is 1235. This point in time is significant because it indicates when a significant increase in the number of new nodes will be necessary.

  • High-growth scenario: November ‘25.
  • Medium-growth scenario: September ‘26.
  • Low-growth scenario: November ‘27.

Question to learn, which is not clear to me. Is the dynamic management of the number of nodes done through a waiting list?

Example: You have 100 requests for new nodes, but you need 50. Would you add more nodes when the demand uses %70 or %80 of them? How is that administration?

Basically I say this because you control the supply of the token, paying only for the necessary nodes. Without excess nodes that are not necessary…

Another question… regarding the comment you made about the NNS not consuming cycles… Wouldn’t that make the NNS dangerous in a DDOS attack? How to prevent ? Do you have another emergency backup site in those cases?

Thx !! :raised_hands:


Great question! Currently, adding nodes is done by proposal. Indeed, we would need a new (and presumably more automated) framework in place by the time adding a significant number of nodes becomes necessary.

I’m not entirely certain if I fully understand the question. It is a valid concern that we should aim to prevent DDoS or other types of attacks against the NNS, as it is central to the functioning of the IC. However, the fact that the NNS is not charged any cycles is likely not the primary concern in this context. Could you please provide more details on your question?


Is the surplus compute capacity by a factor of 7.8 intentional by design? what is the rationale of the number behind it? For example, why not just set the surplus by a factor of 2 or 3 ?

Does it mean that onboarding new node providers will be slowed down / stop ? Because even at High-growth scenario, the surplus need to be added in the end of next year 2025.


The question arises from the fact that adding more nodes also implies more ICP emission. What would be the motivation to continue enlarging nodes if it is not necessary? Why not do it dynamically when necessary.

This is a reasoning that came to me when you commented that the NNS does not consume cycles. Any other use case, if someone attacks through DDoS, they have a motivation to stop them since it consumes cycles. So if a DDoS attack has no direct “cost”, it can consume cycles infinitely? Are these cycles from true ICP or are cycles generated out of nowhere?

Thanks for the answers!!

1 Like

Great question! Here’s how I see it:

In the immediate future, we could boost decentralization by introducing a handful of new nodes, especially in countries currently without IC node machines.

Looking to the mid-term, our goal should be onboarding a larger quantity of node machines. This would necessitate a more streamlined onboarding process and an enhanced node provider framework.

@SvenF, as a key figure in node provider onboarding, may want to chime in with further insights.

Considering the historical annual growth rate of cycle demand at 4.76 year-on-year, it is prudent to maintain a substantial surplus in capacity. This is especially relevant given the current rate of node onboarding is not yet particularly swift.

However you raise a valid point. We should deliberate over the balance of capacity we aim to sustain moving forward. It is a trade-off between managing costs and the ability to accommodate sudden increases in demand.

The canisters on the NNS subnet are not charged any cycles at all.

I’ve been contemplating some issues with the token mechanics between surplus network capacity and network consumption in the Internet Computer Protocol. Looking at it from the supply side, we see node providers being compensated in ICP based on an official market exchange rate of 1 XDR (USD 1.3-1.4) equating to 1 XTC. However, there seems to be a disconnect when we analyze the demand side.

There’s an abundance of cheaper cycles that don’t match the official exchange rate established by the protocol. In the current situation, the protocol’s official exchange rate is 1 ICP for 3-4 trillion cycles, yet the market price is at 13-14 trillion cycles, meaning that 1 XTC is approximately USD 0.3. This discrepancy is amplified by the unofficial cycles (XTC) market, which worsens the ICP’s surplus capacity issue by another factor of three.

I’ve been pondering on is whether the ICP should implement a decaying function for cycles that remain too long in a cycle wallet canister. This could act as a deterrent against simply hoarding cycles for trading speculation when the ICP price is high, unless those cycles are used to top up dapp canisters, which would make them untransferable.

It’s worth noting that this decaying function should apply only to cycles in the wallet (where cycles remain transferable), and not to cycles in the application canister (where they cannot be transferred). The aim here is to bring the ICP to Cycles exchange function back in line with the published rate. I’m curious to hear your thoughts on this proposed solution?

While I understand this idea might not be popular due to the potential impact on those holding large amounts of cycles in their wallets, I believe it could be beneficial for the tokenomics in the long run. By implementing a decaying function on cycles held in wallets, we might stimulate increased demand for ICP, especially during periods of low price. This could, in effect, stabilize the market and create a healthier economic ecosystem within the Internet Computer Protocol. It’s a delicate balance to strike, but one that could pay dividends in terms of long-term stability and growth.

1 Like

While I haven’t thought much about your idea, I can already say that this is more or less impossible on a technical level. There is no separate ‘wallet’ canister - it’s all as you call it ‘application canisters’. If you want to add a decay function to XTC, go ahead and try to get it in there, but it is trivial to spin up another instance without decay

I think Bjorn has summarized it correctly. For the intermediate future, decentralization of the IC-network can be boosted by adding a limited number of new IC node machines in new regions, countries, and data centers, which is currently in progress. In the meantime, the aim is to further simplify, streamline and automate the node provider onboarding and remuneration models in order to allow for onboarding of a larger number of node machines in case the network requires this.


Thank you for your response and for sharing your viewpoint. While I understand the concerns about the technical feasibility of the proposed idea, I think there might be another way to approach the issue.

Your point about there being no separate ‘wallet’ canister and the ease with which one can spin up a non-decaying instance is valid. However, I believe we could address this by incorporating a concept of ‘inflation’ within the system, especially pertaining to the cost of compute measured in cycles.

Consider this: If the cost of an operation that takes 1T cycles today was to increase by a certain rate, say 2%, it would cost 1.02T cycles next year. Simultaneously, we could also adjust the exchange rate for cycles, where 1 SDR equals 1T cycles today, and next year, 1 SDR would be equivalent to 1.02T cycles.

Such a mechanism could mimic a form of ‘decay’, effectively serving a similar purpose, without the need to directly impose a decay function on XTC or create a separate ‘wallet’ canister.

Of course, this is merely a proposal and would require careful consideration and discussion before implementation. I look forward to hearing your thoughts on this potential solution.

Love to witness the spiky burn rate reach an all-time high. However, upon examining the chart, it’s evident that the baseline burn rate is increasing only modestly, remaining stagnant at 2-5 billion cycles per second. Do you have any thoughts or ideas on how we can narrow the gap between the baseline burn rate and the maximum spiky burn rate?

1 Like

The easiest way would be to use larger ‘bins’. That would take a bunch of the volatility away. But I prefer a regression: GitHub - jeshli/Aleatoric_Regression: Simple Script for Running Aleatoric Regression with Pytorch

As I did here,