Core time: Kusama

[eskimor]

Checklist will be based on the one of Westend.

Migration legacy -> legacy + bulk - no on-demand was existing before.

• [ ] coretime chain was registered as legacy parachain
• [x] no ongoing auctions - after we migrated to coretime no new lease holding parachains must come into existence. (Covered in migration - we cancel + refund)

Added from Rococo checklist:

• [ ] coretime chain is running
• [x] Limits are high enough for migrations to succeed?
• [x] Weight limit is higher than actual weights (as benchmarked), but low enough to fit in a block?
• [x] Configure Kusama parachain lease length?
• [x] Motion: Launch coretime chain with 1.2 runtime
• [x] Motion: relay chain runtime upgrade
• [ ] Ping community that coretime has launched and that they can buy core time now with their KSM, to keep their chains running.
• [x] Motion: start_sales: Pass in proper last_sale configuration to have sales start at the proper time.
• [x] Motion: call request_core_count with the desired amount of cores (expring + any new ones + 1 for on-demand). Setting limit_cores_offered configuration seems redundant/error prone.
• [x] Motion: Assign one reserved on-demand core

Actual motion used on Kusama: https://kusama.subsquare.io/referenda/375

Prepared: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.dwellir.com#/extrinsics/decode/0x630003000100b50f03142f0000060202ca9a3b01107c32000a000000e0c40000e0c40000b013000000ca9a3b0080c3c901b01300000602fa5159b0017d10321234000602c2c33f4612a6010038320104ffffffffffffffffffff010602071ecddf380322b70100503204005039278c04000000000000000000003400

Discovered while implementing runtime:

• [ ] Dependency of polkadot-runtime-parachains > 6.0.0 (missing coretime modules) met

[JelliedOwl]

"no ongoing auctions - after we migrated to coretime no new lease holding parachains must come into existence."

Does this mean that, once coretime arrives, it's no longer possible to register a new paraid and swap an existing lease to it?

[liamaharon]

Should this issue be migrated to the fellowship runtimes repo?

[bkchr]

Does this mean that, once coretime arrives, it's no longer possible to register a new paraid and swap an existing lease to it?

Swapping leases is a concept that doesn't exist with coretime anymore. So, yes you will not be able to do this.

[JelliedOwl]

Swapping leases is a concept that doesn't exist with coretime anymore. So, yes you will not be able to do this.

Thanks Basti. So even for teams that have legacy leases - no swap mechanism from day one of coretime even if they have legacy lease time left that they want to move?

[bkchr]

So even for teams that have legacy leases - no swap mechanism from day one of coretime even if they have legacy lease time left that they want to move?

That is actually something we did not thought about to be honest. I mean all leases are migrated and they are not "lost". So, if you currently have a lease for X months, you will still get this. However, you will not be able to swap them. I assume you want to swap some lease?

I personally would be open to fast track this through fellowship, for the small number of projects that already acquired a lease. But maybe we can get them to swap before. I will ensure that this doesn't get lost and we have "a way" forward.

[JelliedOwl]

Thanks @bkchr.

To be honest, I'm considering speculatively picking up a cheap lease before coretime arrives, for a project that might or might not happen. I'm interesting in whether I would be able to off-load it to another team if I ended up not needing it, but it might be something that happens 1 or 0 times, so "fast track this through fellowship" is probably the right way to handle it.

I know some current teams are still buying leases on new paraids and swapping them rather than just extending their existing lease (I'm not sure why, but maybe they want the extra bidding power of that extra few lease periods in their bid), so there could be a team that does this right at the end of the auctions and doesn't swap it in time. Most likely not though.