Cross-Chain Regions

The Coretime parachain, by itself, doesn't support deploying smart contracts. As a result, this limits the creation of a secondary Coretime market on top of it. Due to this limitation, the market logic must be implemented externally. In our specific scenario, the marketplace logic will be located on the RegionX parachain.

Considering that the assets sold in the Coretime market are regions acquired from the Bulk sale, it's essential to establish a mechanism for transferring these regions to the RegionX parachain where the market functionality is deployed.

Since regions can be represented as NFT assets, cross-chain transfers are feasible, particularly because the XCM format is designed to support such transactions. We can transfer regions using XCM reserve-based asset transfers.

However, this approach only allows for the transfer of ownership information for the region, not the properties of the region itself. It's important to have these properties available on the parachain where the market operates, as the value of each region is intrinsically linked to its specific properties.

Each region possesses a set of properties that highly influence its value on the market. These properties are:

• begin: Specifies the starting point of time from which a task assigned to the region can be scheduled on a core.

• end: Specifies the deadline until a task assigned to the region can be scheduled on a core.

• length: The duration of a region. Always equals to end - begin.

• core: The core index to which the region belongs.

• mask: The regularity parts in which this Region will be scheduled.

• owner: The owner of the region.

• paid: The payment for the region on the bulk market. Defined only for renewable regions. This is used to calculate the renewal price in the next bulk sale.

To successfully list regions on the market, it is necessary to transfer not only the ownership but also the complete set of property values to the parachain where the market operates. This ensures that all relevant information about each region is accurately reflected and accessible in the marketplace.

We have developed a solution to address the challenge of transferring metadata, which is compatible with the existing XCM V3 message format. This solution is designed to function without the need for the 'Transact' instruction, a feature that is currently disabled on all production-ready parachains.

For the purpose of reading region metadata, we use ISMP, which allows us to trustlessly read the data from the Coretime chain. This is possible due to the architecture of Polkadot, as the state root of all parachains is stored on the relay chain. Thus, a relayer can provide the actual data, and we can verify it given that we have access to the Coretime chain's state root.

However, we don't actually need to have a relayer infrastructure. We implemented the relayer functionality in the frontend so that the frontend can self-relay for the users in the background.

We recommend reading more about ISMP here: https://docs.hyperbridge.network/protocol/ismp