The coretime sales pricing model needs to be changed. The price discovery phase with dutch auctions doesn’t make sense as a pricing model. The demand for coretime is not there to justify auctions. It also doesn’t make sense for the quantities of coretime that are being sold compared to the previous parachain auctions.
The ecosystem is slowly starting to align with the vision that polkadot could function as the infrastructure for web3 similar to how AWS functions as infrastructure for web2. If you were building a web2 application would you really want your cloud computing costs to be varied monthly based on dutch auctions? It feels like someone within the polkadot ecosystem has an obsession with these dutch auctions and just wants to be experimental.
Polkadot ought to be selling coretime for as cheap as possible in order to attract developers. This will lead to increased developer activity, network transactions, and meaningful web3 applications. The network should continue to offer coretime as affordable as possible until it becomes oversaturated. At which point, the price of coretime should scale based on demand. A major advantage of the polkadot ecosystem and the upcoming JAM upgrades is that the supply of blockspace / coretime is quantifiable. In other words, we should know approximately when there will be enough transactions within the ecosystem in order to cause network congestion. This fixed supply of blockspace should allow for a pricing model that varies the price of coretime based on demand.
Alternatively, there could be a Pay-As-You-Go (PAYG) pricing model that allows developers to pay for coretime based on usage. This could allow for low upfront costs to build on polkadot even if your dApp fails to get usage. The biggest factor though and what these auctions seem to forget is the entire purpose of agile coretime is to allow for low upfront costs for developers. Costs need to start as low as possible and scale based on demand. Rather than costs starting high in a dutch auction and slowly declining over a period of weeks. Psychologically, these dutch auctions make it look like there is no interest in purchasing coretime. The developers will simply wait weeks for prices to become attractive.
Polkadot has to get people building on the ecosystem first before charging people fees to build on it. I would argue that it might even be reasonable to allow for zero cost coretime for low usage amounts just to get people building. Operating at a loss temporarily in order to onboard developers and saturate the network could be wildly beneficial to the longterm prospects of the ecosystem. The coretime pricing model needs to be thought of in a business perspective. There are tried and tested price models that have worked for similar infrastructure based businesses like AWS or other APIs.
What you expressed here makes a lot of sense and should be widely discussed. If Coretime is presented as a solution for crowdloans, it shouldn’t essentially follow the same model. Starting with a fixed price could be beneficial (though this is something for more experienced experts to evaluate), as a constantly changing cost model doesn’t help developers make reliable cost predictions. Additionally, as a developer, I would prefer to arrive at the marketplace, purchase Coretime right away, and not have to wait.
In any case, as I mentioned, this is something that experts in the field should address, considering whether it’s possible or if there’s a reason behind the current model that I’m not aware of.
Early cores (left side) are priced lower to encourage adoption. The renewal price is identical to the purchase price, providing customers with price stability over time.
As more cores are purchased, the price per core gradually increases. @ewaddicor had slightly different ideas regarding the exact shape of the price curve.
This is On-Demand Coretime and it is already live. Also is On-Demand not a solution to your instant coretime description @lilymendzdev?
Bulk Coretime and On-Demand Coretime serve different purposes and have different pricing models. Between them they offer immense flexibility and in any discussion we’ll need to consider both of them together, rather than talking about only Bulk in isolation as in this discussion.
I’ve posted a reply to the referendum on the other thread as it was older and will continue there. I look forward to the next iteration of the pricing model!
I don’t know why an auction model is used for a product with these characteristics. We must not think that we are also inventing the wheel with this. Imagine a telephone company that offers data and voice products for using that telephone network. All this is invented. We just have to talk to experts on this topic.
