# Node Provider Inflation Spiral

At 2\$, we’re facing 2.4% annual inflation from Node Providers.

At 1.5\$, we’re facing 3.2% annual inflation from Node Providers.

At 1\$, we’re facing 4.9% annual inflation from Node Providers.

At 0.25\$, we’re facing 19.6% annual inflation from Node Providers.

I think the “magic number” queuing an inflation spiral is going to be somewhere around 1\$.

10 Likes

Interesting Math!

Might have missed this part but are we calculating under the assumption of static volume?

A sudden shift in volume positive or negative (negative is my current bias) could very much change the landscape rapidly

What I’m personally interested in is the timeline

Trying to do this for fun ATM, but I’d like to see the gradient of the chart and the rate of change of the gradient to see where at current rate, the price would go and the timeline for it

^above would probably be grossly inaccurate due to the fast paced and changing environment but assuming some static variable would allow a picture of the worst case atleast

Incase anyone has the question “who cares about price?” The concern is more about ICP sustainability than “investments”

If we’re able to sustain ICP for multiple years regardless of price action, that would give builders some reassurance

7 Likes

With those points aside, I’m curious about your stance on the Inflationary Spiral in correlation to algorithmic minting of \$ICP for node providers.

I’ll start with this question first, since it’s most likely top of everyone’s mind. I calculate that node providers provided 377k of the ICP that went to exchanges in August (580k ICP x 65%). That’s a little more than 10% of the 3.752M ICP that I think went to exchanges in August (calculated by examining hot wallet account behavior). The vast majority (~70%) of that 3.752M was ICP that had previously dissolved off the NNS. From that perspective, I’m not so concerned over node provider rewards at this time, however I agree it’s worth keeping an eye on and we should be willing to act fast should the data tell us to. Just my two cents.

this definitely would have been easier than manually adding the figures (which is most likely what resulted in my inaccuracy)

The dashboard page is good for high level, but you would have had to look at each NP wallet to get to a % sent to exchanges (as you did). As someone who has done the same analysis, I feel your pain It’s brute work tracing ICP movements. Kudos for doing it!

This would explain why on the block explorer it appears as though the Node Providers have chosen to send rewards to an exchange upon receiving them.

When ICP is sent to an exchange it (almost) always goes to an “client exchange wallet” which tells the exchange which of their clients sent them the ICP. They then (again, almost) always sweep that ICP up to their hot wallet. This behavior helps in analysis because it’s easy to spot when ICP is sent to exchanges.

Here’s the hot wallets for exchanges that I feel confident about

Account Name Ledger Account
Binance 1 d3e13d4777e22367532053190b6c6ccf57444a61337e996242b1abfb52cf92c8
Binance 2 220c3a33f90601896e26f76fa619fe288742df1fa75426edfaf759d39f2455a5
Coinbase 1 4dfa940def17f1427ae47378c440f10185867677109a02bc8374fc25b9dee8af
Coinbase 2 a6ed987d89796f921c8a49d275ec7c9aa04e75a8fc8cd2dbaa5da799f0215ab0
Coinbase 4 660b1680dafeedaa68c1f1f4cf8af42ed1dfb8564646efe935a2b9a48528b605
Coinbase 5 dd15f3040edab88d2e277f9d2fa5cc11616ebf1442279092e37924ab7cce8a74
Coinbase 6 4878d23a09b554157b31323004e1cc053567671426ca4eec7b7e835db607b965
Gate 1 8fe706db7b08f957a15199e07761039a7718937aabcc0fe48bc380a4daf9afb0
Kraken 1 040834c30cdf5d7a13aae8b57d94ae2d07eefe2bc3edd8cf88298730857ac2eb
Unknown 1 acd76fff0536f863d9dd4b326a1435466f82305758b4b1b4f62ff9fa81c14073

There’s a bunch of cold wallets, but they get complicated and some I’m less confident about. However, here is Binance’s cold wallet, which I feel very confident about: 609d3e1e45103a82adc97d4f88c51f78dedb25701e8e51e8c4fec53448aadc29

Let me know how I can further help

10 Likes

I completely agree that in the immediate short term future, this is a non issue.

The primary concern is if we continue upon our current trajectory, without a failsafe in place - amidst an ever-volatile market.

While it’s true this only occurs on a monthly basis - it only takes one month of bad timing to start a landslide that will be very hard to clean up.

I’ve been considering a few ways to “solve” this, and while I don’t think any are going to completely solve the problem, I think it’d be good to start the conversation:

1. Pay Node Providers in a defined amount of \$ICP, over compensate in the short term, introduce halvenings to prevent over compensation longterm.

2. Pay Node Providers with Cycles burnt on their subnet.

3. Define a reward pool for Node Providers, similar to staking rewards, in which Node Providers equally split depending on contribution.

Fair enough - much appreciated ser!

Thank you for the clarification here as well I will have to look out for this behaviour in the future when doing analysis’.

Much appreciated on the list of wallets - I will index these within the provided google sheet!

5 Likes

I believe for this topic might be convenient checking also previous discussions:

I have also a strong feeling that via a proposal the number of ICP that can be minted as Node Provider Rewards was limited (to prevent inflation spiral) but didn’t find it so far (I think @diegop was involved…?).

### Update: just found it

• Proposal: 64141 - ICP Dashboard
• as current monthly total Node Provider Rewards are higher I guess something was changed in between as the proposal (monthly limitation to 100k ICP) passed
• or it’s limitation per provider so we’re still `safe`
3 Likes

Thank you for providing this! If fine tuned, this would definitely be the type of “fail safe” that would prevent a “TERRA/LUNA event”.

With that being said, I’m curious for further clarification upon this proposal:

While I recognize it says each Node Provider is capped at 100k ICP monthly, I’m curious if this applies to Nodes or the Node Providers themselves. Some Node Providers host dozens of nodes, and are already running extremely close to this 100k hard cap.

However, based off my math, with this hard cap in place, the maximum monthly inflation should be ~9.6M ICP (assuming the proposal is correct in categorizing Node Providers).

Ironically, this hard cap actually results in more extreme inflation than where we stopped (0.25\$) within the inflation extrapolation model.

7 Likes

I’ve been considering a few ways to “solve” this, and while I don’t think any are going to completely solve the problem, I think it’d be good to start the conversation:

There’s a lot of wisdom in this statement. I agree that it is prudent to discuss this potential problem and identify potential solutions should we (the NNS) begin to worry about the potential for a landslide.

I haven’t invested much thought or research into how to solve this potential issue (only how to identify if it is an issue) so I don’t have much to say in regards to suggested resolutions should NP rewards get out of hand. However, I’ll say it’s certainly worth evaluating options and getting consensus around one or two so that the NNS could act fast should the need arise.

I’ll flag this thread with the teams that handle NP rewards within DFINITY so they can add their thoughts. In addition, I hope the community will follow in @Accumulating.icp’s lead and also brainstorm and discuss ideas.

8 Likes

Hello #ICPeople

Could each node should spin up it’s own 8year neuron automaticly and a percentage off the monthly rewards should be added to it every pay out so it could become more self sustainable and maybe even more profitable over the long term when price off icp grows also imo it would fair if all contributors off the inflation would give in a bit just my thoughts what do you guys think about it

4 Likes

I think this is a creative idea that would foster a stronger relationship & dependence between Node Providers & the blockchain as a whole. It would definitely amplify the “skin in the game” aspect of it, ensuring a portion of rewards are staked to accrue further interest.

With that being said, I believe there’d be a couple issues implementing this:

Primarily, DFINITY is vocally opposed to Canister Controlled Neurons - actively stating they will do what is in their power to circumvent the function as they don’t believe it should exist. This has been showcased numerous times, most notably within the is_self_authenticating function.

Secondarily, I think this has the potential to offer a double edged blade. If it is an indefinitely non-dissolving neuron, I could see the benefit in reduction of shortterm inflation in exchange for minimal long term inflation. Alternatively, if it has the potential to be unlocked, or even sold, via ID Geek, this drastically reduces the effectiveness. Unfortunately, we currently do not have this functionality (indefinitely locked neurons) available to us - so this is something that would require further development.

With that being said, I’d agree that neuron’s are a unique solution to inflation to be explored - doubling as an income source over the long term, as DFINITY has shown.

4 Likes

There’s only two feasible solutions that I can think of:

1.) Some of the node providers pause operations, thereby lowering the amount of \$ICP needed to pay node providers.

2.) Someone, (either the community, DFINITY, or a combination of the two) come up with the funds to pay the node providers. And their payments would need to be dispersed in a currency other than \$ICP so that node providers don’t just add to the sell pressure when they sell the currency to cover costs. ckBTC would be the best candidate in this case. It’s built on the IC and would be easy to make a protocol that collects the funds from the IC community in a way that’s transparent and auditable.

If the inflation rate gets to a point where it’s out of hand, we’ll probably have to implement some combination of the two solutions i just listed. Unless someone has a better solution.

3 Likes

To reduce inflation reward distribution could be reduced by estimated monthly neuron interest until the reward was completely sustained by the neuron. So the only full reward payment would be the node providers first payment. Afterwards rewards would scale down based on interest accrued monthly. Reward payments would cease completely when the neuron reaches the ability to produce the max hard cap reward regardless of new nodes added etc.

That said node providers will always need x ICP to operate sustainably. So the percentage allotment to neuron should not reduce liquid reward below x. This will be of more importance for the first payment in a schedule like this as once interest begins generating x can come from both rewards and neuron.

2 Likes

How do you guys come up with these complicated solutions.

we could just pay them a fixed rate of icp like every single other blockchain.

We don’t need to reinvent the wheel.

3 Likes

### Multicurrency Reward Pool

In line with your second proposition, why not establish a multicurrency reward pool where contributions could come from ICP holders and possibly even external financial systems interested in sustaining the ICP ecosystem? This pool could be auditable and transparently managed by smart contracts. ckBTC, as you mentioned, could serve as an apt candidate for disbursement.

### Staggered Sell-off Lock

Instead of doling out ICP rewards that can be instantaneously liquidated, enforce a time-based lock on the ability to sell off the rewarded tokens. The duration of this lock could be inversely proportional to the stability of the ICP value. In times of high volatility, the lock extends, thus discouraging sell-offs and reducing market pressure. This idea could be further nuanced by applying a decay function to the lock period, thereby allowing gradual releases that don’t shock the market.

4 Likes

I completely agree with @Accumulating.icp

We should come up with a solution as soon as we can instead of waiting for the situation to get more concerning . Market forces more often than not are smarter than we think. If icp price gets to a point where we start to be concerned about this issue, that’s prolly already too late . Price goes to 0 and it’s all over .

I really hope the team can brainstorm different ways e.g. set strict limits on node rewards , or pay them in a currency other than fiat , etc. to get this resolved in the short term . Only in that way can we remove all the concerns we have and market forces don’t have a chance either .

3 Likes

What happened to proof of useful work that we where brandishing?

@alejandrade , The problem with paying a fixed price in \$ICP is that node providers for the IC are data centers with overhead costs that must be covered in order for them to Provide reliable compute power. Other blockchains can pay a fixed price to node providers as rewards because they have node hardware that someone can set up in their basements if necessary. The cost of operation for a data center vs that of a basement node are vastly different. Paying a data center a fixed amount of ICP would result in all of the node providers having to cease operations all at once when the price of ICP drops below a certain threshold.

I’ll give an example of what i mean:
Let’s say 1 \$ICP = \$10 USD and it costs \$10,000 per month to operate a data center. We agree to pay the node providers a fixed rate of 1500 \$ICP per month. The first month, the node providers would make enough to cover their overhead costs and take profits.

The next month, the price of \$ICP drops to \$3 USD. We pay the node providers the agreed upon price of 1500 \$ICP. This month, they’d only earn \$4500 USD. This would mean they’re \$5,500 short of what they need to run operations- forcing them to shut down operations.

Now imagine all of the IC’s data centers having this issue at the same time. ICP would literally be inoperable over night.

Paying Node providers a fixed amount of ICP every month is not a solution. In fact, it’d be catastrophic.

4 Likes

The problem is that they are getting paid in cash value no matter if they are working or not. This is another problem caused by trying to reinvent the wheel.

This problem has been solved, proof of stake exists.

It should be a minimum amount of ICP staked to be able to host a node and payment should be either fixed return like POS or proof of useful work.

And some node providers will not be profitable while others will be. Some will make more money then others all this is ok.

3 Likes

Another alternative could be something similar to the neurons fund. All neurons pay maturity to a fund that distributes to providers accordingly. The current node provider rewards could be sent to governance so the current interest would be the same. To reduce inflation the NP reward aspect to governance would need to diminish over time. There would also be a need to increase the NP reward aspect each time a node provider would have normally had an increase in rewards up to the max allocation per NP. Failure to do so would lower % yield each time an NP was onboarded or added new nodes. Which may in turn promote governors to turn down new NP requests. Modulation could be applied here in such a way that during times when the network needs expansion and more nodes the reward incentive to the governance pool is higher(resulting in neurons gaining % yield) than at times when there is less of a need and thus less of a reward(which results in neurons paying to add new nodes).

3 Likes

Hey @Kyle_Langham (or anyone else) are there any contractual agreements with node providers that would limit making changes to their payouts?

Also, developer grants are paid in fiat equivalents as well. Hence, that funding is paid with higher amounts of ICP as ICP price goes down just like node providers. Even if we are not minting new tokens for developer grants, it seems likely that most of those payouts are adding to sell pressure. What is the scale of developer grants relative to node providers? Should it be of similar concern? I suspect most people would not advocate for reducing payouts for developer grants. Hence, it seems fair to bring it up in the context of discussions for reducing rewards to node providers. Do we have the stomach to reduce both or is there good justification for only considering changes to one?

Of all the ideas I’ve heard so far, I like the one introduced by @Cryptobaasnl the most. Specifically this part…

Using this approach, the total node provider rewards wouldn’t have to be reduced. Instead, a percentage would be “topped up” into their own 8YG neuron. This seems easy to implement into the NNS since all it requires is knowing the account ID and neuron ID. Anybody can top up any neuron with this information and it seems plausible to enable node providers to provide this information for use by the NNS. This approach would ensure there is very little sell pressure from the fraction of the rewards that get topped up into a node providers neuron. This seems like a preferable alternative to a forced reduction in the total payments that they are expecting.

I personally would like to hear from node providers on this topic. Of course nobody wins if price goes down below a certain point, so it seems reasonable to consider backup plans.

Hey @Accumulating.icp, I also want to say that you have done a fantastic job presenting this topic and leading the deliberation. Keep up the good work.

6 Likes

Yes! A combination of neuron rewards, a reward pool funded by donations from the those who have a vested interest in the network, multicurrency rewards (perhaps only ICP, ckBTC, and later ckETH), and direct ICP minting to fill in the gaps could provide the sustainability needed to prevent an inflationary death spiral no matter how low the price sinks.

2 Likes