Coretime Sales
A brief on the pricing, purchasing, and sale mechanisms of coretime in the Polkadot ecosystem.
Last updated
A brief on the pricing, purchasing, and sale mechanisms of coretime in the Polkadot ecosystem.
Last updated
Disclaimer: This article is written by Dot.alert() contributors for educational purposes only. This article should not be used as a substitute for competent legal or financial advice from a licensed professional in your country.
Coretime sale is a mechanism that allows project teams to take advantage of the shared security scheme and the interoperable ecosystem of Kusama or Polkadot relay chains while running an app or appchain. Projects can bootstrap their products by purchasing coretime on-demand (i.e based on the availability of non-allocated cores) or in bulk (i.e for fixed but renewable periods of 28 days).
Buying coretime is a straightforward process whereby projects register a ParaID, reserve funds in order to acquire coretime, and are placed in a queue of pending purchases. The price of a coretime purchase is dynamically determined by various parameters such as the last valuation on record, the number of available cores, and a renewal price cap. Coretime is allocated via a brokerage system that maps the registered ParaID of an entity against a limited number of cores for a set period of time to ensure optimal usage of relay chain computational resources.
While on-demand coretime is meant to be consumed almost immediately by the purchaser, bulk coretime purchases assign ownership of a specific period of coretime (also called "Region") to each purchasing account. The non-fungible nature of this specific coretime allocation means that it can subsequently be transferred, split, consumed, renewed, or pooled.
Coretime sales are designed for an environment with limited resources (i.e secure blockspace) which guarantees data availability and offers predictable execution time. This means that projects could end up facing fierce competition to access ecosystem resources at any point of their journey, and more likely during times of high-demand.
Even though there is some level of predictability in the system to ensure that committed projects can lock and renew their coretime allocation for a longer period, the pricing mechanism is still very dependent on an evolving market. And so, there is the risk that newly-established projects with little institutional backing wind up priced out of the ecosystem. In this context, a possible solution would be to deploy a dApp on existing and well-capitalised parachains.
The ownership of bulk coretime requires careful planning in the short and medium term. This is mainly because specific allocations cannot be renewed once they have been split, which can limit opportunities for arbitrage and secondary sales. Additionally, since DOT is required to purchase coretime, any upward valuation of the token can visibly impact project teams' budgets. In this case, teams might need to consider keeping a portion of their Treasury in DOT.
