Demand Driver - Computation
Part of the Demand Series newsletter
In the previous newsletter, I discussed how ICP transactions (moving ICP from one account to another) was a driver of demand for the ICP token and how the transaction fee could become an important deflationary aspect for ICP. This newsletter will focus on computation on the IC as a demand driver.
Background
Every smart contract (aka canister) on the Internet Computer requires computation for the execution of activities like querying the canister, writing data to the canister and storing data within the canister. This computation comes with a cost, which is paid by the developer of the canister (side note - This “reverse gas model”, where the smart contract developer pays the computation cost, is unique in blockchain. Most other chains require the smart contract user to pay the computational cost, which is akin to a Facebook user paying the webpage hosting cost for their account instead of Facebook. The reverse gas model is very advantageous for the adoption of the IC because it aligns with existing user expectations).
A developer pays for this computational costs by “charging” the canister with cycles, which are then burned to pay the computational costs. A breakdown of the cycle computational costs by operation can be found here. For example, every time a user interacts with Distrikt (a Twitter-replacement on the IC) cycles are burned from Distrikt’s canisters. When the cycle count gets low, Distrikt needs to charge more cycles to the canister to ensure continued operation of their website and functionality.
In order to keep developer costs constant and predictable, a cycle is pegged to the SDR, an IMF controlled basket of currencies. Cycles can only be created by burning ICP. Since ICP can float relative to fiat currencies and a cycle is pegged to a currency, the conversation rate of ICP to cycles floats relative to the price of ICP. As the price of ICP moves up, more cycles are created per ICP burned. As the price of ICP moves down, less cycles are created per ICP burned. If computational demand on the IC becomes significant relative to other uses of ICP, this dynamic will actually serve as a volatility sink for the price of ICP… something I’ll discuss more in a future article.
The tl/dr of everything above is that all use of smart contracts on the IC ends up resulting in ICP being burned. You can get a good gauge of the growth of the IC ecosystem by monitoring the number of ICP burned for cycles.
Where we are at today
Below is a chart of the ICP burned from Genesis until 17JAN22 from ICA’s dashboard. It shows almost no ICP burned for cycles until mid-July 2021, followed by a rapid increase to about 9k ICP through August and finally in a steady increase rate from September through December.
Note - chart stopped at 17JAN22 to remove the ICP burned with the launch of Sonic, which will be discussed in a separate article.
It’s pretty clear that the July and August increase was due to various developer engagements, like the Cycles Fountain, with the intent of providing developers with free cycles to encourage experimentation and adoption. The steady growth of ICP burned since September has averaged about 600 ICP per month and has not shown a rate increase that would reflect month-over-month increasing adoption of IC applications, meaning IC application usage was growing at a small linear pace in the last quarter of 2021.
Where we are going
ICP burned to convert to cycles is a great measure of the adoption and expansion of applications on the Internet Computer. In its first year, the IC saw deployments of well-designed applications like OpenChat, DSCVR and Distrikt and these apps now have established communities of use. However, even with their growth, the number of ICP being burned is less than 1000/month and doesn’t seem to be accelerating at this time. There’s a a few reasons for this:
It is cheap (in ICP terms) to deploy to the IC. For example, Distrikt had only burned ~2 ICP as of 30NOV to fund all their activity up to that point. If needed, the cost of computation can be changed by the NNS, so this may not always be the case.
Usage of these apps is still limited to mostly people within the Internet Computer community. This may change as more people become aware of Web3.
The ecosystem of applications hasn’t expanded much in the first 8 months since Genesis. This will almost certainly change since there are many projects that have deployed in alpha or beta stage in the last month or two.
It’s also clear that OpenChat, Distrikt and DSCVR don’t make up the majority of computational burn on the IC. I say this because there are many accounts that have burned >10 ICP to create cycles between 01SEP21 (after the developer engagement activities like the Cycle Fountain) and before 17JAN22 (when Sonic launched):
I predict we will start to see the rate of ICP burned for cycles increase throughout 2022. However, for computational demand to play a large role in demand for ICP (relative to other demand drivers like staking and liquidity), the rate of change will need to increase by orders of magnitudes, something I don’t think will occur in the next year. Instead, I predict a steady increase in this rate as usage of current applications increase and new applications are deployed to the IC. These applications will then drive demand for ICP through other methods (non-computational) like liquidity pools, ICP transactions and staking on the NNS.
Up next for the demand driver series: Liquidity Pools (this will be a fun one!)
Like what you are reading? Please Subscribe to the newsletter or Share with a colleague.