Both Mythical and Xcavate currently own bulk Coretime. However, both have missed the opportunity to renew their core. The problem is that someone bought all the cores because they think that the current price per core is too low. While the assessment is correct that the price per core is too low and tries to draw more attention to the topic, this should not be done at the expense of existing parachains. Without Coretime, parachains will not be able to produce blocks. I contacted the Coretime buyer via mail and asked to buy two cores for 200 DOT per core. The Coretime buyer requested $150K USD for one core. This demonstrates that the Coretime buyer is ultimately just a scammer who is not genuinely interested in improving the Coretime system. As I and others want to ensure that Mythical and Xcavate are able to produce blocks, I'm opening this whitelisting proposal. As a member of the Fellowship, I acknowledge the scamming attempt as a flaw in the Coretime protocol. I also opened an issue to discuss potential improvements to the protocol, ensuring that reasonable projects always get access to Coretime and are protected from scammers. I and other members of the Fellowship will push for a fast change to ensure this kind of scamming does not occur again in the future. We also don't want to repeat this kind of proposal. It should be a one-off proposal to help these two parachains. For the future, we encourage every parachain to opt-in to the auto-renew feature of the Coretime chain. A proper guide for setting up this feature will soon be added to the Polkadot wiki.

The proposal will send two XCM messages to the Coretime chain. Each XCM message will request the relay chain to increase the core count from 62 to 66 cores. So, in total, 4 new cores will be added to the relay chain offering. The tasks 3369 (Mythical) and 3,413 (Xcavate) will both be assigned a lease for ~64 days. So, they will get around ~2 months of free Coretime. The last operation of each XCM message is to call set_storage. This set_storage call puts each parachain into the so-called WorkPlan for the next region. This ensures that both parachains will receive a core assignment in the next region.