Secondary Market Overview 🌐

The RegionX parachain provides two main ways of interacting with its Coretime marketplace. These two methods serve distinct purposes.

Direct Access

The RegionX parachain has its own marketplace module which contains the core logic of the RegionX Coretime marketplace. It is described in greater detail in our white paper. Essentially, it provides the functionality for listing regions purchased from the bulk market on sale. We categorize these regions into two categories based on their current 'lifecycle'. The two region types are as follows:

• Active regions. Active regions can be used in the current moment. This means that if we assign a task to an active region, it will start execution in the upcoming timeslice (assuming that the region doesn't begin later in the future)

• 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. Tasks assigned to these regions will only start with execution in the upcoming bulk period.

The pricing of inactive regions remains fixed at the amount initially determined by the seller. In contrast, the cost of active regions follows our dynamic pricing model, which accounts for gradual depreciation in value. The pricing of these regions reflects their decreasing value over time when not used.

Details on the pricing can be found in the Dynamic Coretime pricing section of the wiki.

Orders

Given that most parachains aim to be decentralized systems, it's crucial for them to procure Coretime in a decentralized manner as well. If a parachain depends on a specific group of people to sustain its operations, it fails to achieve true decentralization. Users on these chains should vigilantly monitor whether the chain continues to receive coretime renewals.

Since parachains are transparent systems, they are predictable. This means they cannot effectively interact with an open marketplace without risking others front-running them.

This is the primary reason why we developed the orders model. It enables parachains to acquire Coretime for the marketplace in a decentralized, community-driven manner.

This works by someone posting a Coretime order on behalf of the parachain (e.g., the team behind the chain). Such orders can also be posted by the chain itself. With Agile Coretime, each parachain can decide if it needs an entire core allocated to it or if sharing a core with other projects is sufficient, thereby reducing costs. A Coretime order describes these requirements. Tools such as https://www.polkadot-weigher.com/ can assist in determining how much capacity the chain needs.

These orders need to be posted each sale cycle to ensure the chain doesn’t stop block production.

The order itself doesn't hold any value. However, individuals can help an order by contributing their own DOT tokens to it. This process is similar to the legacy crowdloan model, but in this case, the DOT tokens are spent rather than being locked.

Similar to how parachains used to reward crowdloan participants, they can also specify rewards for the order contributors. This provides incentives for people to spend their DOT tokens on an order.

Of course, the parachain itself can always contribute to its own order.

NOTE: Some parachains might not want to have the logic for posting orders in their runtime. This is why we also made it possible for anyone to create an order. For example, the team behind the project can create the order, and anyone can contribute to it. Once the order is fulfilled, the RegionX chain will automatically assign it to the parachain, ensuring that the region will be used for its intended purpose.