Polkadot coretime: Bulk capacity for steady block demand

The region's dates define the useful allocation

A bulk region's scheduled start and end govern its operating window, so an advance purchase supports the parachain only when that region becomes active. Polkadot's standard bulk configuration sets a full region's duration at 28 days. A region is a non-fungible token (NFT) recording an allocation on a particular core. Buying late in the sale does not move its end. Unused scheduling opportunities expire with the allocated period.

The broker stores region length as configuration and schedules capacity in timeslices, the time units that define region boundaries. Region metadata identifies its beginning and core, while the region record supplies its end. A core mask records which scheduling shares it controls. Together, these fields describe when and how much capacity the allocation supplies. An inactive collator does not pause those dates. Low usage therefore leaves part of the purchased window unused. This is the main cost constraint for a chain that alternates between busy periods and long gaps.

Coretime Chain and Relay Chain scheduling

The Coretime Chain handles bulk allocation and sends schedules to the Relay Chain, where validators use those assignments to validate parachain blocks under the network's rules. A core is a logical validation resource within the shared validator system. The broker pallet, a runtime module on the Coretime Chain, manages sales, region manipulation, and renewals. Its scheduling instructions connect purchased capacity with the parachain that uses it. The parachain's own runtime continues to define how its transactions execute.

Bulk sale phases and DOT costs

Bulk costs depend on the sale phase and the capacity still available, while purchases spend DOT held by the buying account on the Coretime Chain. The sale calendar includes an interlude that gives eligible renewals priority. New purchases open after that interlude. Sale information identifies the offered region and the inventory that remains.

During the lead-in phase, a Dutch auction lowers the offered price over time. Buying earlier can secure capacity before it sells out, while waiting accepts that availability risk for a potentially lower price.

After the lead-in, remaining capacity sells at the established end price. That fixed-price phase belongs to one sale; later periods can have different prices and available inventory.

The broker's purchase price limit bounds what the allocation can cost at execution. It does not add missing funds or reserve an unsold core. Operating costs also include collator infrastructure and applicable transaction fees.

Renewal preserves a complete assigned workload

Eligible renewal carries the recorded workload into the next bulk period, making repeated access easier to plan while leaving payment and sale availability as separate requirements.

Coverage across the full period

The broker requires complete, final task assignments across the full core mask for the full region length. Its renewal record must show completed coverage. A time-partitioned region lacks that full-period span. Renewal prices follow the applicable configuration, including growth and sale-price rules. The renewal record for the relevant period supplies the payable amount.

Assignment finality

Provisional assignment

A provisional assignment keeps the region under its owner's control and allows later reassignment. This flexibility helps while the intended workload remains unsettled. Provisional coverage does not complete the broker's final assignment requirement for renewal. Holding the NFT without assigning it also leaves that requirement unmet.

Final assignment

Final assignment commits the capacity and removes the transferable region record. A full-period assignment can contribute to renewal eligibility, subject to complete coverage. The renewed allocation arrives with its workload fixed. Changing the future workload may require a new purchase, with the regular sale's availability and price.

Renewal windows and payment automation

Renewal needs a successful payment while the relevant sale still has capacity, so an eligible workload can lose continuity if its renewal occurs too late. The interlude provides early access before ordinary buyers enter. Renewals can also occur during the sale while capacity remains. The next period needs its own allocation before present coverage ends. An active region therefore supplies no automatic entitlement to another operating period.

Automatic renewal lets the Coretime Chain attempt recurring payments from the parachain's sovereign account. This account represents the parachain on the Coretime Chain. Configuration requires an appropriate Horizontal Relay-routed Message Passing (HRMP) channel and authorization. XCM, the cross-consensus message format, describes the instructions sent across that channel. The account needs funds for renewal payments and applicable message execution fees.

An enabled setting records automation, while a successful Renewed event records a paid renewal. AutoRenewalFailed reports an unsuccessful attempt. The automation setting can remain enabled after failure, so its presence alone does not establish coverage for the next period.

Block delivery depends on collators and validation

Coretime gives a parachain scheduled access to validators, while running collators supply the candidate blocks that the allocation needs before transactions can receive finalized confirmation. Validators assess those candidates under the registered parachain rules. The network also checks the availability of the data needed to validate them. A valid assignment can therefore coexist with a stalled collator or a candidate that fails validation. Increasing the allocation alone does not repair such problems.

Capacity planning starts with the actual constraint: available scheduling opportunities, candidate execution limits, or the collator's ability to author blocks. Transaction complexity affects how much work fits inside a block. A full core consequently supplies no universal transaction count. Coretime allocation, working block production, and finalized transactions describe different parts of the operating chain.

Does on-demand coretime suit intermittent block production?

On-demand coretime suits intermittent block production because it purchases individual scheduling opportunities, allowing a parachain to request validation as needed while accepting the pool's price and queue conditions. An order supports one parachain block, with further orders needed for continued access through this mode. The underlying parachain still needs working collators and valid registered code.

Spot pricing and available queue space affect whether an order can enter the queue. On-demand core availability affects scheduling after acceptance. The order's spending limit bounds the accepted price, and a full queue can prevent acceptance. Ordering therefore needs coordination with block readiness. Sparse demand can favor this approach. Sustained demand calls for comparing recurring order costs with the cost of reserved capacity. Neither mode is inherently cheaper for every workload.

Time splitting and interlacing change different dimensions

Time splitting shortens the operating span of each resulting region, while the broker's interlacing design divides scheduling shares over the same span. Polkadot Coretime's published runtime with spec version 2005000 blocks ordinary interlace calls.

Continuous access for part of a period

Partitioning produces consecutive, non-overlapping regions with different time boundaries. Each part retains the original scheduling share, allowing continuous access during a shorter span. This can match a workload that ends before the full bulk period finishes. The split creates no additional capacity, and the shortened parts lose ordinary full-period renewal eligibility.

Shared scheduling over the same period

The broker's interlacing design produces regions with matching start and end times and complementary core masks. The assigned tasks take turns using scheduling opportunities on the same core. This arrangement suits chains that can tolerate spaced block production. An individual share supplies only its mask's allocation, even when its dates cover the whole period.

In the broker design, final, full-period task assignments across complementary shares can establish complete coverage for the core. Eligibility depends on that completed workload and its renewal record. Renewing the workload preserves all its recorded assignments. A schedule that leaves any share in the on-demand pool lacks that complete task coverage.

Transfers preserve the region's remaining rights

Transferring an owned region changes who controls its remaining allocation, while its core, dates, and scheduling shares continue to define the capacity that the recipient receives. The broker requires authorization from the region's owner. A marketplace can arrange a sale around that transfer, but a listed region still needs a buyer. Listing alone supplies neither payment nor a replacement allocation for the selling parachain.

View full-size image

A secondary purchase needs its own assessment of the remaining span and mask. The NFT represents a specific resource with those boundaries. A shorter or interlaced region therefore differs from an untouched full allocation. Once final assignment consumes the transferable record, that assigned capacity cannot be resold as the same owned region.

Additional cores need elastic scaling support

Elastic scaling lets a compatible parachain use multiple cores, which changes available throughput only when its runtime and collators can produce and process the additional block workload. Buying extra regions alone does not enable the required parachain configuration. Collator execution and import performance can limit how efficiently the chain uses its cores. Block production settings determine how much parallel validation the workload can consume.

The SDK's elastic scaling configuration enables multiple-core block production; it does not itself purchase extra coretime. Growth in demand therefore needs an allocation policy as well as compatible software. Adding cores increases scheduling capacity within each purchased region's dates. It does not lengthen the configured 28-day bulk period.