RegionX Docs
  • RegionX Docs
  • Basics
    • Blockspace & Coretime
    • Primary Coretime Market 🥇
    • Drawbacks of the Primary Market
    • Secondary Market 🥈
    • Secondary Market Overview 🌐
    • Community Involvement 🌱
    • Coretime Order Processing ⚙️
  • Advanced
    • Cross-Chain Regions
    • Dynamic Coretime pricing
  • Build
    • Market pallet
    • Order pallet
    • Order Processor pallet
    • Integration with xcRegions
    • Integration with the Coretime market
  • FAQ
    • Renewal Questions
Powered by GitBook
On this page
  • ⚠️ Deprecated ⚠️
  • Accessing region metadata
  1. Build

Integration with xcRegions

PreviousOrder Processor palletNextIntegration with the Coretime market

Last updated 11 months ago

⚠️ Deprecated ⚠️

Before attempting to integrate xcRegions into another smart contract or frontend code it is important to have a good understanding of our approach for solving NFT metadata transfers that is described here: .

The xcRegions contract is designed to function as a facilitator, offering a convenient means for various applications to engage with Coretime regions from the Bulk market. It adheres to the PSP34 interface, enabling it to be utilized as a standard NFT token. However, the contract goes beyond the PSP34 interface by implementing the MetadataWrapper interface, as detailed in the article.

Accessing region metadata

The xcRegions contract exposes the get_metadata ink! message, which can be used to retrieve all associated metadata of the region.

fn get_metadata(&self, region_id: RawRegionId) -> Result<VersionedRegion, XcRegionsError>;

However, it is important to note that not all metadata returned by this function is guaranteed to be accurate. The region's metadata is divided into two parts:

RegionId

The RegionId is a unique identifier for regions. In itself, it contains parts of the metadata:

pub struct RegionId {
	/// The timeslice at which the region starts.
	pub begin: Timeslice,
	/// The index of the relay chain Core on which this Region will be scheduled.
	pub core: CoreIndex,
	/// The regularity parts in which this Region will be scheduled.
	pub mask: CoreMask,
}

Given that this type is used to identify regions for executing reserve transfers (in the form of u128), when a user sets the metadata of a region, the xcRegions contract can verify whether its properties align with those that are part of the RegionId. This way we can be assured this part of the metadata is correct.

RegionRecord

pub struct RegionRecord {
	/// The end of the Region.
	pub end: Timeslice,
	/// The owner of the Region.
	pub owner: AccountId,
	/// The amount paid to Polkadot for this Region, or `None` if renewal is not allowed.
	pub paid: Option<Balance>,
}

This part of the metadata is not stored within the region identifier. For this reason, the xcRegions contract cannot verify its correctness and it is the responsibility of the client to ensure its validity as described in the article.

Solving NFT cross-chain transfers
Solving NFT Cross-Chain Transfers
Solving NFT Cross-Chain Transfers