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.
You can check my proposal here RFC-0152 and the forum discussion here (7 Jul 2025): RFC-0152: Decentralized Convex-Preference Coretime Market for Polkadot