Initial Coretime Pricing

Initial Coretime Pricing

Coretime on Kusama is around the corner, and we need to start discussion the initial price-setting of Bulk Coretime on Kusama and Polkadot. For the purposes of simplicity, let’s keep the scope of pricing to Polkadot, and after discuss how Kusama Coretime prices should be set relative to the consensus reached on Polkadot. It is also outside of the scope of this discussion to talk about renewal factors and prices, which is its own entire can of worms I’d like to avoid for now.

For full disclosure, this is Asynchronous Phil, co-founder of Lastic, a blockspace marketplace built on the Polkadot Coretime model.

Bulk Coretime

Bulk Coretime is sold in monthly allotments of a number of cores. The price of a bulk core adapts to the sales of the previous sale, but without an initial price, teams cannot forecast their costs. Parachains with existing slots (i.e., Legacy Cores) get the entire length of their 2-year lease they have acquired in their auction, and do not need to pay for their core until this legacy lease expires.

Besides the price of a bulk core, there are two parameters that need to be set for bulk coretime sales:

  • bulk_limit: the number of cores sold in each sale
  • bulk_target: the ideal number of cores we want as a community to be sold in each sale

If the cores sold is greater than bulk_target, then the price per core increases for the next sale. If the cores sold is less than bulk_target, then the price per core decreases for the next sale.

Lead-in Period

During the proposed 7-day sale period, the price descends from a high number to a lower number (sale_price) in a linear, block-by-block basis, similar to a “dutch auction.” Currently, according to RFC-1, this is a factor of 2, so if the sale_price is 1, the start price at the beginning of the 7-day lead-in period is 2.


I’ve been speaking with many fellowship and community members who believe that the price-per-core should initially set to a very low price. There are two main reasons for this:

  • We should try to find the market price by ascending to it, rather than decreasing to it. This is not only good for external and internal optics, but also for keeping Polkadot as a secure and utilized system with growing momentum. If the price is set too high, and low-to-zero cores are sold, this would obviously be very bad.
  • We need to incentivize projects to begin or continue using Polkadot and lower costs for early adopters of Coretime


To get the ball rolling so that the fellowship and community can agree on these economic factors, I suggest:

1. The price-per-core/month should be initially set to $1,000 USD
2. The lead-in factor should be increased to at least 8 in order to avoid front-running

Request for suggestions from technical experts

We need technical context in order to address how many cores should be sold and targeted to sell:

  1. How many cores can Polkadot support in total right now?
  2. What timeline should we set to fill out this capacity? (i.e., if Polkadot can support 100 more cores, by what date should we allot those 100 cores? 6, 12, 18, 24 months after the launch of Coretime?)

With this context, we can start to also set the bulk_limit and bulk_target.


Polkadot used 52 Cores in mid 2023 so probably around 90 now. If it wants to have 200+ Cores at end of 2024 it will probably have 120-130 at Coretime launch in ~May 2023

62 Legacy Cores, 550 smaller Projects on Polkadot launched on new Bulk Cores (multiple in 1) & Instantaneous. + 125 small Projects from Tanssi (or it will just hop on 2-3 Cores)

I would assume:

62 Legacy Cores
offered 45 Cores on Bulk (with 30 ideal)
15 Instantaneous

And next months bulk_limit 15 bulk_target 10

1000$ is too low i think. Let’s say DOT token is worth 25$ in May 2024. Parachains would jump on Cores for 40DOT a month.

As Aurora wrote on of the topics - Polkadot BaaS would got bought by one bad Actor, Coretime would be ruined by competition with absolute 0 price.

2500$ a month seems more reasonable to start with but still a Mechanism is needed to push new Cores on the Marketplace fast if someone buys them in bad faith/to Market speculate.

Cause it is 500DOT in price from 1 month ago that was discussed about. If the price of DOT would get higher, It’s lower than 500 DOT for them

Seems affordable for most of Parachains, the rest is encouraged to sell some Blockspace on Instantaneous


1 Like

Thanks for your thoughts @EmilKietzman1!

Some of the upcoming auctions may be extensions of existing legacy cores but it will indeed be between 50 and 65. Also, I want to avoid discussion of on-demand cores if possible to keep the scope of this discussion focused.

The price is meant to be low and adjusts month-over-month, so if the cores sell out, there will be more cores sold in the next month, each at a higher price-per-core.

This is definitely something @Poppyseed and I have brought up before and is a possibility in the current design. One way of mitigating this issue is to raise the lead-in factor as I suggested.

All in all, I still believe $1000 per core/month is a good starting point that the system can adapt to better than if we set the price even just a little too high to start.


What would be a good way to find a price in a dynamic way, reflecting maybe two or so relevant factors:

A. Demand for full or fractionalised cores
B. Transaction value

With this (or even more factors), pricing could be determined, reflecting price pressure based on demand and also purchase power, so there would be an opportunity to funnel in small projects with relevant demand and not overstimulating a whale or bad actor market.

Otherwise guessing pricing will sometimes lead to overincentivsing “any” kind of participant or only those with deep pockets.

Therefore depends on desired outcome, and from perspective of relevance there would be another axis between Kusama and Polkadot.


Low impact / low risk = lower end of Kusama Blockspace / Pricing
High impact / higher risk = upper end of Polkadot Blockspace / Pricing

And therefore a pricing could also be determined as composite of baseline cost and a risk factor.

1 Like

I’m not really techie so I’m coming from the standpoint of a consumer. If I walk into a store to buy something and the prices are too high. I’m going to walk right out and go someplace more reasonable. However the price is set it should be reasonable and it shouldn’t matter the value of dot at the time. There should also be mechanisms in place to keep any single entity from buying up all the core time.

Again I’m not techie but that’s just my thoughts.


This is a proposal for the initial price of coretime.

Regarding the work validators are doing with coretime: there is some segregation of duties here from the work done being paid to the network by the parachains (i.e. validators who are in a backing group) vs validators being paid by the relay chain (which they already are). Can we draw any conclusions about the value of the work the validators are doing in backing/auditing parachain PoVs vs the value of them providing general security to the network? The following explores two of these options, after I tried many different approaches:

Coretime as a function of validation rewards

Given the definition of coretime as consisting of “two resources (data availability and execution time) expressed in an arbitrary ratio”, we propose the initial price of coretime should be based on these two factors. Current data availability is estimated at 0.83MB/s per core and maximum execution time is 2 seconds (given asynchronous backing). The current median block weight is roughly 1.8% of benchmarked maximum, even though buying coretime for one core gives access to power of the full core, it may be better to use the actual current usage pattern for initial pricing. Given this information, assuming a core allocation is for maximum PoV size (full block weight), and the amount of DOT validators are being paid right now for the work to secure the network being on average 1170 DOT/day, we can then estimate:

Data availability provided by a core:

((0.83MB/s)/1 core)

Multiplied by the expected execution time based on current median block weight/maximum PoV size:

* (1.8%) * (2sec/5MB)

And the conversions of blocks, time and current validator rewards:
* (14400 blocks/1 day) * (1170 DOT/14400 blocks) * 1 month

= 213 DOT/core/month base cost (@ current median weight)

= $1384.50 USD (@ $6.50/DOT, please see pricing footnote).

Coretime as infrastructure cost

Another approach is to use direct infrastructure costs as a benchmark.
Calculating networking costs, based on cloud bandwidth prices (taken from GCP region europe-west1) for receiving a maximum size PoV from at least 4 other validators for validation (given current backing group size of 5, egress is free) at a full core’s worth of weight (please see footnote at the end of this post about DOT and cloud prices used here):

(1 dot/$6.50) * ($0.085/1 GiB) * ((5MB/1 block) * 4 ) * 14400 blocks/day * 1 month = 112.98 DOT

Adding in compute costs, based on GCP n2-standard-32 VMs @ $1.71 an hour (theoretical maximum compute cost anyone should pay, which allows room for other task-specific processing beyond execution time (2sec)):

(1 dot/$6.50) * ($1.710784/1 hour) * (2sec/1 block) * 14400 blocks/1 day * 1 month = 63.17 DOT

= 112.98 + 63.17 = 176.15 DOT = $1144.98 @ $6.50/DOT

Additional considerations

In the case of coretime being a form of extended registration, we can take the registration fee as a representation of a “down payment” by locking the registration to the chain for the duration of the chain’s existence. This is an average of 1052 DOT, so at an opportunity cost of 15% (staking reward percentage) annually, this comes to 13.15 DOT/month. To initially subsidize cores somewhat it may be interesting to take this into account into the calculation and subtract 13.15 DOT from the initial monthly coretime fee, coming to:

Final coretime cost per month

based on validator fee:
199.5 DOT, or $1296.75 USD @ $6.50 USD/DOT per month.

based on infrastructure costs:
163 DOT, or $1059.50 USD at $6.50/DOT per month.

As we can see, both of these approaches are close to the same value, which is encouraging. They could either be averaged together to get a reasonable value, or if a DOT-only economy is preferred to cloud cost or vice versa, one could be taken over the other. I would suggest either an average, or slight bias toward the DOT-economy approach for simplicity in calculation not requiring an oracle; however, the real-world conversion would allow for more resilience to price fluctuation.

On-demand Coretime

On-demand coretime should be priced significantly higher than bulk at launch, but not too much as to discourage experimentation. I propose 2x.

Comments/concerns with these approaches:

Validators are already being paid by the chain. If coretime payments are burnt, then it becomes a way to recoup inflation from validator reward payments, and if it is paid to the network, it is reimbursement for validator fees. If one views Polkadot as a computing system made of distributed hardware, then since Polkadot is already paying/reimbursing the hardware operators for their time securing the network, CPU is already accounted for in the validator payment, and only bandwidth cost in validating parachain state transitions could be considered incurred by the validator operators above their current line of duty; however, they already have been doing this for some time and can already be considered part of their job in securing the network. This calculation, then, is based on an indirect-but-direct cost paying the network for hardware, with the added security the blockchain brings. I would also add that ignoring infrastructure cost isn’t prudent or possible, since the network runs on paid-for compute infrastructure, which is accessed both indirectly and directly (respectively) in these calculations.

Addressing the concern of tying initial coretime price to DOT price: this is difficult to calculate using only Polkadot-internal economies, and real-world cost for teams or developers obviously determines if coretime is inexpensive or not. In this framing, using a real-world price benchmark makes sense. Alternatively, this real-world pricing is accessed indirectly in the case of validator rewards, where they must remain profitable and ideal staking ratio has previously been adjusted in the past to maintain this balance of payment for infrastructure.


Given the above formulas (and adjusting for backing group size of 3 on Kusama vs 5 on Polkadot, an average of 2KSM/day validator reward, and allowing for maximum block weight to account for experimentation), Kusama prices would be:

Validator onchain cost:
20.2 KSM = $767.60 USD @ $38/KSM

CPU: 10.80 KSM @ $38
Bandwidth: 9.66 KSM @ $38

= 20.46 KSM/core/month = $777.48 USD @ $38/KSM

Subtracting opportunity cost from registration (3.9 KSM/mo) results in:
16.3 KSM = $619.40 USD @ $38/KSM per month for validator fee approach or
16.56 KSM = $629.28 USD @ $38/KSM per month for infrastructure fee approach.

Reproducing Results

If you try these calculations yourself, pay attention to number of significant digits used as they can cause small discrepancies in outcome.

Pricing Footnote

To simplify these calculations I used a rounded number close to the current USD price of DOT/KSM (weekly average) for illustrative purposes only. Cloud pricing for these services fluctuates also, so CPU/bandwidth figures are based on a spot check and are within general range of expected prices.


Since I’ve just extended the Kabocha lease, this is a non-urgent issue for me and I can wait for the price to settle, but are you considering the price that leases currently lock for in your start pricing? There is over supply on Kusama. Teams are locking 100KSM for a lease, but that’s at least partly because they are going to get it back. Moving from “lock” to “buy” is a downward pressure on the price people will pay.

For reference, the last two lease extension I locked for “cost” 0.01KSM.

Unless the intention is to reduce the number of slots available, I think the evidence is that the price - whatever it starts at - is likely to tend towards zero.

[Note: I’m absolutely not trying to suggest that there’s no value in the concept of a parachain on Kusama.]

1 Like

I have a naive question about the matter.
So far I understand the debate as follows: coretime will of course be bought in DOT (although it is not yet clear what will happen with these DOT afterwards).
The linear value is always measured in DOT and not in fiat currency ($). Doesn’t that make it extremely difficult for the operators of the parachains to do business? This would mean that the costs of operating on Polkadot would depend on the respective market cycle.
How would it be the other way around? If Coretime was priced in dollars and offset at market value in DOT, teams could plan much more reliably. On the other hand, there would even be an incentive to hoard DOT during favorable times in order to use it as gas reserves for a more expensive future.
Do I have a fundamental misunderstanding here?
​EDIT: Or is it actually the case that the Coretime marketplace is so dynamically flexible that the required amount of DOT is always based on the current market value? Which would of course make sense and come close to its actual price in fiat.

1 Like

Thanks. Very interesting. One question though. Should the on-demand price not be left for market price discovery? That’s what I thought Lastic was for.

1 Like

Absolutely amazing rundown @erin

I love your approach by comparing coretime costs to actual infra and validation costs. Looks like it lines up perfectly with the expectations I previously laid out before, which is quite the coincidence. Your cost-based approach is perfect and a solid foundation not only for determining the initial price point set by the community, but going forward as well. I fully agree and think that we should go forward with this proposal on Polkadot and Kusama.

Regarding the costs of on-demand cores, I agree that it should be at least 2x more. If for some reason the cost of on-demand cores are close to or below the price of bulk (per given unit of time or computation), then the economics would be broken and there would be no benefit of bulk. We need to make sure that the cost of on-demand cores per unit are significantly higher due to the benefits of convenience and smaller unit of supply.


It will, but the initial starting price has to be set - then the adjustments will happen as per the implemented economics in the code and based on those factors and the market for coretime the prices can adjust.

1 Like

Even if the price of on-demand was closer to bulk the economics of it would still be fine.
Buying bulk coretime gives you several benefits over on-demand:

  1. Unpartitioned bulk coretime can be renewed at a capped price
  2. With on-demand there is always the risk of prices spiking in case of high-demand
  3. On-demand chains will at the start only be able to produce a block every 4 relay blocks. link

I think over time we should have the price fixed in USD or whatever and when you buy you pay the amount of DOT at the point of buying it. This requires a little bit more work before this can be done.

Bulk coretime price is also raising with demand, but with a fixed maximum increase between sales.

The issue you are linking discusses a possible implementation. However, if you would only have 1 collator you know when you have ordered a core and do not need to coordinate anything.

1 Like

We don’t price core time in dollars simply because Polkadot is it’s own nation and economy, and it wouldn’t do to price your goods in another nation’s currency.

Not to mention it would preferentially anchor us to the US dollar in an undesirable way. Best to just base in DOT and let the market figure it out.


We could of course use the same methodology and tweak the expected weight of Kusama blocks downward from 100% to obtain a smaller number if using the validator fee method. I’d mostly like the emphasize methodology in my post and discussion like this on the topic is welcome.


As I said, I have a lease until Jan 2025, so I won’t need to buy for a while, and it’s not really a concern to me today. I don’t think your analysis is completely unsound, but I suspect the market isn’t going to readily move from today where the “cost” is purely in the opportunity lost by locking your tokens rather than, say, staking them, to one where they fully cover the validator costs.

My gut-feel - and that’s all it’s based on - is to start at $200 per core per month and let the market find the right price. Starting too high is at least going to be a downer on new boot-strapped chains. The current registration fees are already pretty painful for marginally funded teams (200+ KSM to register a paraId with initial runtime on chain).

Anyway, I don’t really want to argue - I’m ultimately happy to just see what happens.


While I agree that there are several benefits of bulk coretime over on-demand coretime, these still do not outweigh the “time value of money,” a widely accepted economic norm.

We have many equivalent examples of this in the real world, such as:

  • a long-term (e.g., 5-year) lease of an automobile will in the end be much cheaper per-minute than an on-demand car-sharing agreement.
  • a long-term lease of an apartment will also be much cheaper than an on-demand lease such as an airbnb.

There are also benefits in the above examples for having long-term leases such as lower-cost purchase options, ability to modify, etc. all of which do not outweigh the time value of money which reigns supreme in such comparisons.

1 Like

Comparing to the average of $16,000 USD/month for locking, it has been assumed that ca. $1000/month is still much cheaper even when factoring in opportunity cost.

Also, with regards to deposits, there are a lot of people who want to lower deposits to enable more experimentation without the need for such large amounts of upfront capital. @Szegoo is proposing a model that hopes to lower the deposits for validation functions, and we need a separate proposal that lowers the deposits of paraIDs for sure.

1 Like

Comparing to the average of $16,000 USD/month for locking, it has been assumed that ca. $1000/month is still much cheaper even when factoring in opportunity cost.

That might be the case on Polkadot - I’m completely priced out of that so I don’t even bother looking. On Kusama, that’s not the average, and the slots can be had for essentially nothing if you aren’t in a hurry. Most chains “pay” a nominal 10 - 100KSM.

My parachain is essentially running on nothing (and not doing much right now - so there’s a legitimate argument that it’s not a good example), but there are other chains that are doing more on Kusama and also don’t really have lots of money to spare. It seems likely (to me) that any substantial lease charge will kill them off.

Also, with regards to deposits, there are a lot of people who want to lower deposits to enable more experimentation without the need for such large amounts of upfront capital. @Szegoo is proposing a model that hopes to lower the deposits for validation functions, and we need a separate proposal that lowers the deposits of paraIDs for sure.

I was actually thinking, the other day, about raising a proposal to “award” a parachain with a registration / initial code upload / lease to experiment with - primarily to test the water for that as a model. At the moment, I don’t have time to come up with an experimental parachain concept to pitch for though. To an extent, it comes down to what level / number of bootstrapped experiments Kusama is willing to support - I think they should welcome such things, but on-chain governance can be pretty conservative.

(EDIT: I’m also clearly incapable of tagging a message as replying to another one - not sure what I’m not getting about the UI.)

1 Like

Also - I do recognise that the thread started as “lets talk about Polkadot first”, so Kusama is somewhat off-topic. But erin did include that in the calculations and that’s what I’m responding to.

1 Like