Thoughts on Governance and Cycles

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 :slight_smile: )

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.

20 Likes

Would you mind sharing your thoughts on this more? I do not mean to jump in… I just would like clarification so I understand it moving forward. Btw I really liked your writing style/ abilities/ structure.

3 Likes

Hey Johnathan,

My point is that with the current mechanism ICP holders have to at times subsidise computation costs. We are actually doing this right now. We are minting and diluting ICP to very generously pay node providers.

This is not all bad. For example Bitcoin mints new BTC to pay to miners. So our current mechanism might work: developers pay a stable rate and ICP holders pay for any price differences. We still need to get rid of cycles use in DeFi. And we need to make it clear to ICP holders that they have ICP/XDR exchange rate risk.

So for example if I was a large ICP investor, I would also have to buy a lot of XDR to hedge my position and avoid this exchange rate risk.

3 Likes

Great. It would be nice to see more community members chime in.

2 Likes

But what happen to the future of xtc and cycle holder that bought specifically for Defi if one day cycle be no longer a computing money for the Icp? Isn’t that similar to a rug?

I am sure you could have a better resolution than that. Perhaps the foundation could buy all of it back.

1 Like

Thank you, now could you specify who ICP holders are? Meaning stakeholders, or just wallet liquid/ cycle use holders?

Then, expand on why you feel a large investor needs to hedge. I don’t mean to bug you. Trying to understand the rationale. Might be missing/ misunderstanding something. Thanks

Hey Rudy

Sorry to this take away from topic, but are you still working on Enoki - Whats the latest?

I was really impressed with this project from Supernova but havent heard any updates. Theres no socials etc?

Yes, exactly. Or we could have a hybrid period where you cannot mint any more cycles, but you can use either cycles or ICP for computation

2 Likes

By ICP holders I mean everyone who owns ICP, anywhere. When we mint additional ICP to pay to node providers, this inflation affects everyone who owns ICP.

Let’s say you work at a company that invests in crypto and want to pitch ICP to your coworkers. You do your research. You create forecasts about how many users and developers will use ICP in the future, you estimate how these metrics will affect the price, and you arrive at an estimated total valuation of ICP, similar to how they evaluate equities right now (equity analyst reports and their results). You think that the total value of ICP (market cap) should be $5B right now. The total supply of ICP is about 488M, so this gives you a target price of $5B/488M = $10.25.

Now let’s consider my extreme example above where ICP price jumps up and then back down, resulting in developers burning only 4.8M ICP to pay for computation and 96M minted to pay for that same computation. This will increase the total supply of ICP to 488M - 4.8M + 96M = 579M. You still think the total value of ICP should be $5B because not much has changed with your estimates. This was a weird and irrational price jump, but the rest of the network parameters and usage are very close to what you expected. So now the target price is $5B/579M = $8.64. Each unit of ICP is worth less because it was diluted.

As an investor, you don’t like this. Temporary price movements affect the total valuation of the network. If you are a long-term investor, you don’t care what the short-term price of a token is. You only care about the price 8 years from now. But in the case of ICP, short-term price volatility can have big impacts on your investment.

To avoid this, you can hedge. You need to sell ICP+buy XDR when developers burn ICP to create cycles, and you need to buy ICP+sell XDR when cycles are burned. Let’s see what this would look like with my same example:

  • Price of ICP is 5 XDR ($6.5). You buy 10M ICP.
  • Price of ICP jumps to 100 XDR. Developers mint 480M XDR worth of cycles. You hedge by selling 96K ICP and buying 9.6M XDR with these proceeds (you own 10M / 488M = 2% of all ICP. 480M XDR * 2% = 9.6M XDR. And 9.6M XDR = 9.6M / 100 = 96K ICP).
  • Price of ICP goes back down to 5 XDR. As developers burn cycles, you undo your hedge position. Eventually you sell all your 9.6M XDR for 1.9M ICP (9.6M XDR / 5 = 1.9M ICP). Your position is now 10M - 96K + 1.9M = 11.8 ICP

This way you are never diluted. The rest of the ICP holders are diluted, but your position increases a bit to offset this dilution. If on the other hand the price of ICP increases steadily for a long time, you will not make as much money. But at least your position is not subject to ICP/XDR exchange rate risk.

2 Likes

Hey Sal,

The next step for Enoki is migrating from our proof-of-concept test token to ICRC-1. However, the main focus of our DEX is scalability, specifically scaling transaction throughput. For that we need to work on an extension method to ICRC-1 that focuses on scaling. We already have an implementation of this using sharding, but this needs to be a community effort and there has to be a community standard (otherwise we’d end up having to wrap/unwrap tokens when you deposit/withdraw from the DEX, which I think is poor UX. And this would also create a bottleneck that negates our scalability). These scaling extension community discussions are expected to happen in the next few months, after other major extensions (approve/transferFrom, notify, and one more I’m forgetting) have been discussed for ICRC-1.

In the meantime we’ve been learning more about the ecosystem, since we’re relatively new to the IC. There’s a lot to love about it. We did have several concerns though, which is why I made this post.

Sorry, we don’t have any active socials and we do currently have other full-time jobs. But when the time is right and we decide to start ramping up our development we’ll definitely send out an announcement.

4 Likes

Thanks for the update Rudy. Looking forward to hearing on new developments

Hi @rudy, many thanks for sharing your detailed thoughts on governance and cycles. This is a very interesting read!

In my first reply, I will concentrate on your analysis & concerns on cycles, to which you devoted the biggest part of your article. Feedback on other sections will follow later.

Problem statement/raised concerns on cycles (the way I understand it)

  • Buying a lot cycles in advance (e.g. a sufficient amount for 4 years for the whole IC), via burning ICP at a time when the ICP price is high (e.g. 100 XDR), leads to high cycle reserve which at a subsequent period where the ICP is much lower (e.g. 5 XDR), requires a lot more ICP to be minted in order to pay node providers (e.g. in your example 20x times more = 100/5). This leads to high inflation.
  • In other words: If participants decide to buy a lot of cycles in reserve, the balance of ICP burned for cycles vs ICP minted is subject to ICP/XDR exchange rate risk.

Comments on that concern

First of all, I agree with your analysis of the presented scenario. If participants and the ICP price behave exactly in the way you describe it, then indeed this would lead to very high inflation.

Now let me explain why I believe that it is not very likely that such a scenario will occur.

Economic incentives for developers and opportunity costs

  • In XDR terms developers do not face any exchange rate risk when buying cycles. They know that 1tn cycles will correspond to 1 XDR, regardless of the level of the ICP price.
  • Thus, there is no economic incentive to buy cycles for many years in advance.
  • Furthermore, in case that developers have a big amount of ICP reserves which they would like to earmark for future computations they have a strong economic incentive to do one of the following:
    • Option 1: Invest within the IC
      • If developers are not concerned about the ICP/XDR rate (e.g. because they have a neutral or bullish outlook on the ICP price) they can stake their ICP reserve and use voting rewards to buy future cycles.
      • Given a yearly reward rate of 20% for long-term stakers on the IC this can be an attractive option.
    • Option 2: Invest outside of the IC
      • If developers are concerned about the ICP/XDR rate or if they simply would like to hedge their ICP/XDR rate risk, they could sell the ICP reserve and invest the received cash at the risk free rate.
      • For example, the 3 month US treasury bill rate is 2.8% at the moment (and of course you could also do a risk-free investment in XDR, completely eliminating the exchange rate risk).
      • In your scenario, where developers invest 480mn XDR this would lead to annual profit of 13.4mn. This is much better compared to buying a lot of cycles in advance and receiving nothing.
      • In other words, idle cycles balances represent an opportunity cost in terms of lost interest compared to a risk-free investment of cash.

Timing of cycle purchases

  • There are many different dev teams on the IC and the ecosystem is growing rapidly.
  • As a consequence, cycle purchases will be spread across time (potentially there might be some periodic patterns in activity and cycle purchases).
  • Thus, a spiky behavior with all devs buying huge amounts of cycles at a particular point in time does not seem likely.

Reaction of market price

  • If we nevertheless assume that for some reason, developers purchase a lot of cycles at the same time, then this would reduce the supply of ICP and thus have a positive impact on the ICP price.
  • Thus a subsequent steep price decline, as assumed in the scenario, does not seem likely.

Concluding thoughts

  • For the reasons described above, a purchase of a huge amount of cycles with subsequent high inflation in a low price environment is a very unlikely scenario.
  • In particular, buying (big) amounts of cycles creates opportunity costs in terms of lost interest and thus is not in the economic interest of developers/participants.
  • Thus, a disincentive to holding cycles already exists and thus it is not fully clear to me why charging an interest on cycle holding is required → I would be very interested to hear your thoughts on these counter arguments.
  • As a side comment: The other proposed enhancement of dropping cycles all together and charging canisters with ICP would expose developers to the full ICP exchange rate risk and thus does not seem desirable.
  • When it comes to the potential usage of cycles in DeFi applications, I have to think further about potential implications to system stability.
  • Overall, I think that the key focus of our current efforts should be on growing the IC ecosystem so that we come to a point where the nodes are fully used and ICP burning offsets and eventually exceeds ICP minting for node providers.
9 Likes

Brilliant explanation

This is a great article but it seems cycles burned aren’t rewarded to node providers at a 1:1 ICP conversion rate.

Node providers apparently get a flat rate.

Phew! I freaked out there for a second, thinking ICP could end up like Luna.

Other than that, you’ve made great point :slight_smile:

2 Likes

Yeah that would definitely be a problem.

Hi @bjoernek , I really appreciate your reply. I completely agree with you: I think that the first scenario I described is very very unlikely. And even if it does occur, I think we have a good chance to recover without any catastrophic consequences.

However, I think there is a difference between having a system that is very unlikely to break vs having a system that is engineered to be stable through strong incentive mechanisms. Maybe it would just help me sleep better, and maybe in a practical sense there is no difference.

But by far my biggest concern is cycles use in DeFi. A lot of DeFi users and developers want to leverage the **** out of everything (examples 1 and 2), and I’m worried that this might produce an extreme oversupply of cycles.

Just to address a few of your points:

Well, the cost of computation and storage is very cheap, so I don’t think developers are likely thinking about opportunity costs and lost interest income because we are talking about maybe $100 to power a group of canisters for a few years? I was just thinking that as a developer I want to load my canister and forget about it for a while. There is no economic disincentive to prevent this (my example was 480M XDR, so this would be about 6M developers doing this - I don’t know how likely this is).

First, I don’t think the current disincentive is strong enough. Some people still keep money under their mattresses, so I don’t think we should count on everyone acting rationally, especially if the incentives are a little weak. Also, I think (and hope) the 20% reward rate for long-term ICP stakers will eventually decrease, making these disincentives weaker. And an interest rate of ~3% outside of the IC might not be attractive enough to the average developer to motivate them to put their money in an investment account. These are developers for the most part after all, and not investors. What proportion of the average person’s bank accounts is in a savings or investment account, vs in a checking account? I’m just arguing that the incentives could be made a little stronger, and charging an interest rate is a great disincentive because people do not like losing money, not even a little bit of interest.

Second, and most importantly, charging an interest rate would make sure cycles is not used irresponsibly in DeFi.

Yes, but since computation is so cheap this should not be a huge problem. And we can also automate the canister reloading process. We can create a dApp where developers hold some token (USDC, BTC, etc) earning an interest, and this token is automatically converted to ICP and used to reload canisters with low balances.

And if we have ICP balances in canisters burn depending on the ICP/XDR exchange rate (if ICP price rises relative to XDR, ICP is burned more slowly), this would almost completely remove ICP exchange rate risk for developers.

I agree. I’m just worried that ICP burning is variable/random, while ICP minting is a predefined amount per node. Do you think we’ll get to a point where we can add and remove nodes (and stop paying node providers) on demand as network usage changes? But even if we do this we won’t be able to match ICP burning with ICP minting rates because network usage is proportional to cycles burned, not ICP burned. This is why I don’t see a better solution than to get rid of cycles altogether.

Actually, this is what I’m worried about. We have to pay node providers a flat rate, even if the network was not used, and even if no ICP/cycles was burned.

I don’t think ICP could end up like Luna, though. In the case of Luna, if UST lost its peg you had to buy UST and burn it to mint LUNA. If the price of LUNA was already low, this extra minting will cause inflation and drive the price even lower, causing a death spiral. This is because LUNA was used to defend the UST peg.

In the case of ICP, if cycles loses its “peg”, there’s really nothing to do. We just have to wait until cycles is burned, which reduces its supply and hopefully restores the peg. ICP is unaffected by this because you can’t mint more ICP at will as a regular user. ICP is not used to defend the cycles “peg”.

What I do think could potentially be a problem is that we end up with way too many cycles in circulation. This might lead to cycles being almost worthless. ICP would be ok, but everyone who minted cycles might lose money.

3 Likes

we currently have a protocol reward system based on a maturity % that is acquired depending on the dissolution time and the participation in the governance, at the moment we want to make this maturity liquid, we must split a new neurone where after going through a 7-day dissolution process the final liquidity will be modulated based on the price of the PCI.

The problem that this protocol entails in the current state of the IC ecosystem is that it makes it highly inflationary due to the great divergence between the newly minted ICP and the burned ICP.

The solution I propose would be simple and logical. At the moment of wanting to make maturity liquid, in the process of modulation in the dissolution of the new neuron, do not do it based on the ICP market price, instead do it based on a public numerical index that represents the amount of ICP burned or transformed into cycles.
The greater the activity of development and ICP burned, the greater the index and the greater the final liquidity of that new neuron.

With this system we encourage long-term staking, since the greater the time, the greater the growth in the IC ecosystem and the greater the rate of ICP burned. Consequently, greater reward incentives will be obtained by dissolving the maturity with the highest ICP burn rate.

In addition, in this way , the dissolution of maturity in the short and medium term is discouraged, thus slowing down the new Minting of ICP and inflation

higher growth = higher ICP burned = higher ICP minted for rewards and proportionally vice versa if growth is reversed. In this way, we reward governance by encouraging the growth of the ecosystem in the medium and long term and dissuade short-term minting that generates hyperinflation.