# RFC: Decentralized Convex-Preference Coretime Market for Polkadot \[Draft\] **URL:** \ **Category:** Ecosystem\ **Created:** [June 30, 2025, 7:31pm UTC](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573 "2025-06-30T19:31:59Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![labormedia](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/labormedia/32/2638_2.png) [@labormedia](https://forum.polkadot.network/u/labormedia)\ **Post date:** [June 30, 2025, 7:31pm UTC](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573/1 "2025-06-30T19:31:59Z")
# RFC: Decentralized Convex-Preference Coretime Market for Polkadot [Draft] - **Title:** Decentralized Convex-Preference Coretime Market for Polkadot - **Author:** Diego Correa Tristain - **Status:** Draft - **Created:** 30th June 2025 - **Discussion:** RFC: Decentralized Convex-Preference Coretime Market for Polkadot [Draft] - **Supersedes:** [Invitation to Critically Evaluate Core Time Pricing Model Framework](https://forum.polkadot.network/t/invitation-to-critically-evaluate-core-time-pricing-model-framework/13404) - **Replaces:** RFC-0017 (partially, in application) ## Summary This RFC proposes a decentralized market mechanism for allocating Coretime on Polkadot, replacing the existing Dutch auction method (RFC17). The new model leverages convex preference interactions between agents, eliminating the need for explicit bidding and centralized price determination, thus ensuring fairness, transparency, and decentralization. ## Motivation The current auction-based model (RFC17) introduces several critical issues: - **Front-running and timing asymmetry:** Actors with superior infrastructure or timing strategies have unfair advantages. - **Complexity and cognitive overhead:** Auctions are challenging to understand and participate in effectively. - **Resource hoarding and inefficiency:** Auctions allow strategic actors to monopolize resources, restricting equitable participation. The proposed decentralized convex-preference model addresses these issues by facilitating equitable and transparent access without central coordination. ## Guide-Level Explanation Agents participating in the Coretime market (such as parachains, parathreads, or smart contracts) declare two parameters: - **Asset Holdings:** Their initial allocation of Coretime and tokens (e.g., DOT). - **Preference Parameter (α):** A scalar value between 0 and 1 indicating their valuation preference between Coretime and tokens. These parameters are recorded transparently on-chain. Transactions between agents are conducted through deterministic convex optimizations, ensuring local Pareto-optimal exchanges. A global equilibrium price naturally emerges from these local interactions without any centralized authority or external pricing mechanism. ## Reference-Level Explanation ### Economic Model Agents’ preferences are represented using a Cobb-Douglas utility function: $U\_i(x, y) = x^{α\_i} y^{1-α\_i}$ where: - $x$ represents the quantity of Coretime. - $y$ represents the quantity of tokens allocated for the purpose of Coretime exchange. - $α\_i \in [0,1]$ is the scalar preference parameter. ### Mechanism Implementation Implementation involves the following components: 1. **Preference Declaration:** Agents explicitly register their scalar preference (α) and initial asset holdings on-chain. 2. **Interaction Module:** A dedicated runtime module or smart contract that manages interactions and ensures Pareto-optimal, deterministic outcomes. 3. **Convergence Enforcement:** Interaction ordering follows a deterministic protocol prioritizing transactions that significantly enhance price convergence in a deterministic sequential order from higher to lower exchange rates. 4. **On-chain Verifiability:** Transaction histories and convergence processes are transparently auditable and verifiable on-chain. ## Drawbacks - Initial implementation complexity due to the introduction of a new economic mechanism and runtime module. - User education and interface development required for understanding scalar preference parameters. ## Rationale and Alternatives This model offers fundamental advantages over the existing auction model: - **Elimination of front-running and strategic timing advantages.** - **Simplified user interaction through intuitive scalar preferences.** - **Continuous liquidity and equitable access without auction-related complexities.** Alternative improvements to RFC17, such as incremental auction adjustments or improved fairness constraints, fail to fully address systemic inequities inherent in auction mechanisms. ## Unresolved Questions - Optimal method for initial rollout (experimental sandbox vs. partial deployment on Polkadot). - Specific criteria and heuristics for the deterministic interaction ordering, starting from higher to lower exchange rates for the initial transaction order sequence. ## Future Directions - Extend the model to support multi-asset allocations with additional priority mechanisms. - Apply similar decentralized convex-preference principles to broader decentralized resource allocation challenges. ## Conclusion This RFC introduces a novel, principled, decentralized market design for Polkadot’s Coretime allocation, addressing systemic shortcomings of RFC17’s auction-based mechanism. The proposed model emphasizes transparency, fairness, and decentralization, aligning closely with Polkadot’s core ethos. ## References Emergent Properties of Distributed Agents with Two-Stage Convex Zero-Sum Optimal Exchange Network: [[Tristain, 2024]](https://github.com/onedge-network/Emergent_Properties_paper). * * * _Submitted by Diego Correa Tristain_ ---
**Author:** ![cpiccard](https://avatars.discourse-cdn.com/v4/letter/c/e56c9b/32.png) [@cpiccard](https://forum.polkadot.network/u/cpiccard)\ **Post date:** [July 1, 2025, 4:49pm UTC](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573/2 "2025-07-01T16:49:57Z")
Maybe it would help to bring more attention to your idea in order to gain more support. Have you considered contacting the court reporter the Kusamarian to present your idea to a broader audience? I also think it would make sense to hear a few alternative ideas regarding core time sales. So far, stakeholders have only had the option to say yes or no to the current core time model—there hasn’t been much of a choice. ---
**Author:** ![labormedia](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/labormedia/32/2638_2.png) [@labormedia](https://forum.polkadot.network/u/labormedia)\ **Post date:** [July 4, 2025, 1:43pm UTC](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573/3 "2025-07-04T13:43:04Z")
# 🧭 Clarifying Misconceptions and Opening Space for Innovation As RFC-0017 enters its **Leading phase** , it marks an important moment in the evolution of Polkadot’s resource economy. It’s also a timely opportunity for the community to engage critically—not only with the proposed mechanism itself but with the assumptions guiding it. To support that dialogue, I’d like to surface and clarify a few logical inconsistencies that have emerged in past discussions regarding my alternative **decentralized convex-preference model** for Coretime pricing. This response is not intended as opposition, but as contribution—so that our collective decisions are grounded in both rigor and openness to innovation. The proposed solution reframes the problem: instead of asking who wins in an auction, it asks how can all agents express their preferences fairly and converge on a mutually beneficial price? * * * ## 🔍 Misconception 1: “Auctions are optimal because they are widely used.” **Fallacy:** Appeal to tradition / False generalization **Clarification:** Yes, auctions are well-understood. But they’re not universally optimal. Their effectiveness depends on the context—and in permissionless, latency-sensitive environments like Polkadot, Dutch auctions can reinforce systemic asymmetries: - **Front-running remains a structural risk** , particularly for actors with superior infrastructure. - **Strategic hoarding distorts access** , reducing diversity among parachain participants. - **Timing pressure introduces complexity** , making entry more difficult for new teams. Just because auctions have worked elsewhere doesn’t mean they’re ideal here. The convex-preference model avoids these vulnerabilities by enabling emergent, stable pricing through deterministic interactions—not reaction speed. * * * ## 🔍 Misconception 2: “Convex preferences are too complex for users to express.” **Fallacy:** Straw man **Clarification:** In practice, the proposed model asks users to declare just **one scalar** : `α ∈ [0,1]`, representing the trade-off between Coretime and tokens. This is **easier than auctions** , which demand: - Constant monitoring - Precise timing - Strategic bidding knowledge Complexity doesn’t disappear in auctions—it’s just **offloaded to the users**. * * * ## 🔍 Misconception 3: “The model is too immature to consider.” **Fallacy:** Argument from incredulity / Status quo bias **Clarification:** The convex-preference model is not speculative; it has formal economic grounding, a mathematical framework, and documented simulation foundations: 📘 [`Emergent_Properties_paper`](https://github.com/onedge-network/Emergent_Properties_paper) And what better place than **Kusama** to safely prototype such models? Declaring alternatives “premature” at the outset risks precluding discovery of **better-fit solutions**. * * * ## 🔍 Misconception 4: “Front-running isn’t a problem anymore.” **Fallacy:** Minimization **Clarification:** While RFC-0017 attempts to mitigate it, **Dutch auctions remain inherently front-runnable** , as price discovery favors those who can act faster. The **convex-preference approach** ensures price formation is **non-timing-sensitive** by construction. No race, no edge. * * * ## 🔍 Misconception 5: “Decentralization has no bearing on price formation.” **Fallacy:** Conceptual reductionism **Clarification:** In fact, **decentralization is a prerequisite** for fair price formation in trust-minimized ecosystems. The proposed model: - Treats all agents symmetrically - Uses **transparent, on-chain preferences** - Generates prices **through interactions** , not imposed mechanisms That’s what decentralization _means_ in protocol design. * * * ## ✅ Where Do We Go From Here? This isn’t about “replacing” RFC-0017 overnight. It’s about enriching the design landscape with well-grounded, auditable alternatives that address different concerns. The **convex-preference model** offers: - Deterministic, **front-running-free** price convergence - Intuitive user interaction through a single α parameter - Strong alignment with decentralization principles - Built-in fairness and composability for more complex future use cases (JAM, energy/resource coordination, price stabilization) I invite the community—developers, researchers, and parachain builders—to review the full RFC here: 🔗 **Review the full RFC here** : [RFC: Decentralized Convex-Preference Coretime Market for Polkadot (Draft)](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573) If you’re a researcher, parachain builder, or governance participant, I invite you to: - Provide feedback - Explore simulations - Propose implementations - Share criticisms or extensions * * * **Let’s keep Polkadot bold, experimental, and visionary for better economics—just as it was meant to be.** — _Diego Correa Tristain_ ---
**Author:** ![polka.dom](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/polka.dom/32/8026_2.png) [@polka.dom](https://forum.polkadot.network/u/polka.dom)\ **Post date:** [July 5, 2025, 9:56pm UTC](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573/4 "2025-07-05T21:56:16Z")
Why not submit this RFC in the RFC repo? [Pull requests · polkadot-fellows/RFCs · GitHub](https://github.com/polkadot-fellows/RFCs/pulls) ---
**Author:** ![labormedia](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/labormedia/32/2638_2.png) [@labormedia](https://forum.polkadot.network/u/labormedia)\ **Post date:** [July 5, 2025, 11:41pm UTC](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573/5 "2025-07-05T23:41:13Z")
> [@cpiccard](#): > > Maybe it would help to bring more attention to your idea in order to gain more support. > > Have you considered contacting the court reporter the Kusamarian to present your idea to a broader audience? > > I also think it would make sense to hear a few alternative ideas regarding core time sales. So far, stakeholders have only had the option to say yes or no to the current core time model—there hasn’t been much of a choice. Thank you for this thoughtful and encouraging suggestion — I fully agree. This model first took shape during my economics studies at Universidad de Chile, where I became deeply interested in the dynamics of multi-agent exchange. In particular, I was intrigued by how the introduction of a third agent fundamentally disrupts the dyadic equilibrium typical in two-party transactions — a shift that opens space for richer coordination mechanisms. Building on this insight, I developed a minimal yet expressive framework based on convex preference interactions. To the best of my knowledge, this exact formulation hasn’t been proposed elsewhere. Its strength lies in the fact that emergent, stable, Pareto-optimal pricing arises organically from the structure of interactions — without requiring centralized control or auction mechanisms. Following your recommendation, I’ve reached out to The Kusamarian to share the RFC draft and open space for a wider conversation. I genuinely believe this proposal offers a constructive contribution to the ongoing exploration of Coretime models. Thanks again for your engagement — it’s deeply appreciated. ---
**Author:** ![labormedia](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/labormedia/32/2638_2.png) [@labormedia](https://forum.polkadot.network/u/labormedia)\ **Post date:** [July 6, 2025, 4:21pm UTC](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573/6 "2025-07-06T16:21:13Z")
> [@polka.dom](#): > > Why not submit this RFC in the RFC repo? [Pull requests · polkadot-fellows/RFCs · GitHub](https://github.com/polkadot-fellows/RFCs/pulls) Great point — and thank you for the thoughtful suggestion. I initially shared the RFC on the Polkadot Forum to encourage open discussion and gather early community feedback before proceeding with a formal submission. Given the thoughtful engagement so far, I’ll be preparing a GitHub PR to submit it to the official RFC repository. I truly appreciate the nudge — and I welcome any feedback or support here in the meantime, and once it’s live on GitHub! ---
**Author:** ![labormedia](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/labormedia/32/2638_2.png) [@labormedia](https://forum.polkadot.network/u/labormedia)\ **Post date:** [July 7, 2025, 5:41pm UTC](https://forum.polkadot.network/t/rfc-decentralized-convex-preference-coretime-market-for-polkadot-draft/13573/7 "2025-07-07T17:41:49Z")
I am superseding this discussion in favor to the official RFC-0152 proposal available at [RFC-0152](https://github.com/polkadot-fellows/RFCs/pull/152) and the new Forum Thread [RFC-0152: Decentralized Convex-Preference Coretime Market for Polkadot](https://forum.polkadot.network/t/rfc-0152-decentralized-convex-preference-coretime-market-for-polkadot/13656).