Initial Coretime Pricing

With regards to Kusama, you may be correct and this is something we should be mindful of. It does seem a bit disproportional from Polkadot if we look at the cost of locking DOT for parachains on Polkadot vs the cost of locking KSM for parachains on KSM. @erin Perhaps we need a more friendly approach on Kusama?

Also @jelliedowl, the price does adjust month to month, so if the offered cores don’t meet demand the price will drop for the following month’s sales. You can play around with this using Lastic’s Coretime Price Simulator.

There will be a system called “Coretime credits” but I’m not sure how they will be distributed. Maybe @bkchr could shed some light on this?

Took me a while to find too. Once you click “reply” there’s a little quote bubble in the upper-left of the toolbar.

1 Like

Aha! I was using block quotes before - thanks!

And all else is good - ultimately, it’s all part of iterating to the correct answer.

1 Like

You can take this part of the equation for Polkadot and change the expected weight percentage of the block as a variable. The current median for Kusama blocks is also 1.8%, so this can be tweaked anywhere from 1.8%-100% to find a value. This would mean going with the validator fee calculation, unless the average of the infrastructure calculation and the validator fee calculation is used. For Kusama using the median 1.8% results in .662 KSM (without locking opportunity cost discount) or .66 KSM (with discount). The average block weight is 13% (as there is quite a bit of variability over chains) which would result in 4.41 KSM without discount or 4.39 KSM with discount.

I should note, for this calculation I used the current average of Kusama validator rewards of .91 KSM per era/3.64 KSM a day rather than my estimate of 2 KSM in the original post (the rest of the numbers were confirmed besides this one - I didn’t have it until today).


I see some of you doing all these formulas and other methods to figure out core time pricing. But maybe you should look at it differently. Think in a business perspective…Dot is NOT the only blockchain out there there are tons of them and they are all competing and all of them have a suite of similar products. How do new businesses typically lure new customers in amidst all the competition? They incentivise!!! Core time price should imho undercut the cost of whatever it costs to establish your average L1 on any of the popular platforms. On top of that there should be discounts for projects that buy in bulk. Maybe even free technical assistance in getting setup. THIS WILL BRING PRODUCTS TO POLKADOT!!! Not related to Coretime but dot holders NEED to be incentivised as well…staking alone isn’t enough. Projects should be encouraged to do air drops…solana, avalanche, cosmos etc. are killing dot because of all those airdrops and incentives. While dot still sitting on it’s hands and watching the marketcap get smaller and smaller. Heck maybe projects could get a discount on coretime if they agree to airdrop dot holders. But something NEEDS to change to get Polkadot back on track!!!


@phillux Some discussion on the lead-in factor here. We lean towards keeping it at 2.

Bulk coretime can be purchased up to 28 days in advance, and bulk renewals are capped within a percentage of the previous purchase price.

Need to take this into consideration from the Polkadot Agile Coretime website. Do we know what this percentage will be?

1 Like

Let’s start on Kusama cheap with 1 KSM (~50 USD) and let chaos ensue. Then gather additional data points from that.

A question that also determines price is how many cores there will be available for bulk coretime. Do we have an answer for that already?

We could do that if lead_in is high enough, but on the flip side one major point of Agile Coretime is to improve allocation efficiency. We want to encourage core sharing via secondary markets. If your application does not need a full block every 6s, you should also not use those system resources, but leave them to others, resulting in more resources being available for everybody.

My ideal eventual usage pattern would be for low-volume parachains to bulk order a reasonable amount of coretime to account for the actual block space they need on average. E.g. one block every 30s or even less, then UIs can either soft confirm actions once a transaction is in the mempool, or even build smaller blocks which will be combined into one for eventual inclusion on the relay chain, providing low latency for users, in the case of “low amount” local (non cross-chain) transactions.

To account for fast “full confirmation” needs, e.g. because a transaction moved a significant amount of funds or because a cross chain action (XCM) was triggered, the chain could order an on-demand core to provide low latency to users even in those cases.

Applications could even let the user choose, fast confirmation for XX fees, slow 30s confirmation with xx fees, where xx is obviously less than XX.

I think starting too cheaply injects lots of volatility in and we actually learn less from the process, unless we aim to use the same high-volatility strategy with polkadot. I still think that our absolute best guess of a reasonable initial price combined with a conservative pricing model is the best approach to start off.
I think the low price approach would work well if we had lots of cores and lots of teams off lease, but with our conditions I think it could be a non-representative sample of the market.

Need to take this into consideration from the Polkadot Agile Coretime website. Do we know what this percentage will be?

The renewal bump that is proposed in the Kusama Coretime Chain PR is 3% each sale, representing a maximum of ~47% annually.

1 Like