Handling of Node Provider rewards

Thank you for explaining this.

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.

5 Likes