It would appear based on the RFC pull request that this does more than simply, "increases the number of cores from 66 to 100". Can that be clarified in the proposal text? Were critical ecosystem partners consulted about the potential impacts of these changes?

Thanks to DAO for reading this comment. This proposal is an economic disgrace, primarily aimed at bypassing the entity that acquired a significant amount of DOT cores and at reducing the cost of the ecosystem’s only product: coretime. Do not vote yes on this mess and let's wait for Jonas's proposal. One of the few who tries to create value.

This entity drove up the price of CoreTimes, which was previously sold at 9 DOT. It made us dream of a potential 9,000 DOT per core, but with this proposal, we will likely have to wait years.

I remind you that DOT no longer generates any revenue since the auctions ended in October, which explains why all support levels are breaking and the price is dropping toward a minimum of 2 Dollars.

The CoreTime model was presented to us as a value creator, but to build a self-sustaining system, we need core purchases totaling 400,000 DOT per month. This proposal pushes value further away while diluting it by 33% with the addition of cores.

Probably to quietly push through this proposal, like the Elastic Scaling update that everyone is expecting, even though it has nothing to do with it. Once again, a clear manipulation of the masses by the technical team—vote no! Here is the real proposal:

This RFC proposes an amendment to RFC-1 Agile Coretime: renewal prices will no longer be adjusted solely based on a configurable renewal bump, but also on the final price of the current sale — if that price is higher.

Motivation

In RFC-1, we aimed for perfect predictability of renewal prices. Unfortunately, practice has confirmed what we feared: perfect predictability enables core hoarding and cheap market manipulation. As a result, both on Kusama and Polkadot, there is effectively no free market for cores anymore. A single actor is hoarding a large number of cores at low prices, pushing prices up without being affected themselves.

This situation creates problems for:

• new teams wanting to join the ecosystem,
• existing teams wanting to expand through elastic scaling,
• and even teams who just want to retain their core, but forgot to renew it during the short renewal window.

In short, the current situation is severely hindering team deployments on Polkadot. We are essentially facing a Denial of Service scenario.

Stakeholders

This RFC affects:

• existing teams that already have a core,
• and new teams wanting to join the ecosystem.

Explanation

This RFC aims to resolve the issue by limiting the predictability of renewal prices to a reasonable level, through a soft coupling with the current market price:
Renewal prices must now be at least as high as the final price of the current sale.

In a Dutch auction for core sales, three key price points are defined:

• Starting price (highest)
• Target price (middle)
• End price (lowest)

The target price is set at 10 times the end price, and the starting price is 10 times the target price — i.e., 100 times the end price.

The target price reflects the expected market value of a core. More specifically, in each new sale (sale X+1), the end price is set to one-tenth of the clearing price of the previous sale (sale X). This allows the price curve (and the end price) to adjust by a maximum factor of 10 between sales.

Example:

If the end price of a sale is 10 DOT, and all cores were bought at the starting price of 1000 DOT, the new end price for the next sale would be 100 DOT.

Impact on Existing Tenants

Before this RFC, this pricing model had little effect on existing tenants — and that remains true, except in extreme market fluctuations or if a tenant was lucky enough to purchase below the target price.

In the example above, tenants who acquired a core at 10 DOT would now face a renewal price of 100 DOT. However, those who bought at or above the target price (e.g., 100 DOT or more) would not be affected.

In short, price predictability is preserved, though within reasonable bounds:
Even if the market price increases by a factor of 100, renewal prices would only rise 10x.
Thus, this RFC ensures tenants still benefit from a 10x stability buffer compared to new entrants.

It is fair to say that this proposal maintains price stability, while preventing renewals from becoming completely disconnected from the market.

Concrete Effects of This RFC

1. Attacks become too expensive to be worth it
   Imagine 10 cores are listed at an end price of 10 DOT.
   To push renewal prices up to 100 DOT, an attacker would have to spend 10,000 DOT.
   Not only is this a high cost with limited impact, but the attacker would also end up paying more for their own renewals.
   In short, core hoarding to manipulate prices is no longer profitable.
   The attacker would be hit just as hard — if not harder — than the honest users they’re targeting.
2. Fairness in a growing market
   If demand increases organically (e.g., due to adoption), core prices would naturally rise, and renewals would follow.
   Existing tenants would still be favored (paying 10x less than new buyers), but as prices climb, the least profitable projects would eventually release their cores — freeing them up for new participants.