Node provider rewards are issued monthly in ICP, calculated by applying a 30-day average ICP/XDR rate to a fixed XDR amount which is dependent on the node hardware and its country.
Hence, when the ICP/XDR rate decreases, more ICP is minted for these rewards.
This creates a potential risk of an inflationary spiral. This spiral could occur as follows: a decline in ICP price leads to higher node rewards in ICP, which are then sold, causing a further ICP price decline.
Given ongoing community discussions about this issue, we aim to share our analysis and suggestions for next steps.
Analysis Node provider rewards vs Voting rewards
At current price levels, Node provider rewards make up only 16% of total rewards, compared to Voting rewards.
If the ICP price drops by 50%, this proportion increases to 27%.
If the ICP price drops by 75%, this proportion increases to 43%.
Conclusion: Node provider rewards are currently not the primary contributor to ICP inflation.Their impact becomes substantial only if there are significant further price decreases.
As our analysis shows, Node provider rewards are not currently a primary driver of ICP inflation. However, due to the concerns raised, it is prudent to gather ideas and prepare plans for different ICP/XDR exchange rate scenarios. Specifically, automated stabilization mechanisms could be valuable if the ICP/XDR rate changes significantly.
Short-term
The NNS framework already includes a minimum ICP/XDR exchange rate, called âminimum_icp_xdr_rateâ (set at 1 ICP/XDR), which is part of the NetworkEconomics configuration. Due to a bug, this minimum exchange rate is currently not enforced.
As a short-term fix, we recommend resolving the bug to apply the minimum exchange rate for the calculation of node provider rewards and incorporate this in an upcoming NNS release.
Once this bug is fixed, the minimum_icp_xdr_rate parameter would serve as a tokenomics limit. This would directly address concerns about a potential inflationary spiral by effectively capping the amount of ICP minted for Node Provider rewards. This cap would apply if the ICP/XDR exchange rate fell 60% from todayâs value (between scenario 1 and 2 above)
Mid-term
In parallel, further potential refinements should be reviewed, many of which are already topics of forum discussions. For instance:
Size of Node Population: Assess the current node population and determine the required number and geographic distribution of nodes for adequate network capacity and decentralization.
Reward Mechanism Refinement:
Consider distributing the burden of any reduction in rewards under extreme rate scenarios. For instance, both node provider and voting rewards could be decreased if the ICP/XDR rate drops below a certain level.
Explore mechanisms for tracking deferred node provider rewards for potential future payouts.
Subnet Usage: Consider tying node provider rewards to the actual usage and cycle consumption of individual subnets. This could potentially be coordinated with a review of cycle pricing, which directly impacts cycle consumption.
I think this is a perfectly reasonable course of action to take - ensuring Node Providers are still rewarded, while setting in place the limitations to prevent a death spiral.
Iâm looking forward to seeing how these concepts evolve into a proposal. I appreciate the foundations openness to feedback & critical thinking in this regard.
First of all, thank you to @Accumulating.icp for making enough noise that the Foundation has noticed and addressed this imminent issue. Second, thank you @bjoernek for actually providing a very reasonable solution that addresses the need to reward node providers without sacrificing the entire blockchain. Itâs nice to see the Foundation is willing to take action before we reach a âpoint of no returnâ scenario.
@bjoernek can you explain how a minimum ICP/XDR rate would address the concern of run-away inflation brought on by node provider rewards? If node providers payments are denominated in XDR and dispersed in ICP then the amount of ICP that a node provider receives is calculated by the following:
Rewards = (amount owed in XDR) ( ICP/XDR exchange rate)
If we mean to put an upper bound on the value of the Rewards, how is that achieved by placing a lower bound on the ICP/XDR exchange rate?
We would need to place an upper bound on the ICP/XDR exchange rate. Not a lower bound.
Placing a minimum on ICP/XDR has severe consequences downstream for people purchasing cycles when the price of ICP rises to a point where the true value of cycles falls below that lower bound.
And placing a maximum on ICP/XDR has severe consequences in that itâd result in cycles costs being under valued whenever the true costs of cycles reaches a point in which it exceeds that upper bound.
this is not a short term solution at all. It causes too many hazardous side effects.
@Jesse
I believe your question is related to the notation convention for the ICP/XDR exchange rate.
As of today, the rate stands at 2.22, meaning you need 2.22 XDR to get 1 ICP.
Assume say you are a node provider who is supposed to receive rewards equivalent to 1000 XDR every month.
With todayâs rate, that would convert to 1000 / 2.22 = 450 ICP. However, if the exchange rate drops to 1.50 ICP/XDR, you would receive 1000 / 1.5 = 666.7 ICP instead.
This is why having a floor for the ICP/XDR exchange rate effectively caps the ICP amount (in our example to 1000 ICP).
If we were to assume a worst case scenario, and the ICP price fell by another 60% resulting in the exchange rate cap coming into play (which given the current market conditions, it would not be far out of the realm of possibility), then from there NPâs would start receiving a reduction in their earnings. The risk described in reducing NP rewards has been that it would cause them to go offline. I think it would be appropriate at this point to assess the risk relating to at what point would NP then begin to shutoff due to non-profitability and begin to effect network stability? The NPâs have how much profit built into their operations? It varies from NP to NP but is there a range of estimates and a plan for this eventuality? The mid-term strategies described above would help but there isnât really a timeline for when any of these will be implemented so in the event that the cap comes into play sooner rather than later, there would be some lag before these mid-term solutions are activated.
Thank you very much for your day-to-day work! Many people give their opinion hastily without knowing the number of qualified people analyzing all the variables. Give an idea, ask, analyze, propose, itâs perfect! But many people try to impose something that they thought at home for 1 week. All this will change when the price rises, that is where %50 of the forum posts will decrease.
If i understand you correctly, the notation is misleading as it doesnât follow proper nomenclature. The minimum_icp_xdr_rate variable is actually referring to the XDR/ICP exchange rate. So itâs the XDR/ICP rate that youâd be placing a lower bound on. Not the ICP/XDR exchange rate.
This would still cause issues downstream whenever the true XDR/ICP rate falls below this lower bound. The result would be that cycles costs are subsidized by the entire network even more than it already is.
This is still very haphazard, which speaks to your point that this needs ongoing discussion.
I urge everyone following this topic to consider the solution i propose in this forum post. So far, it is the only proposed solution that addresses the risk of run-away inflation by decentralizing risk while preserving incentives to current and future node providers- and it achieves this while not raising the barrier to entry for future node providers.
Iâm open to hearing other peopleâs recommendations, but i firmly believe that any recommendations should fulfill the following:
1.) takes into account the operation expenses of node providers in a way that doesnât remove all economic incentive for Node Providers to contribute to the network.
2.) mitigates the risk of run-away inflation as a result of node provider rewards dispersals.
3.) mitigates the risk of all other neuron stakers being diluted by rewards paid out to node providers.
4.) Decentralizes risk. Currently, if ICPâs tokenomics breaks down, the result is run-away inflation on the entire NNS. A solution in which the risk is no longer centralized to the NNS, but instead passed onto the Node providers so that risk is decentralized would be optimal.
5.) Refrains from raising the barrier to entry for future node providers looking to contribute to the network.
I donât consider myself very smart, but it seems coherent to think about a treasure pool , which would exchange ICP for stable value in Automatic way with AI through a smart contract when market conditions were favorable and thus prevent harming the price of ICP. From that pool the NP would be rewarded in stable currency
Iâm not opposed to this but there would need to be a funding source established for this treasury. I also think that if this is enacted, it should be done in conjunction with a more comprehensive solution.
If the price of ICP falls below $1.30 USD(1 XDR), node providers will receive less money than they are supposed to receive.
For example, letâs consider one node. If the current ICP/XDR rate is 2.22, the node provider should receive 694.59 ICP.
However, if we set a lower limit for ICP/XDR at 1, then whenever the price of ICP drops below $1.30 USD (1 XDR), the node provider will always receive a maximum of 1542 ICP, regardless of the actual ICP price at that time.
All makes sense apart from tying node provider rewards to actual consumption. Node providers have no control which subnet they are a part of nor do they control how much consumption takes place on their nodes. This design choice would make no sense!
Forgive my ignorance, but what percentage of Nodes are actually âload bearingâ?
Is there a 98% disparity between cycles paid to utilize a subnet vs what that subnet is paid out, or is the network currently 98% oversized in comparison to where it should be (actual useage)?
I just canât seem to figure out why we continuously onboard new Nodes if we donât even have a usecase for them - youâd think if our subnets / nodes were currently overworked, the cycles burnt would reflect that.
It entirely makes sense. If we donât need them at all why are we adding new ones like accumulating.icp has said.
If we want to have it to where anyone can be a node provider at any time then it should just be a fixed rate of icp thatâs allocated to a node reward pool and distributed based on the nodes volume.
But not everybody can be a node provider so there is a barrier of entry. This barrier of entry should be much more strict right now with the current state of the chain with onboarding new nodes. Like a year or two ago it was extremely strict and now you see nodes Beijing added more than ever.
Why is this occurring if we do not need right now? Weâre pretty much just paying off nodes to just sit in a datacenter and do nothing.
So I think itâs justified to pay out nodes that are actually being used and nodes that are not get a smaller amount of rewards.
This is crucial for survival, and Dfinity has to come up with the optimal proposal.
I honestly never expected a problem like this coming up with a great r&d team in switzerland.
If new nodes arenât onboarded, wouldnât that essentially stop decentralizing the protocol? I was thinking the use case for any additional nodes is decentralization.
If decentralization is the goal remove the barrier to entry and let anybody become a node provider and have a fixed amount of icp for every month similar to proof of work but whatever node are used the most get a specific percentage and ones that arenât used at all get nothing.
