, region_id: RegionId) -> DispatchResult { }
```
### [`update_region_price`](https://github.com/RegionX-Labs/RegionX-Node/blob/1887388bc496d0ff4dafd51ece4329a9647a609f/pallets/market/src/lib.rs#L228)
Extrinsic for updating the price of a region listed on sale.
Arguments:
* `region_id`: The region for which we want to update the timeslice price.
* `new_timeslice_price`: The new timeslice price.
pub fn update_region_price(
origin: OriginFor<T>,
region_id: RegionId,
new_timeslice_price: BalanceOf<T>,
) -> DispatchResult { }
### [`purchase_region`](https://github.com/RegionX-Labs/RegionX-Node/blob/1887388bc496d0ff4dafd51ece4329a9647a609f/pallets/market/src/lib.rs#L260C10-L260C25)
Extrinsic for purchasing a region listed on sale.
Arguments:
* `region_id`: The region that is listed on sale.
* `max_price`: The maximum price the buyer is willing to pay for the region. If the actual price exceeds this amount, the purchase will not be executed. The region price is linearly decreasing for currently active(i.e. usable) regions.
```rust
pub fn purchase_region(
origin: OriginFor,
region_id: RegionId,
max_price: BalanceOf,
) -> DispatchResult { }
```
# Order pallet
The order pallet is mainly meant for parachains looking to interact with the market. Therefore, teams looking to deploy their parachain on Polkadot should look into procuring Coretime by accessing the Market pallet.
Nevertheless, if they cannot find Coretime on the market that meets their requirements, they can create an order. This way, they will signal to Coretime traders that there is demand for a region that meets the specified requirements.
### `create_order`
Extrinsic for creating an order.
Arguments:
* `para_id`: The para id to which Coretime will be allocated.
* `requirements`: Region requirements of the order.
```rust
pub fn create_order(
origin: OriginFor,
para_id: ParaId,
requirements: Requirements,
) -> DispatchResult {
```
### `cancel_order`
Extrinsic for cancelling an order.
If the region requirements on which the order was based are for an expired region, anyone can cancel the order.
Only expired orders can be cancelled.
Arguments:
* `order_id`: The order the caller wants to cancel.
```rust
pub fn cancel_order(origin: OriginFor, order_id: OrderId) -> DispatchResult { }
```
### `contribute`
Extrinsic for contributing to an order.
Arguments:
* `order_id`: The order to which the caller wants to contribute.
* `amount`: The amount of tokens the user wants to contribute. This amount will be reserved and will only be spent if the order gets fulfilled.
```rust
pub fn contribute(
origin: OriginFor,
order_id: OrderId,
amount: BalanceOf,
) -> DispatchResult { }
```
### `remove_contribution`
Extrinsic for removing contributions from a cancelled order.
Arguments:
* `order_id`: The cancelled order from which the user wants to claim back their contribution.
```rust
pub fn remove_contribution(origin: OriginFor, order_id: OrderId) -> DispatchResult { }
```
# Order Processor pallet
Before attempting to use the order processor pallet directly we recommend reading the [Coretime Order Processing ⚙️](/docs/basics/coretime-order-processing) page.
We are looking forward to see the development of programs which will fulfill a coretime order when seeing a profitable opportunity.
### Risks & Rewards
The orders pallet is designed to minimize risk for anyone looking to fulfill an order. To reduce these risks, we have implemented the following limitations for order creators and contributors:
* **Only expired orders can be canceled.** Orders looking for a region that is currently or will be active in the future cannot be canceled. This ensures that when someone purchases a region to fulfill an order, they are not at risk of the order creator canceling it. This way, they can be confident that the order can be fulfilled, unless another user fulfills it before them.\
\
Expired orders are those that were not fulfilled, and the region they are looking for has already expired. These regions hold no real value, and anyone can cancel the order so that contributors can claim their contributions. Fulfilling such order is restricted.
* **Contributions can only be removed for expired orders.** This restriction is implemented so that the user fulfilling the order can know in advance the amount they will receive before purchasing the region they will sell.
The reward of selling a region to an order is receiving all the tokens that were collected by the order.
Rewards for contributing to an order can vary depending on the parachain. It is up to the parachains/order creators to define how they will incentivize contributions. With further development on RegionX, we will facilitate the process of rewarding contributors for parachains.
### `fulfill_order`
Extrinsic for fulfilling an order.
**Arguments:**
* `origin`: Signed origin; the region owner.
* `order_id`: The order which the caller intends to fulfill.
* `region_id`: The region that the caller intends to sell to the Coretime order. The region must match the order requirements otherwise the extrinsic will fail
```rust
pub fn fulfill_order(
origin: OriginFor,
order_id: OrderId,
region_id: RegionId,
) -> DispatchResult { }
```
The order must not be expired; otherwise, the call will fail. If the region meets all the requirements and is not locked, the caller will receive the tokens accumulated by the order.
The function will send an XCM message to assign the region to the parachain specified by the order. The assignment will be F`inal`.
If the XCM message fails to be sent, the region assignment will be stored in the `RegionAssignments` storage map. Using the `assign` extrinsic, anyone can attempt to make the assignment call, ideally after the issue is resolved.
### `assign`
Assign a region to the specific `para_id`.
**Arguments:**
* `origin`: Signed origin; can be anyone.
* `region_id`: The region that the caller intends assign. Must be found in the`RegionAssignments` mapping.
```rust
pub fn assign(origin: OriginFor, region_id: RegionId) -> DispatchResult { }
```
Extrinsic used to reattempt assigning a region after the initial attempt failed during fulfillment.
# Integration with xcRegions
## ⚠️ 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: [Solving NFT cross-chain transfers](https://hackmd.io/@Szegoo/rkryxwdIp).
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 [Solving NFT Cross-Chain Transfers](https://hackmd.io/@Szegoo/rkryxwdIp) 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.
```rust
fn get_metadata(&self, region_id: RawRegionId) -> Result;
```
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:
```rust
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`**
```rust
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,
}
```
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 [Solving NFT Cross-Chain Transfers](https://hackmd.io/@Szegoo/rkryxwdIp) article.
# Integration with the Coretime market
## ⚠️ 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: [Solving NFT cross-chain transfers](https://hackmd.io/@Szegoo/rkryxwdIp).
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](https://github.com/RegionX-Labs/Docs).
## Region Pricing
The formula used to calculate the price of a region listed for sale is as follows:
$$
r\_{price}=(r\_{end}- t)\*(tp \* c\_{occupancy})
$$
Where:
* $$r\_{end}$$ is the timeslice at which the region concludes
* $$t$$ represents the current timeslice
* $$tp$$ is the cost per timeslice defined by the seller upon listing the region on the market.
* $$c\_{occupancy}$$ represents the proportion of the Core that is occupied by the region.
> 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:
```rust
pub fn region_price(&self, id: Id) -> Result;
```
## Listing Regions on the Market
```rust
pub fn list_region(
&mut self,
id: Id,
timeslice_price: Balance,
sale_recepient: Option,
) -> 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
```rust
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
```rust
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
```rust
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.
# Renewal Questions
### Why can't I renew my core?
There are multiple reasons why a core cannot be renewed. Instead of trying to outline all the reasons, we will list all the requirements for a core to be renewable.
For a core to be renewable in the upcoming cycles it must **not** be interlaced or partitioned. Additionally, the core must be assigned to a task with Final finality. Cores assigned to the Instantaneous Coretime pool cannot be renewed. Renewal is only available when the core is assigned to a task(parachain).
### When to renew?
There are three phases in the bulk sale:
* interlude phase
* leadin phase
* fixed price phase
Renewals can be made in any phase; however, it is recommended that they are made during the interlude phase. Otherwise, there is a risk that the core could be sold on the market, preventing the renewal.
Renewals must be made in advance. If a core is purchased in bulk sale #1, this means the user has obtained a core for the upcoming bulk period (during which bulk sale #2 takes place). The renewal must be made in bulk sale #2, ideally during the interlude phase.
### Is it always worth renewing?
It is not always worth renewing a core. The renewal price is determined based on the price at which the user initially purchased the core from the market. If the price of cores drops in the next sale, it may be more advantageous to purchase a new core at the lower price and abandon the previous core. This will also reduce the renewal cost for that core in the future.
