Why is the minimum price of coretime set at 10 DOT? Shouldn’t that be changing dynamically based on the demand?
Right now, there are coretime auctions that end without selling over 50% of the available coretime. Can we reduce the minimum price of a core significantly?
If the minimum allowable price was reduced to 0.001 DOT, it would allow anyone to build for extremely cheap until there is enough demand for the price to find a floor.
It wouldn’t be risking much… there is not yet a substantial revenue stream from coretime sales.
It used to be like that in the past, but the problem was that there were individuals who bought all the cores when they were extremely cheap and controlled the supply, and therefore the future price. Imagine one person buying 100% of the cores at $1; afterward, they could sell the cores at whatever price they wanted. That’s why a $10 minimum was implemented as a safety measure.
This means the auction is not truly informational:
Instead of learning from agents’ preferences, the system is anchored to a target that is, in practice, a policy variable, not an emergent result.
The result is a hybrid: part protocol, part central planning, which weakens the legitimacy and credibility of the price signal.
In the current mechanism, the Coretime buy decision is essentially binary:
you either accept the current price, or you wait and hope for a better one. That leads to:
No continuous demand curve – the system never sees how willingness to pay evolves across prices, only a yes/no at a single point.
Timing pressure that rewards infrastructure and attention, not true economic valuation (bots, latency, 24/7 monitoring).
Fragility under DOT price volatility and cross-chain competition – the mechanism doesn’t adapt structurally, it just gets patched.
Failure to clear efficiently or creation of short-term rents, depending on regime, instead of stable long-term pricing.
Unstable aggregation of signals – instead of smoothing the price path through broad participation, it amplifies noise and regime shifts.
Structural advantage for actors with better latency, monitoring and predictive models, i.e., financial sophistication over productive use.
All this makes the current Dutch auctions highly complex at the strategic layer for teams building on Polkadot:
either you accept instability, or you accept that the “price signal” is partially fake and driven by mechanism design rather than actual preferences.
I’ve argued that a Coretime price mechanism should instead:
Avoid durable monopolization and soft capture of Coretime by a few large actors.
Reduce barriers for new entrants, including smaller teams and intermittent users.
Prevent centralization of Coretime inventory management (i.e., warehouse/rentier dynamics).
Approximate Pareto efficiency under clear, convex assumptions.
Yield equivalent prices for equivalent conditions – same resource, same time, same constraints → same price.
Provide predictable long-term stability, so that teams can plan multi-year deployments without gambling on mechanism tweaks.
My RFC-0152 proposal moves in that direction by treating Coretime as part of a continuous, asynchronous p2p preference-driven exchange economy, where price is an output of agent interaction, not a parameter that governance has to manually steer.
It also doesn’t necessarily make sense to me that coretime is priced in DOT and not a DOT-backed stablecoin. If the price of DOT increases… the price of coretime is going to increase significantly. It’s not very predictable. If DOT did 30x then the minimum price of a core would be around $500+…