1. Introduction
Polkadot’s transition from parachain slot auctions to Agile Coretime represents a structural change in how shared security and blockspace are accessed within the network. In Polkadot 1.0, the main path to shared security required a project to win a parachain slot auction. This model required teams to lock a significant amount of DOT for a lease period of up to 2 years, creating a high entry barrier for small and medium scale projects.
The earlier model also created technical inefficiencies. Once a parachain secured a slot, it produced blocks at a fixed 12 second interval regardless of actual demand. Under light traffic, this could result in nearly empty blocks. Under heavier traffic, the chain had no direct mechanism to exceed its fixed allocation. The relationship between what a chain paid and what it consumed was therefore poorly calibrated in both directions.
Agile Coretime, deployed as part of Polkadot’s 2025 technical overhaul, addresses these limitations by treating blockspace as a schedulable market resource rather than a fixed lease. This article examines the coretime model, its scheduling structure, and its implications for builders using Polkadot’s shared security.
2. Coretime as a Scheduling Layer
Agile Coretime introduces a more flexible allocation system for Polkadot’s computational resources. Instead of assigning a core to a single parachain for a long fixed lease, the system allows cores to be purchased, scheduled, shared, and reused according to actual demand.
A core in Polkadot is a virtual abstraction of computational resources provided by the relay chain to secure parachain blocks. It involves a randomised set of relay chain validators, and the total number of available cores determines the overall throughput capacity of the network. In theory, the Polkadot relay chain can support around 100 cores.
This shift changes the role of blockspace from a static resource into a market coordinated through time based allocation.
2.1 Coretime Chain and Resource Coordination
The Coretime Chain is the system parachain responsible for managing this scheduling process. It handles coretime sales, tracks ownership, and coordinates the assignment of purchased coretime to cores on the relay chain.
The unit being purchased is coretime, measured in relay chain blocks. This coretime can be bought, held, split, shared, or resold on secondary markets. DOT is used as the currency for all coretime purchases, directly connecting demand for DOT with usage of the Polkadot network.
This design creates a clearer relationship between resource consumption and network economics. Rather than paying for a long fixed slot regardless of activity, teams can acquire access that reflects their expected usage, technical requirements, and growth stage.
3. Core Allocation Architecture
The core allocation model under Agile Coretime supports several modes of access. A core can be assigned continuously to a single chain, divided across multiple chains through interlacing, or accessed on an ad hoc basis through on demand purchasing.
This creates a more adaptive structure than the original auction based design. Low traffic projects can avoid paying for more capacity than they require, while high traffic projects can expand beyond a single fixed allocation when needed.
3.1 Bulk Coretime and Continuous Access
Bulk coretime is the primary mode for teams that require continuous and predictable block production. It is sold in 28 day periods and represented as an NFT known as a Region. Because a Region is represented as an ownable asset, it can be transferred, split, or resold.
This structure introduces flexibility into what was previously a rigid access model. A team can purchase bulk coretime for its own use, adjust how it is allocated, or participate in secondary markets if the allocation is no longer required in full.
Teams that purchase bulk coretime and assign it to a single chain without modification are eligible for a price capped renewal at the end of the period. Renewal orders take priority over new orders. This protects established chains from sudden price volatility and gives teams a more predictable basis for budgeting.
Bulk coretime therefore preserves the reliability required by production chains while improving the ownership and allocation mechanics around access.
3.2 Interlacing and Shared Core Usage
Interlacing extends the usefulness of bulk coretime by allowing one bulk Region to be divided and shared across multiple chains. In this model, several chains can take turns producing blocks on the same core.
This is useful for projects with modest or inconsistent traffic. A chain that does not need continuous solo access can share coretime with another chain that has similar requirements. Each chain can then pay only a fraction of the full coretime cost while still accessing Polkadot’s shared security.
The importance of interlacing is that it fractionalises blockspace downward. Instead of forcing every project to acquire a full core, the system allows smaller workloads to use only the amount of resource that better matches their activity.
This lowers the economic threshold for early stage applications, research chains, and specialised workloads that would not justify continuous solo access under the previous model.
3.3 On Demand Coretime and Short Term Access
On demand coretime provides access without requiring an upfront time based commitment. It is acquired through near real time bidding for the validation of a single parachain block on cores reserved specifically for on demand orders.
This mode allows teams to pay for what they use rather than committing to a 28 day period. Polkadot maintains a dedicated pool of cores for on demand access, separate from the bulk coretime sales process.
Bulk Regions that are not fully utilised can also be contributed to the on demand pool, either partially or entirely. This allows unused capacity to return to the market instead of remaining idle.
The practical effect is a lower entry threshold for accessing the network. Early stage teams, research chains, and projects with intermittent or unpredictable usage patterns can access shared security without the capital burden of bulk commitment. For established chains, on demand coretime can also supplement capacity during traffic spikes, reducing the need to purchase bulk coretime sized around rare peak scenarios.
4. Elastic Scaling and JAM Alignment
Agile Coretime also supports elastic scaling, which allows a single parachain to access multiple cores at the same time. This enables a chain to process more transactions in parallel when demand increases.
Source: Polkadot Docs
A chain experiencing a traffic surge can temporarily use additional cores and release them when demand subsides. This makes throughput dynamic rather than fixed at the point of provisioning.
4.1 Resource Aggregation and Future Compute Markets
Elastic scaling is the counterpart to interlacing. Interlacing allows one core to be shared across several low traffic chains, while elastic scaling allows one high traffic chain to consume several cores. Together, these mechanisms allow resources to be fractionalised downward or aggregated upward according to actual demand.
This model also connects directly to JAM. Agile Coretime is not only a Polkadot 2.0 feature, but also the economic layer expected to carry forward into the JAM architecture. JAM extends the concept of cores from parachain block validation into general purpose computation.
Under JAM, any service, not only a chain producing blocks in the traditional sense, can purchase coretime to access the validator set’s compute capacity. This makes the coretime market foundational for how compute may be allocated as Polkadot’s architecture develops.
Understanding how coretime is priced, purchased, and scheduled today is therefore useful groundwork for evaluating Polkadot’s next architectural phase.
5. Conclusion
Agile Coretime changes the economic and technical conditions for building on Polkadot. By replacing the fixed auction model with a flexible market, it lowers the capital barrier to entry and aligns resource allocation more closely with actual network usage.
For builders, this expands the range of projects that can viably access shared security. Smaller projects can use interlacing or on demand access, while established chains can use bulk coretime and elastic scaling for predictable operation and temporary expansion.
For the network, coretime sales create DOT demand connected to genuine usage. The full economic picture will become clearer as more chains migrate from legacy leases and on demand usage data accumulates. Still, treating blockspace as a fluid market resource offers a more accurate representation of decentralised compute than fixed allocation alone.