I was reading up on how the exact mechanism for minting and burning cycles works, and there are several concerns I have about the NNS and about the use of cycles.
So I thought I should write this post and highlight some of the issues I see with the IC. I would appreciate any clarifications and corrections, and I am hoping we can discuss possible solutions. I have seen some of these concerns raised elsewhere in the forums with answers that are not very convincing. In general my concerns are:
- We don’t have a clear understanding of the overall incentives and dynamics between groups within the IC (ICP holders, node providers, developers, end users), and how these incentives may change as we keep decentralising.
- We are relying too much on governance and the NNS to make decisions that could be made either at the protocol level or off-chain.
- Payments to node providers do not seem to be sustainable.
- Cycles adds unnecessary risk and leverage to ICP holders.
Incentives and dynamics
We can divide actors in the IC into groups: ICP holders, node providers, developers, and end users. Many interactions and relationships between these groups are currently held together primarily by the DFINITY Foundation / ICA, and I’m afraid that if we keep decentralising (which we should) the whole system might fall apart because the right incentives are not in place. Or at least we don’t have a clear picture of all of these incentives in play.
I see a lot of great articles about the technical aspects (ex: here and here) of the IC or about the ecosystem (ex: here), but I don’t see articles discussing how these groups are incentivised to work together. If we think about BTC or ETH, for example, miners are incentivised to include user transactions because they are paid a transaction fee. And there is a relatively strong mechanism against censorship because miners are simply choosing the transactions with the highest fees, and only one miner has to include the transaction for it to be on the blockchain (at least for Proof of Work). I haven’t seen such strong incentives on the IC.
Let’s look at a few interactions between these groups:
Reverse gas model
One of the best features of the IC is the reverse gas model, which is great for onboarding new users. However, developers have to add safety mechanisms to prevent cycle draining, which can be very complex, especially if/when query calls start consuming cycles. There is a lot of discussion about this topic, and I’m optimistic about finding solutions as a community. But this highlights a point of contention where developers in this case have to protect themselves.
Ensuring we act in the best interests of end users
End users can use the IC for free, but they also have the least power. How can we ensure that NNS decisions (protocol upgrades, capacity upgrades) are made in a decentralised way and with the best interests of end users in mind? I can imagine situations where it might make more financial sense to ICP holders to rate-limit/throttle users instead of adding more expensive network capacity.
How do we convince the NNS to invest in something that will greatly benefit end users but that might never give ICP holders a return on their investment?
Decentralising node provider onboarding
It will be very interesting to look at how new node provider onboarding will work on the NNS when we start decentralising this process. According to this post, “New node providers shall be able to register directly in the NNS frontend dapp. They will be able to submit a proposal to become a new node provider, without the support of the ICA”.
This sounds great, but also makes me a little nervous. What would prevent node providers from establishing a bribery channel with some NNS holders and pay a bribe to get approved faster? Jordan also has some great questions and concerns. But I feel that this is an area under active discussion, and I’m also optimistic we will slowly find appropriate solutions to these problems.
Cycles tokenomics
As I’ll discuss later, I don’t think the cycles mint/burn mechanism is 100% stable. As we can read here, developers burn ICP (deflationary) to create cycles, which are consumed when running canisters. The NNS then creates new ICP tokens (inflationary) to pay node providers. If ICP prices trend downwards for some time, the “consuming cycles to issue new ICP tokens” step can cause significant inflation. This can create conflict between the cycles holders (developers) and ICP holders about when and how to best deal with inflation.
Overuse of NNS
Decentralised governance is hard, and we should be very careful about overusing the NNS, especially in situations where protocol-level rules or good old off-chain social consensus might make more sense. For example, the community came together to create the ICRC-1 Token Standard, successfully making decisions in an off-chain way. The NNS was only used at the end as a signal that ICP holders accept this new standard.
Paying nodes based on geography
The ICA currently determines how much to pay nodes based on their geography. I assume this task will later be taken over by the NNS. It’s a great idea because it ensures nodes are geographically decentralised. But this also centralises power on this body (ICA/NNS) that decides how much nodes are paid, and I feel it would make it more open to manipulation/bribes.
Would we be able to somehow automate this at the protocol level? Assuming we can reliably get a measure of user activity by geography and a measure of subnet availability by geography, we can simply increase rewards for areas of high congestion and decrease rewards for areas of excess network availability. We would need to be extra careful about DoS and Sybil attacks. But this has the added benefit that the protocol automatically re-balances nodes depending on where users are.
Automating payments to node providers
And a slightly related topic: paying node providers via the NNS also makes these payments subject to manipulation. While we have to be careful, I don’t think it should be too difficult to automate these payments on the protocol level.
On-chain voting vs off-chain governance
Let’s say a bad proposal on the NNS somehow passed. Maybe people misunderstood it. Maybe there was low voter turnout, and a huge malicious ICP holder voted YES at the last second. Maybe someone bribed ICP holders. Maybe it was a proposal for a fake project.
Anyways, a proposal that is unquestionably bad passes. For example it essentially mints $100M of new ICP to give to a random address. Can it be stopped?
Now let’s consider a different scenario. Let’s say that 51% of ICP holders vote to comply with the demands of a government to censor a particular type of transaction or to bring down a dApp. The other 49% and the vast majority of the community are against this. Will the results of the NNS proposal (to censor) hold?
For these scenarios there are two possible outcomes:
- The community + DFINITY + node providers come together to create and implement an update to the protocol to undo this proposal. We can potentially even slash the neurons of the malicious ICP holders. Result: most people are happy, and ICP continues as a single chain.
- The proposal passes and is (begrudgingly) accepted by part of the community. Another very vocal part of the community is absolutely against allowing the proposal. There is a community split, similar to what we saw with BTC and ETH fork wars. Half of the community will want to split off and create a hard fork. This is very difficult to do because the cost of replicating the infrastructure (running nodes, boundary nodes, etc.) is much higher than that on other blockchains. Result: the community is irreversibly fragmented (maybe the vocal minority goes on to implement Badlands finally
)
In both scenarios the best solution is for the community to come together and act in an off-chain way. We cannot overlook the power of off-chain governance.
I think the best thing we can do for a large part of proposals on the NNS is to have loosely-coupled coin votes, as we are already doing for some proposals (see ICRC-1). The coin vote does not trigger a code change. Instead, the coin vote merely acts as a signal to an off-chain governance system to actually implement and deploy.
NNS managing inflation
As I mentioned before, the NNS is in charge of minting new ICP (inflation) to pay to node providers. If this inflation is not adequately balanced by developers burning ICP to create cycles (deflation), then it could lead to significant inflation, which will need to be carefully considered by the NNS and the community.
I don’t think the NNS should be the Federal Reserve trying to manage inflation or a congressional committee managing a budget for day-to-day operations. Governance via the NNS opens us up to manipulation and other risks, and we shouldn’t be relying on governance as a safeguard when the protocol itself should be safeguarding us against runaway inflation. The protocol itself should not allow us to issue so much debt in the form of cycles as to endanger the system.
Payments to node providers
We are currently paying node providers very generously, which is ok when bootstrapping the network. However, when we ramp up node provider onboarding and we get a lot more activity on the IC, we have to make sure that our costs do not run away from us. For this ecosystem to be sustainable, the amount that node providers are paid has to be a function of how much cycles/ICP developers are burning. We’re not running a company that can have good and bad months, where good months (with lots of surplus) can offset bad months. We cannot expect the NNS to do risk management for us.
Our current mechanism pays node providers a predetermined monthly cost independent of activity level. I’m not sure how we can sustain this indefinitely. I think inevitably we will have to start paying node providers a variable rate depending on node usage:
If node providers are paid more than the total amount of cycles burned, then ICP holders are essentially subsidising this computation through inflation of ICP. We cannot expect ICP holders to want to act against their best interests, and I don’t think this mechanism in its current form is stable. ICP holders will eventually stop voting to increase network capacity and pay node providers because they are being unfairly and unsustainably diluted, and this will cripple the network or stagnate its growth.
If on the other hand node providers are paid less than the total amount of cycles burned, then they are paid less than what has been determined to be fair rewards to cover node operating costs, which is not sustainable.
For these two reasons I’ll assume for the rest of my post that when canisters consume 100T cycles, node providers are soon after paid about 100 XDR.
As an aside: I hope I’m making a math error and someone can verify and correct me, but it looks like we are currently paying node providers 50x the amount of ICP that developers are burning. In other words, developers collectively burn the equivalent of 1 ICP to power their canisters, and later 50 ICP is minted to pay to node providers. I understand we are being very generous to node providers to jumpstart the network, but 50x seems very excessive (the current cycle burn rate is about 8,000T cycles burned/month, which is equal to ~1,600 ICP. Compared to about 240,000 ICP minted per month to pay node providers, this is 150:1. If we take into account that only about 1/3 of the nodes we are paying for are actually active, then this is 50:1). Maybe this ratio will improve if/when query calls start consuming cycles?
Cycles
Now my issues with cycles:
Cycles is debt
Cycles can be seen as a voucher. When a developer mints 100T cycles, we are promising them that they can use 100 XDR worth of computation at a future time. When they eventually use 100T cycles of computation, we also need to pay the node providers for this computation, which is worth around 100 XDR (as I mentioned before I’m assuming that when canisters consume 100T cycles, node providers are soon after paid about 100 XDR).
Cycles should also be seen as a debt of ICP holders that is payable to developers in some future date and is valued in XDR. Since the assets of ICP holders are ICP tokens and the debt is in terms of XDR, this creates a huge exchange rate risk. ICP holders essentially have a leveraged long position on ICP, and you can ask crypto traders why that might not be the best idea.
We shouldn’t look at cycles/ICP as a deflation+inflation mechanism - we should look at cycles as a debt that ICP holders need to eventually repay to cycles holders.
For example, Alice burns 20 ICP for 100T cycles (currently 1 ICP = ~5 XDR). Soon after, her canisters consume the 100T cycles, and node providers are paid the equivalent of ~100T cycles, or 100 XDR. If the price of ICP/XDR hasn’t changed, then this is equal to 20 ICP (100 XDR / 5 = 20), which is minted. In this case, the total supply of ICP stays the same, which is great.
However, if the price of ICP went down to 3 XDR, then 33 ICP would have to be minted to reward node providers (100 XDR / 3 = 33). In this case, the total supply of ICP increases by 13, which creates inflation/dilution for ICP holders. In other words, ICP holders collectively accrue a loss of 13 ICP. ICP holders lose money because of changes in the exchange rate.
But let’s take a look at a more extreme case. Let’s say ICP price goes up to 100 XDR ($130) and network usage increases 1,000x (yay adoption!) from 8,000T cycles burned/month currently (I got this estimate from IC dashboard) to 8,000,000T cycles burned/month. New developers flood to the IC and they super-charge their canisters with enough cycles to last for 5 years (other blockchain developers are used to high fees, and 5 years of computation is relatively cheap on the IC, so I think this is not a crazy amount). This is equal to 8,000,000 * 12 * 5 = 480M XDR. They burn 480,000,000 / 100 = 4.8M ICP for these cycles.
Soon after, ICP goes back to the original price of 5 XDR (we’ve seen similar trends in BTC and ETH). New developers lose interest and cycles minting goes back to the original rate. But the same 8,000,000T cycles/month of computation is still being used. This is equal to 8M XDR, or 8,000,000 / 5 = 1.6M ICP per month. If the price stays the same for 5 years, then 96M ICP will be minted to pay node providers, and a much lower amount of ICP will be burned by developers to offset this inflation.
In this example, developers burned 4.8M ICP to pay for computation, but 96M ICP was minted to actually pay for that computation. This is a 91M ICP (18% of total supply) = ~$550M hit that ICP holders collectively took, due to just exchange rate risk. I don’t think this is sustainable in the long run. And although unlikely, this is what might lead to a “death spiral” because the only defence mechanism is minting more ICP.
But what other alternatives do we have, other than minting these ICP tokens?
- we could tell users, I’m sorry, we cannot honour the cycle-to-computation exchange rate right now. You have to use 10T cycles in exchange for 5 XDR worth of computation.
- we could tell node providers, I’m sorry, we cannot pay you the full amount this month. I know you have fixed costs, but please bear with us.
- we could temporarily reduce the capacity of the network. I think this is a nuclear option that will cripple the network. Who decides what subnets will keep running? And this is a temporary measure until the price of ICP increases. But what if the price stays low for a long time? Shutting down part of the network is a bad indicator that will make investors lose trust, and I don’t think price should be expected to rise back up anytime soon.
Any other alternatives we can think of? Either way people will lose trust in the protocol. I’m not debating about the likelihood of this scenario, I’m arguing about the protocol’s design. We are not experiencing an attack on the network. This is just the network not being able to deliver on the promise it sold to users. And this seems to be a design problem: the stability of the network depends on the price of ICP.
The only defence from the DFINITY Team I have seen is, don’t worry, voting reward inflation is a bigger problem right now. They might be right because my scenario resulted in annual inflation of “only” 4%. But might I repeat: this is not really “inflation”. It is a cost that ICP holders must bear because of poor exchange rate hedging.
Maybe we just need to have this discussion: who should pay for canister computation and storage? Should it just be developers, or should it be developers and ICP holders? If we’re ok with ICP holders paying some (or a lot) of the computation at times, then I guess the current mechanism might work. But we just need to make this clear.
Cycles in DeFi
Now let’s consider the fact that cycles is also being used in DeFi on the IC. You can lock 1T cycles to mint 1 XTC, and 1 XTC can be burned to release ~1T cycles. Therefore 1 XTC should always be worth ~1 XDR.
Cycles is very useful for DeFi on the IC because it is native to the IC, making it invulnerable to inter-blockchain and other external effects. If DeFi takes off on the IC, it is very likely that the amount of cycles locked up to create XTC will be orders of magnitude greater than the rest of the cycles supply. While cycles is not technically a stablecoin, it will definitely be used like one. This is dangerous because unlike with a real stablecoin, cycles lacks a mechanism to create arbitrage to keep its price stable.
Currently the price of XDR is 0.20 ICP. If the price of XTC rises to 0.25 ICP (but XDR is still 0.20 ICP), arbitrage traders can simply buy 100 ICP, burn it to create 100 / 0.2 = 500T cycles, lock up cycles to create 500 XTC, and sell 500 XTC for 500 * 0.25 = 125 ICP, for a net profit of 25 ICP. This will cause the price of XTC to fall back down to 0.20 ICP, to keep it pegged to XDR.
On the other hand, if the price of XTC falls, there are no easy arbitrage opportunities. And since the amount of XTC tokens is orders of magnitude above the cycles used for powering canisters, we cannot simply wait for cycles to be burned by canisters to reduce supply. There is no mechanism or incentive to bring XTC back to peg.
XTC price will continue to fall, and DeFi users will panic sell cycles to developers for a big discount. We will now have enough cycles to power the IC for 100 years for 1/10th the price of XDR without having to burn any more ICP. This is a similar problem as in the previous section, only 100x worse. In this scenario the source of income/deflation is completely removed (ICP no longer has to be burned), leaving ICP holders slowly bleeding while having to cover computational costs indefinitely.
Possible solution
The problem with cycles is that ICP holders are exposed to ICP/XDR exchange rate risk as long as there are cycles outstanding.
We need to disincentivise holding cycles. We can simply charge an interest rate for holding cycles, for example 5% annually. High enough to disincentivise/kill XTC/cycles use for DeFi and to prevent developers from creating 5 years worth of cycles. But low enough to allow developers to load up their canisters for ~6-12 months.
The solution can be very simple. When burning ICP → cycles and when paying node providers, we use:
1T cycles = 1 XDR * exp(r * (t_0 - t))
where r is the interest rate (eg. 5% annually → r = 1.62e-9 if t is in seconds), t is current time, and t_0 is the start time when this mechanism goes into effect.
This way cycles is still pegged to XDR, but it is constantly depreciating in value.
Better solution
However, the best solution is to simply get rid of cycles. I think the risks of having cycles greatly outweigh the benefits of using cycles. And cycles is not an essential core feature of the IC.
We can get rid of cycles and instead have users charge up their canisters with pure ICP. We still use the XDR/ICP rate: the ICP in the canisters is burned at a rate determined by the XDR/ICP exchange rate. If the price of ICP rises, ICP in canisters is consumed more slowly. Also, the total amount of ICP consumed by canisters is the total amount of ICP paid to node providers, minus an optional protocol fee.
I would argue that the situation for developers does not change much. Developers already don’t know how much their cycles balances in canisters will last. It could be one year, but if they have a spike in number of users it could be one month. I would also argue that since fees on the IC are much much lower than on other blockchains, developers are not very price sensitive.
To reduce ICP price exposure for developers, we can instead make it easier to automatically reload canisters. For example, users can keep reserves in USDC (or even an XDR-pegged actual stablecoin), which can be automatically converted to ICP to reload canisters.
The situation for node providers stays practically the same, except that their pay depends on network usage. Their pay is based on XDR price, like today.