Community Proposal: Assessing node inflation based on token price

Onboarding more nodes only when actual compute and storage demand (ICP burn rate in canisters) approaches the 80%-90% of utilization, of all available capacity, will be best, IMHO. Because it’ll halt infinite printing of ICP that gets simply sold on the market by node providers who have to pay real cash to datacenters for hosting.

Someone has to pay for all these running servers, and if providers are given ICP, then all ICP holders together are paying for the hosting prices in the datacenters, even if they don’t know it (price of their holdings goes down proportionally to how much $$$ was spent on running the servers).

It’s like the world had to pay for US stimulus checks and all the printed $. Someone had to lose purchasing power proportional to the amount of injected dollars to the circulation (and same with Euro unfortunately :sweat:).

Growing number of nodes, without waiting for demand, means someone will need to pay the bills, but what are the options except devaluing the ICP asset proportionally? Who else has enough $ in reserves, to pay all the bills of all nodes, until demand for cycles catch up with provided capacity?

Really interesting question, I wonder what is the official plan by the foundation? To let the ICP market absorb all the hosting costs? what about nodes growth rate, it can really kill the project if ICP keeps trending toward pricing of 0.1$, which is inevitable with current model of minting the token for all running nodes, while not enough capacity is utilized (I guess if at least 50% will be utilized, it’ll keep price stable, as someone picks up the tokens which node providers sell, correct?).

1 Like

fast growth of nodes that join the network will not be an issue in a large and functioning final version of the project where at least 1% of the internet as we know it, runs on IC. It’ll have enough dApps which require compute power and burn cycles, to sponsor at least some number of always active nodes (and node providers will not be joining when rewards are getting lower than expected).
Hmm, the stable rewards level for all nodes, seems like a weak point, it easily will burn through all market cap of ICP and we all end up simply paying hosting bills (by holding ICP). Doesn’t seem like a good idea unless the foundation has enough cash reserves to keep the token alive for a year or two while dApp ecosystem accelerates (by sweeping the floor, buying all tokens that node providers definitely sell, because they have to pay bills, does Dfinity buy any ICP at the moment?).

But in current “incubation” stage, I don’t see any way to fix it apart of centralized control of joining nodes, plus preferably a marketing effort to rehabilitate the brand in the eyes of broader community, which mostly thinks “it was a pump and dump scam” because there’s not enough information about the technology reaching their Twitter feeds/etc’. I’d run some free bootcamp webinars for IC coding, onboarding more developers, and run ads on youtube (targeted at web3 dev topics) to bring people into the bootcamps. They all will start building stuff, some will also bring more capital into the ecosystem, probably.

what about a multiplier introduction, that rewards node providers with “base” pay that covers some of the expenses of running a server (it should really be at most equal to 100% of the monthly average hosting costs in the selected location. the server hardware should be investment by the operators, like in any other PoW, with the chances of having their rewards grow in value if the ecosystem usage grows) but anything beyond that only depends of how busy the global network was. Let’s say utilization of all IC was 15% on average during the month, it means all node providers get ICP bonus of 15% on top of the base pay. But in this case, can node providers fake activity in the network by botting the dApps and burning cycles of the developers, in order to bump activity numbers?
If it can be faked, then it’s bad idea. but if not, then it’ll also make node operators try to promote the project on every corner, and shill it to developers of dApps, which is good :slight_smile: