Integration with the Coretime market

The RegionX Coretime market utilizes an order-book model and integrates directly with the XcRegions contract. For a region to be listed on the market, it must be represented within the XcRegion contract.

The regions sold in the market are classified into two categories:

  • Active regions. The tasks that are assigned to active regions can currently be performed on a Polkadot core.

  • Inactive regions. These are the regions that will become active in the upcoming Bulk period. The regions purchased from the Coretime chain fall into this category until the start of the next Bulk period.

The active regions experience a depreciation in price over time, as described in the RegionX white paper.

Region Pricing

The formula used to calculate the price of a region listed for sale is as follows:

Where:

The contract doesn't store the entire region's price; instead, it records the price of its timeslice, which is determined at the time of listing the region.

The price of a region listed for sale can be determined by invoking the region_price ink! message, which is made available by the market contract:

pub fn region_price(&self, id: Id) -> Result<Balance, MarketError>;

Listing Regions on the Market

pub fn list_region(
    &mut self,
    id: Id,
    timeslice_price: Balance,
    sale_recepient: Option<AccountId>,
) -> Result<(), MarketError>;

The market contract provides a list_region ink! message, accessible to anyone wishing to list their region for sale. However, before initiating this call, the region's owner must grant approval to the market contract, as the region will be transferred to it upon listing.

Approvals are made by invoking the approve ink! message exposed by the XcRegions contract.

Based on the configuration set during contract deployment, listing a region may require a deposit from the caller. This deposit can be reclaimed when the region is delisted from sale. This mechanism is necessary to provide users with an incentive to remove their expired regions from the sale list, preventing storage bloat.

Updating price

pub fn unlist_region(&mut self, id: Id) -> Result<(), MarketError>;

Once a region is listed for sale, the owner has the permission to update the region's timeslice price.

Unlisting Regions from the Market

pub fn unlist_region(&mut self, id: Id) -> Result<(), MarketError>;

If the owner decides not to sell a region they've listed, they can choose to unlist it.

Should the region expire before being sold, anyone can unlist the region and claim the listing deposit.

Purchasing Regions from the Market

pub fn purchase_region(
    &mut self,
    id: Id,
    metadata_version: Version,
) -> Result<(), MarketError>;

Anyone willing to pay the asking price can purchase the regions listed for sale.

However, it's crucial for the client to verify the validity of the listed region's metadata. Upon verification, the buyer must specify the current metadata_version of the listed region. This allows the market to ensure that the purchase proceeds only if the metadata remains unchanged.

Last updated