On-demand around the corner - what do you want/need?

With the upcoming Agile Coretime Launch on-demand coretime will be available on Kusama, target date: 18th of April!

Quick recap: With on-demand, what you can do is register a parachain runtime on the relay chain and then instead of participating in an auction or soon buy bulk coretime you can for example just collect user transactions and once you hit some trigger, e.g.:

  1. XCM needs to be sent/received
  2. User wants immediate confirmation
  3. You collected enough transactions to make producing a block worthwhile

you would order a core (block validation opportunity) on the relay chain and you will get one as soon as possible. E.g. on low load, right the next block, allowing you to produce a block for your chain and getting it validated and included on the relay chain. I explained some more concrete usage examples, in this blog post.

Now, while technically on-demand will be there on Kusama on 18th of April, actual production usage will still be involved, as we are not yet providing out-of-the-box integration code, for e.g. the above block production strategies. We plan on providing that, but now comes the actual reason for this post. I do have some questions to the community:

  1. How important do you think on-demand is and why? E.g. are you waiting for this feature already, don’t understand why it took us so long and already go crazy about it not yet being there? If so, why? What makes on-demand so compelling to you? If not, if you think this feature does not make a difference at all, please also let us know your thoughts.
  2. Assuming you are actually excited about this feature: What is still missing? E.g. would this cover your needs? Or is it besides the point and you would actually benefit much more from something else? Or are you even completely happy with the base functionality there on the relay chain and don’t mind doing the integration on your own?

Looking forward to hearing your thoughts!


I am a big fan of on-demand because it significantly reduces the barrier of entry to become a parachain and maintain that status.

While the block production strategy document is a great start, we would love to see more detailed but less technical document that explains how fees are calculated when placing a core order, ways to pay them (deposit based, ad-hoc…) and a list of possible triggers for placing those orders.

Additionally it would be great to have a Parity approved parachain implemenation that serves as a guide for parachain teams to integrate on-demand and maybe even customise block production triggers and collator selection logic for ordering a core.


Thanks @nahuseyoum !

So how fees are calculated: Basically by demand. There is a minimum fee which is set by governance. The price will go up if requests for on-demand cores start to queue. The longer the queue, the higher the price. There will be on-chain events telling you the current price.

For possible triggers: That is really up to the parachain. Whatever you can think of and is useful, only restriction is: It needs to be provable in the runtime.


Does this mean I can maintain my own parachain that mostly remains offline? I’m assuming the block that’s placed on the relaychain would be the same kind of block that I would place on the relaychain if I were running a parachain with 100% uptime. It would be great if you could clarify this!

Depends. Technically the blocks you provide can be the same as the ones you would provide if you were a parachain having bulk coretime.

In practice you will likely end up making adjustments, if you are truly decentralized. This is because the parachain is not running by default, it can not order its own core, hence somebody has to do it for the chain. Now once the parachain produced a block, you very likely need to reward that someone. This is where the difference in practice comes in.