April 2025 Coretime Purchase

Ecosystem
21

Some thoughts having experienced the coretime saga at is fullest, as a builder transitioning to coretime, as the very first “scalper” pointing out in Kusama long ago the issues of bulk coretime pricing, as proposer of the dismissed setting of a minimum price and later the accepted ideal bulk proportion adjustment, being saved by other core hoarders and now with a stalled* parachain that also forgot to renew.

Should I pay the asked 50KSM? maybe I should, it’s a reasonable price for the service being provided, I believe coretime should be priced to at least help offset the cost of validators (and reduce inflation with more confidence). It was my fault not renewing and now I deal with the consequences(sure the system doesn’t make it easy). So I feel uneasy when people start paying attention and getting around rules only when some of Polkadot’s darlings are threatened, I wouldn’t like the proposed ref to pass, it sets a bad precedent, coretime has a cost, we pride ourselves of the quality of our product so we should price it accordingly, does it cost 3500 DOT ? maybe, I don’t know, keep negotiating. I can’t afford that so I stay in Kusama, if affected projects can’t afford it either maybe they should switch to Kusama too.

With Kreivo stalled* I remembered on-demand coretime is a thing, conveniently I’m a small fry with a very early stage ecosystem and the projects building with us are still under construction, our parachain like most has very low traffic so it seems very reasonable to just pay for validation whenever necessary, even blocks every 5min is still cheaper than the 50KSM, so we are good right? not so much, UX will definitely be hurt and it will affect our projects once they start getting activity. If only on-demand experience could be better :thinking:

Here’s a bold feasible idea that I was discussing in a thread in the fellowship channel. What about fixing bulk sales by not having them? at least in Kusama, what if we ditch the coretime chain and go on-demand coretime only ? It’s the literal pay as you go, a simple model easy to reason with, it could be priced even simpler with stables, it just needs a better experience.
Inspired by “Basti-blocks” I’d like to propose an adaptive block production system. First, because we can, let’s make 0.5sec(or less) the default block duration everywhere, immediately producing a block(low latency) is super important for UX, it’s the way users know their interaction was accepted by the system. Then instead of immediately packing our block in a box(PoV) and sending it to the relay, let’s wait until we fill our box and it’s worth sending(or hit a deadline), this means the parachain doesn’t produce blocks at a regular interval, it becomes a reactive system that does work(produce blocks) only when there is something to do, it also means we optimize resources as the relaychain doesn’t waste time validating empty blocks. Then allow me to configure an account that gets charged automatically and we are golden :wink:

1 Like
22

Hello everyone,

We are publishing our email correspondence with Bastian, Jonas, and Karim to ensure transparency. This record outlines our intentions, details how the negotiations unfolded, and explains our reasons for opposing OpenGov Referendum 1536.

2 Likes
23
24

I invite anyone that is truly interested in bringing the ecosystem forward and wanting to fix this issue, to contribute to this RFC.

We are especially interested in hearing from Parachains teams what they are saying into the direction of renewal prices. We are very likely going into the direction of aligning the renewal price to the market price. Now the question is how we determine the market price. Do we keep the price discovery “bounded” and use a dutch auction for example. Or are we going into the direction of bidding?

4 Likes
25

Sounds good, but first the inflation rate has to be lowered substantially. There is a reason central banks target 2%.

26

The obvious long term “stable state” situation for coretime sales is that the cost of cores is directly used to pay for the validators on the network.

If we want to estimate how much cores should cost, we should estimate the actual cost to run the network underneath it.

Obviously this does not really work today because:

  1. we overpay validators
  2. we undervalue cores

The disparity between the cost of the network and the revenue generated can probably be justified due to the fact that Polkadot is still relatively new, but the fact that inflation / staking of the network is basically unassociated with coretime sales is probably a fundamental flaw in the whole tokenomics.

I understand that strictly tying these two things together can lead to a “death spiral”, where:

  1. a lack of demand leads to low payouts for validators
  2. low payouts leads to less or lower quality validators
  3. less or lower quality validators leads to less security
  4. less security leads to less demand

But, there are probably ways to put a floor to the validator rewards, and then allow validator rewards to increase as a function of the coretime sales themself.

This also aligns incentives among the teams that launch on Polkadot, and the validators who run the network.

3 Likes
27

I am not a coretime buyer (not yet), but would like to suggest something simple that works to solve today’s problem and is very easy to reason about.

Use a simple exponential pricing for the RESERVE_PRICE (the minimum price a buyer has to pay per core) formula like

190 × (1.01854)^i
  • i = # of cores “sold” so far
  • 190 = starting price (in DOT)
  • 1.01854 = exponential growth factor per core

With the above, as we increase from i=0 to i=340 cores (the Toaster target), the price reaches about 100,000 DOT. Its simple enough that a 5th grader can understand it (which is GOOD for a customer base who just wants something simple and predictable), and solves the present day problem really quickly, in a way that I hope could be implemented tomorrow.

To give you the math:

  • 190 × (1.01854)^0= 190 DOT
  • 190 × (1.01854)^50= 476 DOT
  • 190 × (1.01854)^100= 1192 DOT
  • 190 × (1.01854)^150= 2298 DOT
  • 190 × (1.01854)^200= 7.5K DOT
  • 190 × (1.01854)^250= 18.7K DOT
  • 190 × (1.01854)^300= 47K DOT
  • 190 × (1.01854)^340= 100K DOT

You just pick two numbers to replace 190 and 1.01854 and skip all the market based pricing until the 200th core is actually sold. If you have some alternate formula that works so the last core is 3500 DOT (which I think is very reasonable if its the last core!) for the 50 or 100 cores present day, ok!

But the key feature of exponential pricing makes it hard for someone to buy up everything and will fend off an attacker – it becomes 1.854% more expensive for the next core. Again, something a 5th grader can understand in the sense of “Compound interest is the eighth wonder of the world. He who understands it, earns it … he who doesn’t … pays it.”

1 Like
28

We are issuing an operational update and outlining actions that are required to be taken by certain network participants. Immediate attention is necessary to avoid service interruptions for specific parachains.

Renewal of Existing Chains

The following Kusama parachains will be deactivated in one day unless their core leases are renewed. Responsible teams should complete renewal as follows:

  1. Transfer 50 KSM to the following address: J2HQtWuJMHpNWZ4Y6U85bz6wCGmxYHTepqZQwUtqqAdyFBi

  2. After the transfer is confirmed, you must send an email with your paraID to coretimenegotiation@proton.me

Failure to complete these steps will result in the parachain being taken offline.

  • Xode (3344)

  • Picasso (2087)

  • Parallel Heiko (2085)

  • Mangata (2110)

  • Turing Network (2114)

  • Quantum Portal Network (2274)

  • ParaIDs 3359–3388, 9999

Next Steps and Core Utilization

We intend to deploy all acquired cores by registering parachains on each relay chain and assigning our cores accordingly. These parachains will subsequently be offered for sale.

To date, we have completed the reserve-and-register process for Kusama parachain 3415.

We cannot post links to these extrinsics because of forum restrictions, but you can check our Bethany account.

We will continue to renew our cores and participate in all upcoming auctions until we reach our valuation target. For transparency, the bids received to date are listed below:

Polkadot

  • 3,500 DOT (Bastian; later rescinded)

  • 3,000 DOT (Bastian)

  • 750 DOT (Karim)

  • 500 DOT (Bastian)

  • 200 DOT (Bastian)

  • 100 DOT (IronHash Systems; we believe this is not a legitimate entity)

  • 35,000 MYTH (Sourabh)

Kusama

  • 50 KSM (Altair)

  • 50 KSM (Xode; pending payment)

  • 10 KSM (Bastian)

  • 0.1 KSM (0x5hmoo)

Correspondence regarding the 35,000 MYTH bid is available pastebin/nVxGYXEZ

We believe these bids indicate that core leases on both networks remain undervalued.

We remain available for inquiries regarding core or parachain acquisitions: coretimenegotiation@proton.me

2 Likes
29

Apart from being simple and robust, your solution has the additional benefits that:

  • People are motivated to acquire a core as early as possible to secure a lower price.
  • Once someone has a core, they’re unlikely to give it up, since they want to keep their relatively cheap one.

I don’t think your solution is final or fully fleshed out yet, but it’s a solid suggestion and a great starting point for discussion.

2 Likes
30

Hello everyone,

We have registered six Kusama parachains (IDs 3415–3420) and will allocate all 73 of our cores to these chains today. Although the deadline for allocation is nine hours from now, we plan to complete this process well in advance.

Any team whose parachain appeared in our previous announcement must contact us immediately to ensure continued operation; otherwise, their parachain will be taken offline.

We will continue renewing our cores and participating in future core sales until core prices reach what we consider fair valuation. Please be aware that core availability is not guaranteed in upcoming sales, and you should not expect to receive the same treatment of being granted a core via whitelisting like Mythos may be on Polkadot.

For reference, our Bethany account is available here:

1 Like
31

I believe you’re overlooking the fact that OpenGov is an integral part of Polkadot’s permissionless system.

You’ve raised a crucial point for discussion, but negotiating a deal by creating an adversarial environment for the ecosystem isn’t in the best interests of the community.

32

I’m not super convicted on this, but how is buying something on an open market and reselling it adversarial? The coretime sales system has always had secondary markets in mind, and RegionX (and Lastic?) received Treasury funding for that function, even.

I’m having a hard time reconciling the system as designed with claims of maliciousness or adversarial behavior, to be honest.

5 Likes
33

Phrasing this is as just “buying and reselling” is, I would say, reducing the problem to the point past the point where it’s a useful. It’s like saying “how is moving my arm ahead of me a crime?” ignoring the broader fact that you’re punching someone.

In this case, you have a single entity attempting to corner the market. I’d like to quote from the Wikipedia page on this topic. There is a long history of governance dealing with situations like this to avoid negative externalities.

“In the few cases where companies have purchased a dominant position in a market, governments and exchanges have intervened. Cornering a market is often considered unethical by the general public and has highly undesirable effects on the economy.”

1 Like
34

With RegionX, we are looking to provide a platform where Coretime can be safely traded, given that it will be deployed as a parachain controlled by DOT holders (KSM on Kusama).

Without such a platform, Coretime resellers—as in this case—can easily end up not fulfilling their promise after receiving payment. This is why it’s important to have a trustless trading platform in place.

Thanks to our latest proposal, the solution will be fully deployed on Kusama in about 1.5 months. After that, we will move on to deploying it on Polkadot.

1 Like
35

From a security perspective what I see is that there was a critical flaw on the system design.

1 Like
36

One could have — and still can — start with a very simple and secure approach, such as the model suggested by @sourabhniyogi, or even a fixed price per core (in USD or KSM/DOT).
This approach can always be adapted later when the need arises.
Instead, we began with a complicated model, with all its flaws.

37

Hello everyone,

We would like to provide clarity regarding our next steps, as outlined in our previous communication.

Current Status

The following information applies to both relay chains, with Kusama being used as a specific example.

We have acquired several cores, which have been assigned to multiple parachains. At present, we have six parachains on Kusama. Five of these parachains are allocated 12 cores each, while the sixth one has 13 cores.

These cores have been legitimately purchased through the permissionless and free market, and we have plans to utilize them as follows:

  • Conduct performance testing
  • Onboard businesses to the ecosystem, taking advantage of the high transaction per second (TPS) capabilities, data availability (DA), low block times, and cost-efficient rent control on these chains
  • Offer these chains for sale to other projects seeking cores

Price structures, details, and marketing material will be following soon and we encourage you to reach out if you wish to explore any of these opportunities.

The para manager accounts for all of our parachains are configured as pure proxies. This setup allows for greater flexibility when working with potential buyers of the parachains.

There are various methods by which we can transfer ownership of the parachains:

  • Change the owner of the pure proxy and, consequently, the para manager account, along with modifying the sudo key
  • Execute an XCM lease swap of our cores with a buyer
  • Carry out a governance lease swap of our cores with a buyer

Markets & Governance

For those who have reviewed our correspondence with Bastian, it may be evident that we anticipated the Polkadot Technical Fellowship would whitelist cores for Mythos and similar projects. This was a likely development, though one that we believe has significantly impacted the nature of core markets as they currently operate.

Conclusion

We have repeatedly advised projects to reach out to us in advance of core assignment and renewal, as this is the most straightforward way to facilitate OTC sales of cores. These reminders have been shared through both email and this thread.

We will continue our activities within these markets and welcome any inquiries at coretimenegotiation@protonmail.me

38

I miss the days of 2021 when DOT demand was created by artificial scarcity, when 5 cores were auctioned off at a time, and there was no way to get into a parachain crowdloan except to buy DOT. The @coretimenegotiation efforts of cornering the market sort of looked like the 2021 days for a second – but we’re clearly in a different era of cops and scammers in 2025!

So can we have coretime logic done in USDC + USDT instead of DOT, using Hydration liquidity pools now, Polkadot Hub liquidity pools later?

This would make it even easier for coretime customers to get even more stable and fair pricing, where reserve + market prices are all done in stablecoins. Because now fair pricing is what Polkadot is all about now, not price gouging.

39

(I have also posted this on the RFC thread on GitHub but thought crossposting here would lead to more eyeballs challenging this):

Have you checked out Harberger Tax? This could help with Polkadot coretime in a couple of ways, here are some thoughts:

  1. Efficient Coretime Allocation
    Projects only hold coretime if they really value it.
    No “squatting” — if a team isn’t using their coretime efficiently, others can buy it from them.
    Active, high-value chains stay live; lower-priority chains naturally exit.

  2. Dynamic Pricing
    Coretime prices adjust according to real demand — no need for big auctions.
    Projects have to constantly think: “Is it still worth it to keep paying for this at this price?”

  3. Encourages Liquidity
    If your project changes direction, you can exit easily by setting a lower sale price.
    New projects can quickly enter by buying available coretime without waiting for new auctions.

  4. Supports Smaller Chains
    Small, agile chains could buy coretime cheaply if bigger players set high prices they can’t justify paying taxes on.
    Reduces monopolization of limited coretime resources.

  5. Polkadot Treasury Benefits
    The ongoing tax payments (based on asset value) could flow into the Polkadot Treasury.
    This provides a sustainable source of funds for ecosystem development.
    Taxation can (or better should) depend on coretime utilization, resulting in increased tax for unutilized coretime.

A chain can always defend their coretime by increasing the valuation

  • resulting in higher tax
  • purchase cost will be higher for an attacker

image
image2780×1380 257 KB

Dynamic Radical Coretime Lifecycle: Ownership, Valuation, and Tax Paid Over 90 Days. Blue Line: how the valuation changes over time, including defensive spikes when projects raise their self-assessed prices. Dashed Vertical Lines: moments when ownership changes happen — labeled with the new owner’s name. Red Line: how the cumulative tax paid steadily grows over time as projects continue operating and defending.

I would factor in utilisation of the chain, where

  • lower utilisation increases tax and lowers buyout protection and
  • higher utilisation results in lower tax and increased buyout protection

image
image1920×953 131 KB

Utilization vs Effective Tax Rate Dynamics. Green Line: Utilization percentage over time — fluctuating daily around each chain’s typical behavior, with noise added. Purple Line: Effective Tax Rate per Day — moving inversely to utilization. When utilization drops → tax rate increases. When utilization is high → tax rate stays lower. The dashed green line at 80% is a visual reference point for “healthy” utilization.

Further Reading: