We currently hold 74 of the 94 available cores on Kusama and 9 of the 18 available cores on Polkadot. Our objective in sharing this perspective is to foster informed discussions about core functionality, market dynamics, and broader ecosystem implications. We emphasize that core sales operate on permissionless, free-market principles.

Documentation Gaps

Many in the Polkadot ecosystem lack a comprehensive understanding of cores—their purpose, mechanics, and economic significance. This document outlines our observations on core valuation, functionality, and potential inefficiencies. We acknowledge that some details may require refinement and we welcome community feedback.

A notable concern is the incomplete documentation surrounding cores, Polkadot’s primary resource-allocation mechanism. We urge the Web3 Foundation, the Polkadot Technical Fellowship, or other relevant bodies to prioritize clarifying and updating these materials.

Core Fundamentals

Cores serve as the foundational resource enabling rollups to access the relay chain’s compute capacity. In their current “bulk core” form, assigning a core to a paraID guarantees a rollup uninterrupted access to Polkadot’s resources for approximately one month—the core’s validity period. Purchasing a core in a given month secures compute access for the following month. While the timing does not strictly align with calendar months, this analogy simplifies the concept.

Renewal Mechanics

Once a core is assigned to a paraID with finality, the holder gains renewal rights for the subsequent month. Renewals occur during a one-week “interlude period,” where existing holders face no competition.

Following the interlude, a two-week “lead-in phase” opens, during which cores are sold via a descending-price Dutch auction. Any party with sufficient DOT or KSM may purchase available cores in a single transaction, provided they meet the capital requirements.

The final week is a “fixed-price phase,” where cores are offered at the month’s lowest price. Cores acquired during the lead-in or fixed-price phases are transferable, whereas renewed cores remain tied to their original parachain unless transferred through more complex processes.

Renewal Pricing Mechanism

The system incorporates a “rent control” feature, capping monthly renewal cost increases at 3% (the “renewal bump”). For example, a core initially purchased for 10 DOT can be renewed for no more than 10.3 DOT the following month. This mechanism provides cost predictability for projects, making rent-controlled cores a valuable resource.

Resource Allocation Concerns

While Agile Coretime theoretically allows dynamic core usage, documentation on its implementation appears insufficient, possibly leading to underutilization. Over recent months, at least 10 rollups have consistently renewed cores, with others retaining cores until their parachain lease expires. Some exhibit minimal on-chain activity, raising questions about resource efficiency.

Future Considerations

The total core supply is fixed. With elastic scaling, high-traffic rollups may require up to 12 cores each, a scenario that could intensify competition. One Technical Fellowship member noted that 12 cores could support “500ms block times and ~12MB/s DA bandwidth.” If all cores become locked via renewals, it remains unclear how renewal costs would scale. Further clarity on these dynamics is needed.

Market Dynamics

During the lead-in phase, core acquisition is often a matter of speed, with no restrictions on bulk purchases. Kusama’s initial core implementation led to oversupply and extremely low prices (as little as 0.0001 KSM), a clear mispricing given rent control.

Polkadot’s core launch avoided oversupply by capping availability at 18 cores, with ~10 typically renewed and ~8 sold monthly. Until now, no single buyer has acquired all available Polkadot cores at once; instead, purchases have been fragmented, often for testing rather than active use.

Contact Information

We welcome feedback. Feel free to contact us at [email protected]

I’ve read this post three times and still don’t get it.
You’ve bought all cores, and effectively disrupting the network, in order to get attention to the issues?
Is it “fix the issues and get the cores back” or “fix the issues and we’ll stop doing this”?
Or is it rather “fix the network so what we’re doing wouldn’t be possible anymore”?

It’s also not clear what you’re suggesting to do with the docs you’ve written, maybe consider creating a PR to polkadot-docs or polkadot-wiki?

There is already a Referendum up for vote modifying this on Kusama.

Do you have a proposal on how this could be improved?

My proposal here would be to introduce some training wheels: Coretime training wheels · Issue #142 · polkadot-fellows/RFCs · GitHub

These training wheels would not fix the price (which is not really possible right now), but would instead ensure that interested parties always get access to the system.

Related:

• Adjustment of ideal block proportion as in Ref#512 will likely drive price of cores up as we will have a lower expectation of how many cores we should sell each period (40%) before adjusting the price, this mixed with increased demand due to elastic scaling should regulate prices to disincentivize core hoarding. I hope there are limits on how many cores can be assigned to 1 parachain to not get locked with 1 parachain getting all the cores.

• On-demand coretime remains an option. If your para still doesn’t have much traffic like most, paying 0.005 KSM with onDemandAssignmentProvider.placeOrderKeepAlive(maxAmount, paraId) to produce a block(a cost that can be passed down to the user) might an acceptable solution.

GM,

To expand on what I wrote in Polkadot Direction the other week, here are some ideas that I think may be worth exploring.

Disclaimer: I am not a developer, I don’t have a PHD in economics, I just like Polkadot.

I have 4 ideas as to modifications that can be made to the system:

• LBP-like mechanism during the lead in period

• Splitting the lead in period up into two phases

• Pre-purchase non-transferable cores

• Adjusting, as OP put it, the “renewal bump” or the renewal price

I do not think these things are mutually exclusive; maybe parts of each can be taken into consideration. Again, I’m not an economist, I’m just floating around ideas and hopefully some of them are okay/worth looking into.

LBP-like Mechanism

This is what I spoke about a bit in Polkadot Direction. Basically, at the moment, there are three phases to coretime sales:

1. Interlude (or renewal) period – this is where parachains can renew their cores
2. Lead in period – this is where anyone can purchase a core in a Dutch auction style sale
3. Fixed price period – this is the lowest price for cores

The “problem” with this current system is that if you believe the start price during the lead in period is too low, you are rather silly to not purchase all of the cores, assuming you have at least 1 buyer. It is also pretty much a fastest finger first / whoever puts in the highest tip system, which is kind of bad imo. This only rewards the collator as they are the ones getting the tip; the protocol itself sees none of this.

I am sure that people will be of the opinion that “eventually the price of cores will be too high”, but I disagree, I think there are other protocols, etc., that have funds to FAFO and semi-DOS the network. I also think that there will be parachains that will need to buy from the people doing this, especially when parachains want more cores for elastic scaling.

In order to make it more capital-intensive to purchase every core, one of my ideas is that we should add an LBP-like system to the coretime sales. You can Google how this works or check here, but basically it follows:

• Price go down in Dutch auction very gud
• If many buy pressure, price go up, clearly thing I sell is undervalued wow
• Price go back down to line if no buyer, clearly no one want buy at this price

It’s pretty simple, from a high-level PoV, and it looks something like this:

It’s pretty simple, from a high-level PoV, and it looks something like this:

To me, this has some benefits:

• Increases capital required to take the piss and buy all of the cores
• More DOT is burnt, or whatever happens, because the price can go up, and isn’t just always down
• Creates a game where you might lose out if you don’t buy before others do (I wonder why this mechanism exists in DeFi, eh?)

I guess a downside is basically “what if my mate’s project can’t buy a core for some really low price”, but I am not sure why DOT token holders should care about that too much.

Split up the Lead-In Period

Currently, there is no mechanism for someone who wants to pay more for a core to do so. For example, if a team really wants to purchase a new core, and they value cores at 1,000 DOT - they cannot put in this bid.

Imagine the scenario:

• There are 5 cores
• Cores are 100 DOT
• Person A values cores highly, at like 1,000 DOT
• Person B knows that person A values cores in this way

Why wouldn’t person B buy all of the cores at 100 DOT immediately, even with a massive tip (see above about fastest finger first), because they can sell a single core for more than they bought all of the cores for? This, to me, is rather bad. I get that it’s “how its designed” but that doesn’t mean it can’t be better. Obviously person A could choose to not buy a core off of person B, but if person B has enough capital to do this for a number of months, person A probably will end up caving in and buying a core.

Again, assume that those buying cores aren’t just “retail taking the piss” assume they are well financed actors.

A possible way to fix this would be to split up up the lead in period into two phases, so the new timeline of core sales would look like:

Week 1: Interlude / Renewal Period – no changes

Week 2: Auction/Candle Auction/whatever mechanism where “highest bidder wins / the price goes up” for some cores

Week 3: Dutch Auction period – price goes down over time

Week 4: Fixed Price period

This means that those who value cores highly can pay more DOT. If people start taking the piss bidding up the price (I heard this happened during parachain slot auctions, whoops) then the bidder can choose to stop bidding and quite heavily impact the capital reserves of the person taking the piss.

Pre-Purchase non-transferable cores

Here’s how core purchases currently work (simplified a bit):

• You bid for a core in April
• The core becomes usable in May

Assume everything else remains the same, with the buying in batches, etc.

Perhaps instead, it could be modified so that people can pre-purchase NON-TRANSFERRABLE cores, which would be assigned to a particular task/ParaID.

• In April, you deposit/reserve some funds, along with stating the task you want to assign a core to
• In May, those funds are utilized automatically to purchase a core and assign it to your task
• In June, the core is active

The pricing for this can be fairly simple (I think), so for example:

• The price of a core in April (during lead in period) is 10 DOT
• The “worst case scenario” for core prices in May is 100 DOT (assuming all cores sell out) during the lead in period
• The purchaser locks 100 DOT in April
• In May, during the interlude phase, the system checks if there are any “free cores” (I guess it’s something like total_cores - max_renewable_cores = free_cores)
• If there is a free core, it buys it and assigns it to the task

This requires a lot of forward planning, but prevents people sniping, and people can buy for the market rate. I hope it makes some level of sense.

Modifying the renewal bump, or renewal price

It seems that if I buy a core in April for 10 DOT, in May the max the renewal cost can be is 10.3 DOT. This is the 3% renewal bump. It could be an idea (probably wont be liked) to either Increase the renewal bump - meaning that those with cheap cores bought during over supply cant squat indefinitely, which seems to be one of OPs issues.

Or, potentially, the renewal price could have some level of gravitational pull towards the market rate. For example:

• The project can renew its core for 1 DOT
• Market price is currently 1,000 DOT
• The market has sold X number of cores for 1,000 DOT

In this case, it is obvious that this 1 DOT renewal is very, very cheap. Perhaps as more cores are sold for a higher price, the renewal bump increases, gradually nudging the renewal rate to the market price.

Think of it in terms of gravity. The more sales for a higher price, the bigger the mass of the object. The little moon (the renewal price) should move towards the bigger mass.

I hope that these made sense, I wrote them while I had some free time, would be more than happy to discuss further – feel free to call me retar dio.

For those interested - @bkchr, @seadanda and @xlc are discussing more about a possible change on Github, likely the proposed solutions are a lot quicker/easier of a change than some of the stuff I proposed.

Thank you, @coretimenegotiation, for raising and highlighting the issues with the current core time sales, namely:

• Incomplete documentation
• A poor pricing model

These problems have been brought up multiple times in the past but were dismissed.

Unfortunately, the proposed “training wheels” solution only adds another layer of complexity that is likely to deter customers, without addressing the underlying issue—the flawed core pricing model.

Hello,
If you are in contact with teams running Altair, Picasso, or Xode, please inform them to reach out to us. We have not yet been contacted by these teams regarding core renewals. If cores are not secured, these chains will stop producing blocks in 6 days.

Existing offers from other parties have ranged from 0.0009 KSM to 10 KSM. We believe that Kusama cores are worth 50 KSM. Relevant discussion: Initial Coretime Pricing

If you’re interested in acquiring cores, contact us at [email protected]

We will continue to participate in core markets until the price of cores is in our estimated value range. We look forward to seeing more parties be actively involved in these markets.

In my opinion, the main issues of the current system is that it does not subject the renewals to a proper market force. This is particularly problematic in a situation where prices are low and the entity could just buy up all the cores, sit on them, and escape upward motion of the price due to the slow adjustment. This is exactly what has happened now.

I’ve mentioned this problem a while ago in RFC 15, stating that a predictability of renewal prices fundamentally contradicts the idea of finding a “market price”. I’ve mentioned that increasing the market force on renewals "[…] prevents a situation where the renewal price significantly diverges from renewal prices which allows for core captures.” We don’t see the divergence of market price and renewal prices, because demand for cores started very low and hasn’t picked up yet. But, we have seen now an entity occupying the cores and facing small future costs of holding on to them.

I think a reasonable path forward is to subject renewals to (at least some) market force which would make this attack eventually costly once demand for cores picks up. It might take some time (depending on how serious the demand is) but holding on to the cores just for griefing purposes becomes too costly.

Update on Coretime Negotiations and Future Plans

We would like to provide an update on the status of our ongoing negotiations surrounding coretime and outline our plans moving forward.

Recently, OpenGov Referendum 1536, proposed by Bastian, has drawn attention. While we had previously advised against this course of action due to concerns about its potential impact on the core market structure, he proceeded regardless.

For broader community awareness, we would like to clarify the current state of negotiations related to Polkadot cores. There have been misrepresentations regarding our involvement, particularly by members of the Polkadot Technical Fellowship, which we believe require correction.

Negotiations Overview

We have consistently highlighted systemic concerns with the existing coretime framework. These include the absence of a permissionless and trustless secondary market for core sales—a structural gap we have repeatedly raised. The recent allocation of treasury funds to RegionX to develop such a marketplace supports the premise that this need is widely acknowledged. However, we hold differing views on implementation. Specifically, we advocate for a marketplace hosted on Polkadot Asset Hub or for enabling smart contract functionality directly on the Coretime chain.

Due to the lack of a functioning secondary market, we have had to engage in direct price discovery ourselves. On Kusama, we established 50 KSM as a baseline value per core. While this may not reflect the maximum price some teams are willing to pay, it offers a starting point in the absence of broader price discovery mechanisms.

We believe that Polkadot cores hold significantly more value than those on Kusama. During negotiations, we received an offer from Bastian of Parity Technologies for 200 DOT per Polkadot core. Given the relative value discrepancy between Polkadot and Kusama, we viewed this as an opening bid and responded accordingly. Our counterproposal was informed by core availability and timing, notably the expiration of the Mythos chain’s core—a factor we believed had not been widely recognized.

Negotiations continued, and after several rounds of offers and counter-offers, a provisional agreement of 3,500 DOT per core appeared to be reached. However, this was later rescinded, with a new offer of 500 DOT presented, which we do not consider aligned with the value of a Polkadot core. While we remain open to dialogue, we also wish to express our disappointment in being publicly characterized as acting in bad faith. We see these statements as efforts to gain leverage during negotiations.

Our position remains that 3,500 DOT per Polkadot core represents a reasonable valuation. Should this price be met, we are prepared to allocate the corresponding cores to their parachains without delay.
We have also received inquiries from Jonas Gehrlein (Web3 Foundation) and Karim Jedda (Parity Technologies). The proposals they presented fall below our stated price threshold. While we respect the contributions of all involved individuals, we question whether alternative negotiators might be better positioned to assess the market value of Polkadot cores in alignment with our perspective.

Next Steps

We intend to continue engaging with the coretime marketplace and contributing to its development. While we maintain concerns about certain structural inefficiencies, we are encouraged by the increased activity and discussion around improving the system.

Regarding a pending transaction: we remind @hgminerva that we are awaiting the transfer of 50 KSM for the purchase of a Kusama core for Xode. This must be completed today, if it is not then it will not be possible for Xode to renew their Kusama core.

We remain confident in the Polkadot ecosystem’s potential as a platform for scalable blockchains. Our assessment of recent network performance reinforces this belief, and we view our role in core ownership as an opportunity to facilitate onboarding of new projects.

As such, we believe that our ownership of cores presents a good opportunity for us to onboard businesses to this ecosystem. Some in this thread have correctly identified our intentions. In fact, you can see a snippet of that here: https://kusama.subscan.io/extrinsic/27856034-2

We will be registering parachains on each relay chain and assigning our unsold cores to these parachains. This will allow us to sell these chains to interested parties, either existing parachain projects or companies that our BD team will identify.

On Kusama, especially, the cost for registering a parachain is very reasonable at around 1,000 USD. This, along with the high throughput, data availability, and incredibly low rent-controlled cores, makes these chains probably the best deal in the entire web3 space for any project.

None of our actions are malicious. We are participating in a permissionless system. We hope everyone reading this understands the importance of this permissionlessness and stands against Referendum 1536, against those who wish to rig the game whose rulebook they themselves wrote, and against an erosion of the Web 3 vision we all share.

If any project wishes to inquire about acquiring one of these chains, our inbox, as always, remains open for negotiation: [email protected]