[Disclaimer: the author has holdings in ICP as of the writing of this piece. None of what follows should be taken as financial advice. The author is not a representative of the Dfinity foundation.]

Last updated: July 11th, 2021, to incorporate newly-available IC cost data.

The Internet Computer (IC), if you haven’t already heard, is one of the most exciting new decentralized platforms to issue its own cryptocurrency. Its creators bill the IC as “the last original Layer 1 blockchain project … provid[ing] a limitless environment for smart contracts that run at web speed, serve web, scale, and reduce compute costs by a million times or more.” At root, the IC might be thought of as a decentralized, blockchain-based web-server, enabling developers to launch web services free from reliance upon Big Tech, and with all the benefits of decentralization manifest in other smart contract platforms like Ethereum.

While the IC and the benefits it promises have been covered in depth by many, few have shared how they might quantify the fundamental value of ICP, the token that powers the IC. That’s what this piece does.

Summary of ICP tokenomics

ICP’s tokenomics go a long way toward pinning down its fundamental value.

The current total supply of ICP is ~470 million. ICP is burned to pay for IC web services (through a mediating token called “cycles,” discussed a bit more below). ICP is created to pay those who govern the IC and/or provide the infrastructure that supports it. The “Network Nervous System” (NNS), the IC’s cerebrum, controls these mechanisms for burning and creating ICP.

Importantly, these tokenomics imply that ICP’s total supply is not fixed. ICP’s total supply grows if more ICP is created than burned, and falls if less ICP is created than burned.

So ICP’s fundamental value depends pivotally on the balance of ICP created and burned. The more ICP is burned — which happens the more the IC is used — the smaller the potential supply of ICP, and so the higher the price.

Deriving a “fundamental value” expression for ICP

To derive an expression representing the fundamental value of ICP, we can start with the assumption that ICP’s price will settle where the amount of ICP created equals the amount of ICP burned, such that ICP’s supply is in fact constant:

(1) ICP Created = ICP Burned

But wait — didn’t we just say that ICP’s supply will not be fixed? Let me explain.

The alternatives here would be ICP supply increasing (inflation) or decreasing (deflation). ICP inflation is possible, but is less conservative from a pricing perspective, and so set aside for the moment, to err on the conservative side. ICP deflation, ultimately to 0 ICP supply, on the other hand, is much less possible. ICP market participants would not logically tolerate ICP’s deflation to 0: deflation like this would mean that users are burning a lot of ICP to use the IC, implying that it is quite profitable to buy and burn great quantities of ICP at prevailing ICP prices. If this were the case, ICP’s price would rise, as ICP buyers would outbid each other to secure scarce ICP representing the chance to reap profits on the IC. So to be sure, there may be periods during which ICP is deflationary; but eventually, ICP’s price would increase until ICP is no longer deflationary in a material way, and is instead better estimated by stability in ICP supply.

Now, if we accept equality (1), above, then we’ll soon see that the right-hand-side (RHS) of equality (1) can be recast in terms of the price of ICP, which enables expressing ICP price as a function of that equality’s other components.

But first things first, starting with the left-hand-side (LHS) of equality (1). The amount of ICP created by the NNS each year, as communicated by the creators of the IC (Dfinity), starts at 10% of outstanding supply, declining each year for 8 years, and levelling off at 5% per year after year 8:

ICP Supply Inflation (Source: Dfinity, Creators of the IC)

Dfinity materials also indicate that a certain relatively fixed amount of essentially fiat payouts will be made to IC node providers (remitted in ICP); but given the significant fiat value of existing IC funding, it seems reasonably safe to assume that node provider payouts will represent at most a small proportion of existing IC funding, so it is unlikely to meaningfully inflate the ICP supply over time. (This is a slight simplification, but probably a reasonable one given the dollar values at issue, outlined in a bit more detail here.)

So in general, the amount of ICP created in a given period can be taken to be equal to the product of the inflation rate and the outstanding total supply:

(2) ICP Created = ICP Inflation Rate x ICP Supply

That gives us the LHS of equality (1).

Now, the RHS of equality (1) — ICP burned — is slightly more involved. But before we continue, we should take a small deep-dive to understand in a bit more detail just how ICP is burned to use IC web services.

Technically, IC web services use something called “cycles” to pay for IC processing power and storage. Cycles are bought using ICP. And importantly, the IC is designed so that 1 trillion cycles (units of compute/networking and storage) always cost a constant amount in fiat dollars, set technically to 1 SDR (a value representing a weighted basket of world currencies maintained by the IMF, which today equals ~$1.44 USD).

These mechanics are relevant when estimating likely adoption of the IC by developers and users; but they don’t play a role in ICP’s fundamental value besides, as it happens.

This is because, zooming back out again, the key to understanding the RHS of equality (1) — ICP burned— is in really grokking that ICP is burned only when IC web services are used. And if we can estimate the fiat value (e.g. USD) that web developers as a group will spend on ICP to run IC web services, then ICP burned is just that total fiat amount divided by the price of ICP:

(3) ICP Burned = ($ Spent by Devs to Run IC Services) / ($ ICP Price)

So for example, if developers spend $6 to run IC services, at an ICP price of $2 per ICP, then 3 ICP would have been burned.

Now, a lot feeds into the term ‘$ Spent by Devs to Run IC Services’ — or to label it more concisely, ‘$ IC Spend’ — and we’ll break that term down in a moment. But first, equalities (1) — (3) are enough to cast the price of ICP in terms of other identified exogenous variables. Combining and rearranging equalities (1) through (3), we get:

(4) $ ICP Price = ($ IC Spend) / (ICP Inflation Rate x ICP Supply)

This expression is intuitive: the more that users spend on IC web services, the higher the price of ICP. The greater the inflation of the ICP supply, the lower the price of ICP. It’s this proportion that matters for the price of ICP.

We can also note here that equality (4) follows logically from mathematical identities (2) and (3) above, resting on only the one assumption represented by equality (1): that ICP will not be deflationary in steady state. And in fact, if we permit that ICP can be inflationary (relaxing equality (1) so that it reads instead as “ICP Created ICP Burned”), and follow all the same logic thereafter, we actually get a more relaxed relationship:

(5) $ ICP Price ≥ ($ IC Spend) / (ICP Inflation Rate x ICP Supply)

This inequality is in fact probably more accurate, as units of exchange tend to be slightly inflationary over time, to accommodate that greater reserves (of e.g. ICP) tend to be demanded by market participants over time.

Quantifying the value of ICP

We’re now in a position to start estimating the quantitative values to assign to identified inputs for ICP’s fundamental value, to get a dollar price of ICP.

To do this, we’ll need to flesh out the meat of inequality (5), represented by the numerator, “$ IC Spend:” the fiat dollars spent by developers to run IC services. This value will be driven by both web developers creating IC services, and also on users using those services. Looking at each set of stakeholders will enable estimation of the value “$ IC Spend.”

Start with IC web users. The IC truly does run at web speed (to get a tiny taste for yourself, check out some of these classic games — 2048 and the T-rex game — already ported over to the IC); and IC application performance is practically indistinguishable from that based on a traditional web 2.0 stack. Indeed, since users need not pay to use IC services (which are funded instead by developers), a user need not even be aware that they’re using an IC service (unlike e.g. Ethereum, where users need to pay ETH to use Ethereum services). In fact, the IC has some very convenient user advantages relative to alternative web stacks, including Internet Identity — a password-free means of authenticating with any IC service. So from a user perspective, the IC is, if anything, more enjoyable to use than services run on an alternative stack.

So the limiting factor to IC usage is probably developer adoption and deployment of compelling IC web services. And here we have to think a little more deeply about the market segments in which the IC is likeliest to stand best among available web stack alternatives, from a web developer’s perspective.

In general when it comes to developer adoption, web developers will likely choose to buy and burn ICP to run IC web services insofar as the IC is easier, more profitable, or sufficiently less risky to use when compared to available web stack alternatives. The developer community is already rich with resources and potential funding to develop on the IC. So the opportunity to save time/effort/money, reduce risk, or deploy services that weren’t previously possible is what will attract web developers to build and run IC services. And already, the IC seems to represent a compelling alternative on these fronts to both web 2.0 stacks (e.g. AWS and GCM) and web 3.0 services (e.g. Ethereum).

Comparing the IC to web 2.0 stacks

Vis-a-vis web 2.0 stacks, the IC as it stands today already seems to this writer (a novice developer) to be easier to use and maintain as a developer. While the IC’s purpose-built language, “Motoko,” is still undergoing rapid development in collaboration with the burgeoning IC developer community, experienced developers can still choose to use any language that compiles nicely to WebAssembly (e.g. Rust). And already, writing and deploying working code to the IC is quite straightforward. No Postgres database, no separate server, no finicky AWS configuration, no backup infrastructure— just write your code and deploy straight to the IC (or if one prefers, through a third-party IC-based provider like fleek.co).

Besides ease of use, the IC has been designed to practically eliminate platform risk, by enabling developers to create and integrate with services featuring “non-revocable APIs” — third party services that cannot later be withdrawn or diminished. (In a traditional web 2.0 stack, developers at all times risk seeing their integrations with third-party services breaking when third-parties update their codebases or terms of service. The company Zynga’s reliance on Facebook to host the famous online game “Farmville” represents a recent cautionary tale of platform risk.) Moreover, the IC enables (decentralized) services that simply aren’t possible on a web 2.0 stack. Witness the dramatic rise of decentralized finance (“DeFi”) on Ethereum, for example: such services are only possible on a decentralized platform like Ethereum or the IC.

Now to be sure, cost is more ambiguous when comparing the IC to web 2.0 stacks. The icp.guide offers a nice breakdown of key cost comparisons, which we explore in a bit more detail immediately below.

IC storage costs are fairly cheap in absolute terms (~$5 USD per year per gigabyte), but still roughly 3.62x the storage cost of e.g. AWS RDS — though IC data is replicated at least 7x by default, whereas web 2.0 storage is not.

Data-update/data-read costs are quite comparable to web 2.0 services when read in combination, even without considering data replication. While it’s free to load data on AWS, for example, it costs ~256x more to read it on AWS. And in the simplest case, you only need to load up data once, and then it gets read many more times. A simple break-even analysis shows that the IC is actually cheaper than AWS if, for every GB saved (costing $9.56 on the IC and $0 on AWS), that saved GB is read ~137 times (costing $0.07 for each read on AWS, and $0.0002733 on the IC). This seems like a realistic save-to-read ratio in general— if not quite conservative.

Finally, backend transfer costs — transferring data from one backend service to another — look higher on the IC (~10x greater after accounting for differences in replication factor), so digital services relying on other own (or third-party) code will likely be more expensive on the IC. But then again, API-enabled IC services, which by definition rely on third-party code, can do things (with e.g. immutable third-party smart contracts, a.k.a. “canisters”) that can’t be done on web 2.0 services. So if that’s what’s being offered by these IC services, users will likely be willing to pay more to get the benefit of these IC-unique services, offsetting higher backend data transfer costs on the IC.

All of this said, in the final analysis comparing the IC to web 2.0 stacks, while direct IC platform costs are likely to fall over time, and despite the IC’s relative ease of use and potentially significant cost reductions in many aspects of expensive stack maintenance and system software/infrastructure besides, for now it seems maybe likely that the IC will appeal most to developers looking to create new services that are only possible on, or much enhanced by, decentralized platforms. It’s perhaps later that the IC will appeal more to the platform-risk-conscious developers who will build services on top of early adopters’ services — before the IC then becomes more widely-adopted thereafter.

Comparing the IC to web 3.0 stacks

So considering that the IC is likely to appeal today most to developers seeking specifically to build out decentralized applications (“dapps”), how does the IC fit in with decentralized platforms? Answer: quite nicely.

Among existing smart contract platforms, Ethereum stands foremost, now boasting the most robust web 3.0 developer community and dapp ecosystem — especially when it comes to DeFi. But outside of DeFi, and among web 3.0 alternatives, the IC offers distinct technical advantages — namely web speed, much lower and more predictable compute cost, and complete independence from Big Tech stacks — as even Ethereum dapp front-ends currently mostly live on AWS, Google Cloud, or similar. (Indeed, the IC represents an opportunity for Ethereum and other web 3.0 providers to offer users complete, end-to-end decentralization, by hosting their front-ends on the IC.)

So markets most directly appealing to dapps are perhaps the IC’s most attractive opportunity at the moment. And sizing these markets is probably a good starting point for estimating “$ IC Spend” in the early years of the IC.

IC initial market opportunities and implied valuations

Some of the biggest dapp market opportunities outside of DeFi include social media, news, and other peer-to-peer services (e.g. chat); multiplayer gaming; identity management and data proprietorship; numerous kinds of coordination services (e.g. supply-chain management, health information exchanges, etc.); and many other services besides. A number of such services — especially social — have already been released in the first 3 weeks of the IC’s life post-beta-launch (e.g. DSCVR, OpenChat), or are otherwise built for ready deployment (e.g. CanCan, LinkedUp).

To get a sense of the market size represented by initial target segments, it’s helpful to take a look at the users of major cloud providers today, to get some intuition regarding what share is represented by those segments. Here are the top 10 biggest users of Amazon Web Services (AWS), for example (out of more than 1 million users), including monthly spend:

  1. Netflix: $19 million
  2. Twitch: $15 million
  3. LinkedIn: $13 million
  4. Facebook: $11 million
  5. Turner Broadcasting: $10 million
  6. BBC: $9 million
  7. Baidu: $9 million
  8. ESPN: $8 million
  9. Adobe: $8 million
  10. Twitter: $7 million

Needless to say, this list is almost completely composed of social, news, and peer-to-peer services — and in many cases, listed services represent a fraction of total storage/network/compute spend of each of these users (e.g., Facebook runs most of its own servers and networking operations). In fairness, top users of cloud services may not be completely representative of the usage of all users; so taking what might be considered to be a conservative stance on these points taken together, one might estimate that 50% of the global cloud market is represented by the dapp target segments above. (To be sure, though, this estimate could use refining, as the initial fundamental valuation here is sensitive to this number.)

Now, the global cloud computing market is estimated to be somewhere in the area of $450 billion today, growing at 18% per year. That represents storage, compute, networking, and systems software spend. The IC stands to substitute for all of these services. So if we assume that initial target verticals represent 50% of this market per the estimate above, then the target market size today is $225 billion (and growing fast).

(It’s worth noting here that this number conspicuously does not account for the IC’s potential to serve as the front-end for all decentralized services (Ethereum, Polkadot, etc.). It does not account for potential net new migration from on-premises stacks, as opposed to cloud stacks, to the IC. It does not account for perhaps the likelihood that the IC, in its relative simplicity and ease of use, actually grows the size of the addressable cloud market itself, by enabling more developers than ever before to deploy services where previously prohibitively complex and time-consuming. It does not account for these things because this is meant to be a more conservative take.)

Based on these numbers, if the IC were to peel away 5% of cloud computing users from just these initial target verticals in 5 years’ time, that would equate to developers spending $15.66 billion per year on IC services. (For comparison, AWS, as a single closed-source cloud provider in today’s market (much smaller than that expected in 5 years’ time), makes cloud sales of around $50 billion.) Per inequality (5) above, this would imply a price of at least~$773: ($15.66 billion)/(~470 million x ~6%). 8 years from now, that baseline price would rise to ~$1,291, as the cloud market grows and ICP inflation falls to its steady state of 5%.


Given the potential addressable market for the IC, the expert team behind its development, the developer ecosystem springing up to nurture the protocol, and its relative advantages and complementarities vis-a-vis existing web 2.0 and web 3.0 stacks, ICP looks to have a fair amount of upside potential on the basis of its use as a utility token alone.

It’s also worth noting that the foregoing doesn’t account for the possibility that ICP may at some point come to be seen as a store of value, which would imbue it with additional fiat worth (in the same way that Bitcoin has come to be seen as a reserve asset like gold). Nor does it account for the possibility that ICP could be imbued with additional fiat value on the basis that it provides rights to govern the IC itself, which are inherently valuable rights in themselves. And for ICP holders, it moreover excludes consideration of the ability to stake ICP for considerable annual returns, when contributing to IC governance.

Long-term potential upside must always be risk-adjusted to account for the project’s relative nascency, its technical novelty, the possibility of entry of competitors, regulatory risks attaching to crypto markets generally, and project-specific team, ecosystem, and governance-related risks. All recently-launched blockchain projects are risky prospects by nature. But even after adjusting for these risks, one might still reasonably conclude that ICP could well enjoy a rosy future.

Alex Mucalov
Alex Mucalov

Global strategy & governance professional in financial services, former regulator of "vices." Self-taught Python, Swift and Solidity developer - learning Motoko! JD/MBA (Toronto), MSc Economics (LSE)

Connect with @AlexMucalov on Distrikt

Connect with @AlexMucalov on DSCVR