mirror of
https://github.com/pezkuwichain/pezkuwi-fellows.git
synced 2026-05-30 15:01:01 +00:00
bkchr
409 lines
46 KiB
HTML
409 lines
46 KiB
HTML
|
||
<!DOCTYPE HTML>
|
||
<html lang="en" class="polkadot" dir="ltr">
|
||
<head>
|
||
<!-- Book generated using mdBook -->
|
||
<meta charset="UTF-8">
|
||
<title>RFC-0017: Coretime Market Redesign - Polkadot Fellowship RFCs</title>
|
||
|
||
|
||
<!-- Custom HTML head -->
|
||
|
||
<meta name="description" content="An online book of RFCs approved or proposed within the Polkadot Fellowship.">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
<meta name="theme-color" content="#ffffff">
|
||
|
||
<link rel="icon" href="../favicon.svg">
|
||
<link rel="shortcut icon" href="../favicon.png">
|
||
<link rel="stylesheet" href="../css/variables.css">
|
||
<link rel="stylesheet" href="../css/general.css">
|
||
<link rel="stylesheet" href="../css/chrome.css">
|
||
<link rel="stylesheet" href="../css/print.css" media="print">
|
||
|
||
<!-- Fonts -->
|
||
<link rel="stylesheet" href="../FontAwesome/css/font-awesome.css">
|
||
<link rel="stylesheet" href="../fonts/fonts.css">
|
||
|
||
<!-- Highlight.js Stylesheets -->
|
||
<link rel="stylesheet" href="../highlight.css">
|
||
<link rel="stylesheet" href="../tomorrow-night.css">
|
||
<link rel="stylesheet" href="../ayu-highlight.css">
|
||
|
||
<!-- Custom theme stylesheets -->
|
||
<link rel="stylesheet" href="../theme/polkadot.css">
|
||
|
||
</head>
|
||
<body class="sidebar-visible no-js">
|
||
<div id="body-container">
|
||
<!-- Provide site root to javascript -->
|
||
<script>
|
||
var path_to_root = "../";
|
||
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "polkadot" : "polkadot";
|
||
</script>
|
||
|
||
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
||
<script>
|
||
try {
|
||
var theme = localStorage.getItem('mdbook-theme');
|
||
var sidebar = localStorage.getItem('mdbook-sidebar');
|
||
|
||
if (theme.startsWith('"') && theme.endsWith('"')) {
|
||
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
||
}
|
||
|
||
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
||
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
||
}
|
||
} catch (e) { }
|
||
</script>
|
||
|
||
<!-- Set the theme before any content is loaded, prevents flash -->
|
||
<script>
|
||
var theme;
|
||
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
||
if (theme === null || theme === undefined) { theme = default_theme; }
|
||
var html = document.querySelector('html');
|
||
html.classList.remove('polkadot')
|
||
html.classList.add(theme);
|
||
var body = document.querySelector('body');
|
||
body.classList.remove('no-js')
|
||
body.classList.add('js');
|
||
</script>
|
||
|
||
<input type="checkbox" id="sidebar-toggle-anchor" class="hidden">
|
||
|
||
<!-- Hide / unhide sidebar before it is displayed -->
|
||
<script>
|
||
var body = document.querySelector('body');
|
||
var sidebar = null;
|
||
var sidebar_toggle = document.getElementById("sidebar-toggle-anchor");
|
||
if (document.body.clientWidth >= 1080) {
|
||
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
||
sidebar = sidebar || 'visible';
|
||
} else {
|
||
sidebar = 'hidden';
|
||
}
|
||
sidebar_toggle.checked = sidebar === 'visible';
|
||
body.classList.remove('sidebar-visible');
|
||
body.classList.add("sidebar-" + sidebar);
|
||
</script>
|
||
|
||
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
||
<div class="sidebar-scrollbox">
|
||
<ol class="chapter"><li class="chapter-item expanded affix "><a href="../introduction.html">Introduction</a></li><li class="spacer"></li><li class="chapter-item expanded affix "><li class="part-title">Newly Proposed</li><li class="spacer"></li><li class="chapter-item expanded affix "><li class="part-title">Proposed</li><li class="chapter-item expanded "><a href="../proposed/0000-rewards.html">RFC-0000: Validator Rewards</a></li><li class="chapter-item expanded "><a href="../proposed/0150-voting-while-delegating.html">RFC-150: Allow Voting While Delegating</a></li><li class="chapter-item expanded "><a href="../proposed/xxxx-improve-the-security-of-proof-of-possession.html">RFC-XXXX: Adding customized mandatory context to proof of possession statement</a></li><li class="spacer"></li><li class="chapter-item expanded affix "><li class="part-title">Approved</li><li class="chapter-item expanded "><a href="../approved/0001-agile-coretime.html">RFC-1: Agile Coretime</a></li><li class="chapter-item expanded "><a href="../approved/0005-coretime-interface.html">RFC-5: Coretime Interface</a></li><li class="chapter-item expanded "><a href="../approved/0007-system-collator-selection.html">RFC-0007: System Collator Selection</a></li><li class="chapter-item expanded "><a href="../approved/0008-parachain-bootnodes-dht.html">RFC-0008: Store parachain bootnodes in relay chain DHT</a></li><li class="chapter-item expanded "><a href="../approved/0009-improved-net-light-client-requests.html">RFC-0009: Improved light client requests networking protocol</a></li><li class="chapter-item expanded "><a href="../approved/0010-burn-coretime-revenue.html">RFC-0010: Burn Coretime Revenue</a></li><li class="chapter-item expanded "><a href="../approved/0012-process-for-adding-new-collectives.html">RFC-0012: Process for Adding New System Collectives</a></li><li class="chapter-item expanded "><a href="../approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html">RFC-0013: Prepare Core runtime API for MBMs</a></li><li class="chapter-item expanded "><a href="../approved/0014-improve-locking-mechanism-for-parachains.html">RFC-0014: Improve locking mechanism for parachains</a></li><li class="chapter-item expanded "><a href="../approved/0017-coretime-market-redesign.html" class="active">RFC-0017: Coretime Market Redesign</a></li><li class="chapter-item expanded "><a href="../approved/0022-adopt-encointer-runtime.html">RFC-0022: Adopt Encointer Runtime</a></li><li class="chapter-item expanded "><a href="../approved/0026-sassafras-consensus.html">RFC-0026: Sassafras Consensus Protocol</a></li><li class="chapter-item expanded "><a href="../approved/0032-minimal-relay.html">RFC-0032: Minimal Relay</a></li><li class="chapter-item expanded "><a href="../approved/0042-extrinsics-state-version.html">RFC-0042: Add System version that replaces StateVersion on RuntimeVersion</a></li><li class="chapter-item expanded "><a href="../approved/0043-storage-proof-size-hostfunction.html">RFC-0043: Introduce storage_proof_size Host Function for Improved Parachain Block Utilization</a></li><li class="chapter-item expanded "><a href="../approved/0045-nft-deposits-asset-hub.html">RFC-0045: Lowering NFT Deposits on Asset Hub</a></li><li class="chapter-item expanded "><a href="../approved/0047-assignment-of-availability-chunks.html">RFC-0047: Assignment of availability chunks to validators</a></li><li class="chapter-item expanded "><a href="../approved/0048-session-keys-runtime-api.html">RFC-0048: Generate ownership proof for SessionKeys</a></li><li class="chapter-item expanded "><a href="../approved/0050-fellowship-salaries.html">RFC-0050: Fellowship Salaries</a></li><li class="chapter-item expanded "><a href="../approved/0056-one-transaction-per-notification.html">RFC-0056: Enforce only one transaction per notification</a></li><li class="chapter-item expanded "><a href="../approved/0059-nodes-capabilities-discovery.html">RFC-0059: Add a discovery mechanism for nodes based on their capabilities</a></li><li class="chapter-item expanded "><a href="../approved/0078-merkleized-metadata.html">RFC-0078: Merkleized Metadata</a></li><li class="chapter-item expanded "><a href="../approved/0084-general-transaction-extrinsic-format.html">RFC-0084: General transactions in extrinsic format</a></li><li class="chapter-item expanded "><a href="../approved/0091-dht-record-creation-time.html">RFC-0091: DHT Authority discovery record creation time</a></li><li class="chapter-item expanded "><a href="../approved/0097-unbonding_queue.html">RFC-0097: Unbonding Queue</a></li><li class="chapter-item expanded "><a href="../approved/0099-transaction-extension-version.html">RFC-0099: Introduce a transaction extension version</a></li><li class="chapter-item expanded "><a href="../approved/0100-xcm-multi-type-asset-transfer.html">RFC-0100: New XCM instruction: InitiateAssetsTransfer</a></li><li class="chapter-item expanded "><a href="../approved/0101-xcm-transact-remove-max-weight-param.html">RFC-0101: XCM Transact remove require_weight_at_most parameter</a></li><li class="chapter-item expanded "><a href="../approved/0103-introduce-core-index-commitment.html">RFC-0103: Introduce a CoreIndex commitment and a SessionIndex field in candidate receipts</a></li><li class="chapter-item expanded "><a href="../approved/0105-xcm-improved-fee-mechanism.html">RFC-0105: XCM improved fee mechanism</a></li><li class="chapter-item expanded "><a href="../approved/0107-xcm-execution-hints.html">RFC-0107: XCM Execution hints</a></li><li class="chapter-item expanded "><a href="../approved/0108-xcm-remove-testnet-ids.html">RFC-0108: Remove XCM testnet NetworkIds</a></li><li class="chapter-item expanded "><a href="../approved/0122-alias-origin-on-asset-transfers.html">RFC-0122: Asset transfers can alias XCM origin on destination to original origin</a></li><li class="chapter-item expanded "><a href="../approved/0123-pending-code-as-storage-location-for-runtime-upgrades.html">RFC-0123: Introduce :pending_code as intermediate storage key for the runtime code</a></li><li class="chapter-item expanded "><a href="../approved/0125-xcm-asset-metadata.html">RFC-0125: XCM Asset Metadata</a></li><li class="chapter-item expanded "><a href="../approved/0126-introduce-pvq.html">RFC-0126: Introduce PVQ (PolkaVM Query)</a></li><li class="chapter-item expanded "><a href="../approved/0135-compressed-blob-prefixes.html">RFC-0135: Compressed Blob Prefixes</a></li><li class="chapter-item expanded "><a href="../approved/0139-faster-erasure-coding.html">RFC-0139: Faster Erasure Coding</a></li><li class="chapter-item expanded "><a href="../approved/0146-deflationary-fee-proposal.html">RFC-0146: Deflationary Transaction Fee Model for the Relay Chain and its System Parachains</a></li><li class="chapter-item expanded "><a href="../approved/0149-rfc-1-renewal-adjustment.html">RFC-0149: Renewal Adjustment</a></li><li class="spacer"></li><li class="chapter-item expanded affix "><li class="part-title">Stale</li><li class="chapter-item expanded "><a href="../stale/0000-pre-elves_soft.html">RFC-0000: Pre-ELVES soft concensus</a></li><li class="chapter-item expanded "><a href="../stale/0004-remove-unnecessary-allocator-usage.html">RFC-0004: Remove the host-side runtime memory allocator</a></li><li class="chapter-item expanded "><a href="../stale/0006-dynamic-pricing-for-bulk-coretime-sales.html">RFC-0006: Dynamic Pricing for Bulk Coretime Sales</a></li><li class="chapter-item expanded "><a href="../stale/0034-xcm-absolute-location-account-derivation.html">RFC-34: XCM Absolute Location Account Derivation</a></li><li class="chapter-item expanded "><a href="../stale/0035-conviction-voting-delegation-modifications.html"> RFC-0035: Conviction Voting Delegation Modifications</a></li><li class="chapter-item expanded "><a href="../stale/0044-rent-based-registration.html">RFC-0044: Rent based registration model</a></li><li class="chapter-item expanded "><a href="../stale/0054-remove-heap-pages.html">RFC-0054: Remove the concept of "heap pages" from the client</a></li><li class="chapter-item expanded "><a href="../stale/0070-x-track-kusamanetwork.html">RFC-0070: X Track for @kusamanetwork</a></li><li class="chapter-item expanded "><a href="../stale/0073-referedum-deposit-track.html">RFC-0073: Decision Deposit Referendum Track</a></li><li class="chapter-item expanded "><a href="../stale/0074-stateful-multisig-pallet.html">RFC-0074: Stateful Multisig Pallet</a></li><li class="chapter-item expanded "><a href="../stale/0077-increase-max-length-of-identity-pgp-fingerprint-value.html">RFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytes</a></li><li class="chapter-item expanded "><a href="../stale/0088-broker-pallet-slashable-deposit-purchaser-reputation-reserved-cores.html">RFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker pallet</a></li><li class="chapter-item expanded "><a href="../stale/00xx-secondary-marketplace-for-regions.html">RFC-0001: Secondary Market for Regions</a></li><li class="chapter-item expanded "><a href="../stale/00xx-smart-contracts-coretime-chain.html">RFC-0002: Smart Contracts on the Coretime Chain</a></li><li class="chapter-item expanded "><a href="../stale/0102-offchain-parachain-runtime-upgrades.html">RFC-0000: Feature Name Here</a></li><li class="chapter-item expanded "><a href="../stale/0106-xcm-remove-fees-mode.html">RFC-0106: Remove XCM fees mode</a></li><li class="chapter-item expanded "><a href="../stale/0111-pure-proxy-replication.html">RFC-0111: Pure Proxy Replication</a></li><li class="chapter-item expanded "><a href="../stale/0112-compress-state-response-message-in-state-sync.html">RFC-0112: Compress the State Response Message in State Sync</a></li><li class="chapter-item expanded "><a href="../stale/0114-secp256r1-hostfunction.html">RFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signatures</a></li><li class="chapter-item expanded "><a href="../stale/0117-unbrick-collective.html">RFC-0117: The Unbrick Collective</a></li><li class="chapter-item expanded "><a href="../stale/0120-referenda-confirmation-by-candle-mechanism.html">RFC-0120: Referenda Confirmation by Candle Mechanism</a></li><li class="chapter-item expanded "><a href="../stale/0124-extrinsic-version-5.html">RFC-0124: Extrinsic version 5</a></li><li class="chapter-item expanded "><a href="../stale/0138-invulnerable-collator-election.html">RFC-0138: Election mechanism for invulnerable collators on system chains</a></li><li class="chapter-item expanded "><a href="../stale/0145-remove-unnecessary-allocator-usage.html">RFC-0145: Remove the host-side runtime memory allocator</a></li><li class="chapter-item expanded "><a href="../stale/RFC-114 Adjust Tipper Track Confirmation Periods.html">RFC-114: Adjust Tipper Track Confirmation Periods</a></li><li class="chapter-item expanded "><a href="../stale/TODO-stale-nomination-reward-curve.html">RFC-TODO: Stale Nomination Reward Curve</a></li></ol>
|
||
</div>
|
||
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
|
||
</nav>
|
||
|
||
<!-- Track and set sidebar scroll position -->
|
||
<script>
|
||
var sidebarScrollbox = document.querySelector('#sidebar .sidebar-scrollbox');
|
||
sidebarScrollbox.addEventListener('click', function(e) {
|
||
if (e.target.tagName === 'A') {
|
||
sessionStorage.setItem('sidebar-scroll', sidebarScrollbox.scrollTop);
|
||
}
|
||
}, { passive: true });
|
||
var sidebarScrollTop = sessionStorage.getItem('sidebar-scroll');
|
||
sessionStorage.removeItem('sidebar-scroll');
|
||
if (sidebarScrollTop) {
|
||
// preserve sidebar scroll position when navigating via links within sidebar
|
||
sidebarScrollbox.scrollTop = sidebarScrollTop;
|
||
} else {
|
||
// scroll sidebar to current active section when navigating via "next/previous chapter" buttons
|
||
var activeSection = document.querySelector('#sidebar .active');
|
||
if (activeSection) {
|
||
activeSection.scrollIntoView({ block: 'center' });
|
||
}
|
||
}
|
||
</script>
|
||
|
||
<div id="page-wrapper" class="page-wrapper">
|
||
|
||
<div class="page">
|
||
<div id="menu-bar-hover-placeholder"></div>
|
||
<div id="menu-bar" class="menu-bar sticky">
|
||
<div class="left-buttons">
|
||
<label id="sidebar-toggle" class="icon-button" for="sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
||
<i class="fa fa-bars"></i>
|
||
</label>
|
||
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
||
<i class="fa fa-paint-brush"></i>
|
||
</button>
|
||
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
||
<li role="none"><button role="menuitem" class="theme" id="polkadot">Polkadot</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="light">Light</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
||
</ul>
|
||
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
||
<i class="fa fa-search"></i>
|
||
</button>
|
||
</div>
|
||
|
||
<h1 class="menu-title">Polkadot Fellowship RFCs</h1>
|
||
|
||
<div class="right-buttons">
|
||
<a href="../print.html" title="Print this book" aria-label="Print this book">
|
||
<i id="print-button" class="fa fa-print"></i>
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div id="search-wrapper" class="hidden">
|
||
<form id="searchbar-outer" class="searchbar-outer">
|
||
<input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
||
</form>
|
||
<div id="searchresults-outer" class="searchresults-outer hidden">
|
||
<div id="searchresults-header" class="searchresults-header"></div>
|
||
<ul id="searchresults">
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
||
<script>
|
||
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
||
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
||
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
||
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
||
});
|
||
</script>
|
||
|
||
<div id="content" class="content">
|
||
<main>
|
||
<p><a href="https://github.com/polkadot-fellows/RFCs/blob/main/text/0017-coretime-market-redesign.md">(source)</a></p>
|
||
<p><strong>Table of Contents</strong></p>
|
||
<ul>
|
||
<li><a href="#rfc-0017-coretime-market-redesign">RFC-0017: Coretime Market Redesign</a>
|
||
<ul>
|
||
<li><a href="#summary">Summary</a></li>
|
||
<li><a href="#motivation">Motivation</a></li>
|
||
<li><a href="#stakeholders">Stakeholders</a></li>
|
||
<li><a href="#explanation">Explanation</a>
|
||
<ul>
|
||
<li><a href="#overview">Overview</a></li>
|
||
<li><a href="#market-period-14-days">Market Period (14 days)</a></li>
|
||
<li><a href="#renewal-period-7-days">Renewal Period (7 days)</a></li>
|
||
<li><a href="#reserve-price-adjustment">Reserve Price Adjustment</a></li>
|
||
<li><a href="#settlement-period--secondary-market-7-days">Settlement Period / Secondary Market (7 days)</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#additional-considerations">Additional Considerations</a>
|
||
<ul>
|
||
<li><a href="#new-track-coretime-admin">New Track: Coretime Admin</a></li>
|
||
<li><a href="#transition-to-the-new-model">Transition to the new Model</a></li>
|
||
<li><a href="#details-on-some-mechanics">Details on Some Mechanics</a></li>
|
||
<li><a href="#implications">Implications</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#appendix">Appendix</a>
|
||
<ul>
|
||
<li><a href="#further-discussion-points">Further Discussion Points</a></li>
|
||
<li><a href="#insights-clearing-price-dutch-auctions">Insights: Clearing Price Dutch Auctions</a></li>
|
||
<li><a href="#prior-art-and-references">Prior Art and References</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<h1 id="rfc-0017-coretime-market-redesign"><a class="header" href="#rfc-0017-coretime-market-redesign">RFC-0017: Coretime Market Redesign</a></h1>
|
||
<div class="table-wrapper"><table><thead><tr><th></th><th></th></tr></thead><tbody>
|
||
<tr><td><strong>Original Proposition Date</strong></td><td>05.08.2023</td></tr>
|
||
<tr><td><strong>Revision Date</strong></td><td>04.06.2025</td></tr>
|
||
<tr><td><strong>Description</strong></td><td>This RFC redesigns Polkadot's coretime market to ensure that coretime is efficiently priced through a clearing-price Dutch auction. It also introduces a mechanism that guarantees current coretime holders the right to renew their cores outside the market—albeit at the market price with an additional charge. This design aligns renewal and market prices, preserving long-term access for current coretime owners while ensuring that market dynamics exert sufficient pressure on all purchasers, resulting in an efficient allocation.</td></tr>
|
||
<tr><td><strong>Authors</strong></td><td>Jonas Gehrlein</td></tr>
|
||
</tbody></table>
|
||
</div>
|
||
<h2 id="summary"><a class="header" href="#summary">Summary</a></h2>
|
||
<p>This document proposes a restructuring of the bulk markets in Polkadot's coretime allocation system to improve efficiency and fairness. The proposal suggests splitting the <code>BULK_PERIOD</code> into three consecutive phases: <code>MARKET_PERIOD</code>, <code>RENEWAL_PERIOD</code>, and <code>SETTLEMENT_PERIOD</code>. This structure enables market-driven price discovery through a clearing-price Dutch auction, followed by renewal offers during the <code>RENEWAL_PERIOD</code>.</p>
|
||
<p>With all coretime consumers paying a unified price, we propose removing all liquidity restrictions on cores purchased either during the initial market phase or renewed during the renewal phase. This allows a meaningful <code>SETTLEMENT_PERIOD</code>, during which final agreements and deals between coretime consumers can be orchestrated on the social layer—complementing the agility this system seeks to establish.</p>
|
||
<p>In the new design, we obtain a uniform price, the <code>clearing_price</code>, which anchors new entrants and current tenants. To complement market-based price discovery, the design includes a dynamic reserve price adjustment mechanism based on actual core consumption. Together, these two components ensure robust price discovery while mitigating price collapse in cases of slight underutilization or collusive behavior.</p>
|
||
<h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
|
||
<p>After exposing the initial system introduced in <a href="https://github.com/polkadot-fellows/RFCs/blob/6f29561a4747bbfd95307ce75cd949dfff359e39/text/0001-agile-coretime.md">RFC-1</a> to real-world conditions, several weaknesses have become apparent. These lie especially in the fact that cores captured at very low prices are removed from the open market and can effectively be retained indefinitely, as renewal costs are minimal. The key issue here is the absence of price anchoring, which results in two divergent price paths: one for the initial purchase on the open market, and another fully deterministic one via the renewal bump mechanism.</p>
|
||
<p>This proposal addresses these issues by anchoring all prices to a value derived from the market, while still preserving necessary privileges for current coretime consumers. The goal is to produce robust results across varying demand conditions (low, high, or volatile).</p>
|
||
<p>In particular, this proposal introduces the following key changes:</p>
|
||
<ul>
|
||
<li><strong>Reverses the order</strong> of the market and renewal phases: all cores are first offered on the open market, and only then are renewal options made available.</li>
|
||
<li><strong>Introduces a dynamic <code>reserve_price</code></strong>, which is the minimum price coretime can be sold for in a period. This price adjusts based on consumption and does not rely on market participation.</li>
|
||
<li><strong>Makes unproductive core captures sufficiently expensive</strong>, as all cores are exposed to the market price.</li>
|
||
</ul>
|
||
<p>The premise of this proposal is to offer a straightforward design that discovers the price of coretime within a period as a <code>clearing_price</code>. Long-term coretime holders still retain the privilege to keep their cores <strong>if</strong> they can pay the price discovered by the market (with some premium for that privilege). The proposed model aims to strike a balance between leveraging market forces for allocation while operating within defined bounds. In particular, prices are capped <em>within</em> a <code>BULK_PERIOD</code>, which gives some certainty about prices to existing teams. It must be noted, however, that under high demand, prices could increase exponentially <em>between</em> multiple market cycles. This is a necessary feature to ensure proper price discovery and efficient coretime allocation.</p>
|
||
<p>Ultimately, the framework proposed here seeks to adhere to all requirements originally stated in RFC-1.</p>
|
||
<h2 id="stakeholders"><a class="header" href="#stakeholders">Stakeholders</a></h2>
|
||
<p>Primary stakeholder sets are:</p>
|
||
<ul>
|
||
<li>Protocol researchers, developers, and the Polkadot Fellowship.</li>
|
||
<li>Polkadot Parachain teams both present and future, and their users.</li>
|
||
<li>Polkadot DOT token holders.</li>
|
||
</ul>
|
||
<h2 id="explanation"><a class="header" href="#explanation">Explanation</a></h2>
|
||
<h3 id="overview"><a class="header" href="#overview">Overview</a></h3>
|
||
<p>The <code>BULK_PERIOD</code> has been restructured into two primary segments: the <code>MARKET_PERIOD</code> and the <code>RENEWAL_PERIOD</code>, along with an auxiliary<code>SETTLEMENT_PERIOD</code>. The latter does not require any active participation from the coretime system chain except to simply execute transfers of ownership between market participants. A significant departure from the current design lies in the timing of renewals, which now occur after the market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.</p>
|
||
<h3 id="market-period-14-days"><a class="header" href="#market-period-14-days">Market Period (14 days)</a></h3>
|
||
<p>During the market period, core sales are conducted through a well-established <strong>clearing-price Dutch auction</strong> that features a <code>reserve_price</code>. Since the auction format is a descending clock, the starting price is initialized at the <code>opening_price</code>. The price then descends linearly over the duration of the <code>MARKET_PERIOD</code> toward the <code>reserve_price</code>, which serves as the minimum price for coretime within that period.</p>
|
||
<p>Each bidder is expected to submit both their desired price and the quantity (i.e., number of cores) they wish to purchase. To secure these acquisitions, bidders must deposit an amount equivalent to their bid multiplied by the chosen quantity, in DOT. Bidders are always allowed to post a bid at or below the current descending price, but never above it.</p>
|
||
<p>The market reaches resolution once all quantities have been sold or the <code>reserve_price</code> is reached. In the former case, the <code>clearing_price</code> is set equal to the price that sold the last unit. If cores remain unsold, the <code>clearing_price</code> is set to the <code>reserve_price</code>. This mechanism yields a uniform price that all buyers pay. Among other benefits discussed in the Appendix, this promotes truthful bidding—meaning the optimal strategy is simply to submit one's true valuation of coretime.</p>
|
||
<p>The <code>opening_price</code> is determined by: <code>opening_price = max(MIN_OPENING_PRICE, PRICE_MULTIPLIER * reserve_price)</code>. We recommend <code>opening_price = max(150, 3 * reserve_price)</code>.</p>
|
||
<h3 id="renewal-period-7-days"><a class="header" href="#renewal-period-7-days">Renewal Period (7 days)</a></h3>
|
||
<p>The renewal period guarantees current tenants the privilege to renew their core(s), even if they did not win in the auction (i.e., did not submit a bid at or above the <code>clearing_price</code>) or did not participate at all.</p>
|
||
<p>All current tenants who obtained less cores from the market than they have the right to renew, have 7 days to decide whether they want to renew their core(s). Once this information is known, the system has everything it needs to conclusively allocate all cores and assign ownership. In cases where the combined number of renewals and auction winners exceeds the number of available cores, renewals are first served and then remaining cores are allocated from highest to lowest bidder until all are assigned (more information in the details on mechanics section). This means that under larger demand than supply (and some renewal decisions), some bidders may not receive the coretime they expected from the auction.</p>
|
||
<p>While this mechanism is necessary to ensure that current coretime users are not suddenly left without an allocation, potentially disrupting their operations, it may distort price discovery in the open market. Specifically, it could mean that a winning bidder is displaced by a renewal decision.</p>
|
||
<p>Since bidding is straightforward and can be regarded static (it requires only one transaction) and can therefore be trivially automated, we view renewals as a safety net and want to encourage all coretime users to participate in the auction. To that end, we introduce a financial incentive to bid by increasing the renewal price to <code>clearing_price * PENALTY</code> (e.g., 30%). This penalty must be high enough to create a sufficient incentive for teams to prefer bidding over passively renewing.</p>
|
||
<p><strong>Note:</strong> Importantly, the <code>PENALTY</code> only applies when the number of unique bidders in the auction plus current tenants with renewal rights exceeds the number of available cores. If total demand is lower than the number of offered cores, the <code>PENALTY</code> is set to 0%, and renewers pay only the <code>clearing_price</code>. This reflects the fact that we would not expect the <code>clearing_price</code> to exceed the <code>reserve_price</code> even with all coretime consumers participating in the auction. To avoid managing reimbursements, the 30% <code>PENALTY</code> is automatically applied to all renewers as soon as the combined count of unique bidders and potential renewers surpasses the number of available cores.</p>
|
||
<h3 id="reserve-price-adjustment"><a class="header" href="#reserve-price-adjustment">Reserve Price Adjustment</a></h3>
|
||
<p>After each <code>RENEWAL_PERIOD</code>, once all renewal decisions have been collected and cores are fully allocated, the <code>reserve_price</code> is updated to capture the demand in the next period. The goal is to ensure that prices adjust smoothly in response to demand fluctuations—rising when demand exceeds targets and falling when it is lower—while avoiding excessive volatility from small deviations.</p>
|
||
<p>We define the following parameters:</p>
|
||
<ul>
|
||
<li><code>reserve_price_t</code>: Reserve price in the current period</li>
|
||
<li><code>reserve_price_{t+1}</code>: Reserve price for the next period (final value after adjustments)</li>
|
||
<li><code>consumption_rate_t</code>: Fraction of cores sold (including renewals) out of the total available in the current period</li>
|
||
<li><code>TARGET_CONSUMPTION_RATE</code>: Target ratio of sold-to-available cores (we propose 90%)</li>
|
||
<li><code>K</code>: Sensitivity parameter controlling how aggressively the price responds to deviations (we propose values between 2 and 3)</li>
|
||
<li><code>P_MIN</code>: Minimum reserve price floor (we propose 1 DOT to prevent runaway downward spirals and computational issues)</li>
|
||
<li><code>MIN_INCREMENT</code>: Minimum absolute increment applied when the market is fully saturated (i.e., 100% consumption; proposed value: 100 DOT)</li>
|
||
</ul>
|
||
<p>We update the price according to the following rule:</p>
|
||
<pre><code>price_candidate_t = reserve_price_t * exp(K * (consumption_rate_t - TARGET_CONSUMPTION_RATE))
|
||
</code></pre>
|
||
<p>We then ensure that the price does not fall below <code>P_MIN</code>:</p>
|
||
<pre><code>price_candidate_t = max(price_candidate_t, P_MIN)
|
||
</code></pre>
|
||
<p>If <code>consumption_rate_t == 100%</code>, we apply an additional adjustment:</p>
|
||
<pre><code>if (price_candidate_t - reserve_price_t < MIN_INCREMENT) {
|
||
reserve_price_{t+1} = reserve_price_t + MIN_INCREMENT
|
||
} else {
|
||
reserve_price_{t+1} = price_candidate_t
|
||
}
|
||
</code></pre>
|
||
<p>In other words, we adjust the <code>reserve_price</code> using the exponential scaling rule, except in the special case where consumption is at 100% but the resulting price increase would be less than <code>MIN_INCREMENT</code>. In that case, we instead apply the fixed minimum increment. This exception ensures that the system can recover more quickly from prolonged periods of low prices.</p>
|
||
<p>We argue that in a situation with persistently low prices and a sudden surge in real demand (i.e., full core consumption), such a jump is both warranted and economically justified.</p>
|
||
<h3 id="settlement-period--secondary-market-7-days"><a class="header" href="#settlement-period--secondary-market-7-days">Settlement Period / Secondary Market (7 days)</a></h3>
|
||
<p>The remaining 7 days of a sales cycle serve as a settlement period, during which participants have ample time to trade coretime on secondary markets before the onset of the next <code>BULK_PERIOD</code>. This proposal makes no assumptions about the structure of these markets, as they are entirely operated on the social layer and managed directly by buyers and sellers. In this context, maintaining restrictions on the resale of renewed cores in the secondary market appears unjustified—especially given that prices are uniform and market-driven. In fact, such constraints could be harmful in cases where the primary market does not fully achieve efficiency. </p>
|
||
<p>We therefore propose lifting all restrictions on the resale or slicing of cores in the secondary market.</p>
|
||
<h2 id="additional-considerations"><a class="header" href="#additional-considerations">Additional Considerations</a></h2>
|
||
<h3 id="new-track-coretime-admin"><a class="header" href="#new-track-coretime-admin">New Track: Coretime Admin</a></h3>
|
||
<p>To enable rapid response, we propose that the parameters of the model be directly accessible by governance. These include:</p>
|
||
<ul>
|
||
<li><code>P_MIN</code></li>
|
||
<li><code>K</code></li>
|
||
<li><code>PRICE_MULTIPLIER</code></li>
|
||
<li><code>MIN_INCREMENT</code></li>
|
||
<li><code>TARGET_CONSUMPTION_RATE</code></li>
|
||
<li><code>PENALTY</code></li>
|
||
<li><code>MIN_OPENING_PRICE</code></li>
|
||
</ul>
|
||
<p>This setup should allow us to adjust the parameters in a timely manner, within the duration of a <code>BULK_PERIOD</code>, so that changes can take effect before the next period begins.</p>
|
||
<h3 id="transition-to-the-new-model"><a class="header" href="#transition-to-the-new-model">Transition to the new Model</a></h3>
|
||
<p>Upon acceptance of this RFC, we should make sure to transition as smoothly as possible to the new design.</p>
|
||
<ul>
|
||
<li>All teams that own cores in the current system should be endowed with the same number of cores in the new system, with the ability to renew them starting from the first period.</li>
|
||
<li>The initial <code>reserve_price</code> should be chosen sensibly to avoid distortions in the early phases.</li>
|
||
<li>A sufficient number of cores should be made available on the market to ensure enough liquidity to allow price discovery functions properly.</li>
|
||
</ul>
|
||
<h3 id="details-on-some-mechanics"><a class="header" href="#details-on-some-mechanics">Details on Some Mechanics</a></h3>
|
||
<ul>
|
||
<li>The price descends linearly from a <code>opening_price</code> to the <code>reserve_price</code> over the duration of the <code>MARKET_PERIOD</code>. Importantly, each discrete price level should be held for a sufficiently long interval (e.g., 6–12 hours).</li>
|
||
<li>A potential issue arises when we experience demand spikes after prolonged periods of low demand (which result in low reserve prices). In such cases, the price range between <code>reserve_price</code> and the upper bound (i.e., <code>opening_price</code>) may be lower than the willingness to pay from many bidders. If this affects most participants, demand will concentrate at the upper bound of the Dutch auction, making front-running a profitable strategy—either by excessively tipping bidding transactions or through explicit collusion with block producers.
|
||
To mitigate this, we propose preventing the market from closing at the <code>opening_price</code> prematurely. Even if demand exceeds available cores at this level, we continue collecting all orders. Then, we randomize winners instead of using a first-come-first-served approach. Additionally, we may break up bulk orders and treat them as separate bids. This still gives a higher chance to bidders willing to buy larger quantities, but avoids all-or-nothing outcomes. These steps diminish the benefit of tipping or collusion, since bid timing no longer affects allocation. While we expect such scenarios to be the exception, it's important to note that this will not negatively impact current tenants, who always retain the safety net of renewal. After a few periods of maximum bids at maximum capacity, the range should span wide enough to capture demand within its bounds.</li>
|
||
<li>One implication of granting the renewal privilege after the <code>MARKET_PERIOD</code> is that some bidders, despite bidding above the <code>clearing_price</code>, may not receive coretime. We believe this is justified, because the harm of displacing an existing project is bigger than preventing a new project from getting in (if there is no cores available) for a bit. Additionally, this inefficiency is compensated for by the causing entities paying the <code>PENALTY</code>. We need, however, additional rules to resolve the allocation issues. These are:
|
||
<ol>
|
||
<li>Bidders who already hold renewable cores cannot be displaced by the renewal decision of another party.</li>
|
||
<li>Among those who <em>can</em> be displaced, we begin with the lowest submitted bids.</li>
|
||
</ol>
|
||
</li>
|
||
<li>If a current tenant wins cores on the market, they forfeit the right to renew those specific cores. For example, if an entity currently holds three cores and wins two in the market, it may only opt to renew one. The only way to increase the number of cores at the end of a <code>BULK_PERIOD</code> is to acquire them entirely through the market.</li>
|
||
<li>Bids <strong>below</strong> the current descending price should always be allowed. In other words, teams shouldn't have to wait idly for the price to drop to their target.</li>
|
||
<li>Bids below the current descending price can be <strong>raised</strong>, but only up to the current clock price.</li>
|
||
<li>Bids <strong>above</strong> the current descending price are <strong>not allowed</strong>. This is a key difference from a simple <em>kth</em>-price auction and helps prevent sniping.</li>
|
||
<li>All cores that remain unallocated after the <code>RENEWAL_PERIOD</code> are transferred to the On-Demand Market.</li>
|
||
</ul>
|
||
<h3 id="implications"><a class="header" href="#implications">Implications</a></h3>
|
||
<ul>
|
||
<li>The introduction of a single price (<code>clearing_price</code>) provides a consistent anchor for all available coretime. This serves as a safeguard against price divergence, preventing scenarios where entities acquire cores at significantly below-market rates and keep them for minimal costs.</li>
|
||
<li>With the introduction of the <code>PENALTY</code>, it is always financially preferable for teams to participate in the auction. By bidding their true valuation, they maximize their chance of winning a core at the lowest possible price without incurring the penalty.</li>
|
||
<li>In this design, it is virtually impossible to "accidentally" lose cores, since renewals occur after the market phase and are guaranteed for current tenants.</li>
|
||
<li>Prices within a <code>BULK_PERIOD</code> are bounded upward by the <code>opening_price</code>. That means, the maximum a renewer could ever pay within a round is <code>opening_price * PENALTY</code>. This provides teams with ample time to prepare and secure the necessary funds in anticipation of potential price increases. By incorporating reserve price adjustment into their planning, teams can anticipate worst-case future price increases.</li>
|
||
</ul>
|
||
<h2 id="appendix"><a class="header" href="#appendix">Appendix</a></h2>
|
||
<h3 id="further-discussion-points"><a class="header" href="#further-discussion-points">Further Discussion Points</a></h3>
|
||
<ul>
|
||
<li><strong>Reintroduction of Candle Auctions</strong>: Polkadot gathered vast experience with candle auctions where more than 200 auctions has been conducted throughout more than two years. <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5109856">Our study</a> analyzing the results in much detail reveals that the mechanism itself is both efficient and (nearly) extracting optimal revenue. This provides confidence to use it to allocate the winners instead of a descending clock auction. Notably, this change solely affects the bidding process and winner determination. Core components, such as the k-th price, reserve price, and maximum price, remain unaffected.</li>
|
||
</ul>
|
||
<h3 id="insights-clearing-price-dutch-auctions"><a class="header" href="#insights-clearing-price-dutch-auctions">Insights: Clearing Price Dutch Auctions</a></h3>
|
||
<p>Having all bidders pay the market clearing price offers some benefits and disadvantages.</p>
|
||
<ul>
|
||
<li>Advantages:
|
||
<ul>
|
||
<li><strong>Fairness</strong>: All bidders pay the same price.</li>
|
||
<li><strong>Active participation</strong>: Because bidders are protected from overbidding (winner's curse), they are more likely to engage and reveal their true valuations.</li>
|
||
<li><strong>Simplicity</strong>: A single price is easier to work with for pricing renewals later.</li>
|
||
<li><strong>Truthfulness</strong>: There is no need to try to game the market by waiting with bidding. Bidders can just bid their valuations.</li>
|
||
<li><strong>No sniping</strong>: As prices are descending, a player cannot wait until the end to place a high bid. They are only allowed to place the decreasing bid at the time of bidding. </li>
|
||
</ul>
|
||
</li>
|
||
<li>Disadvantages:
|
||
<ul>
|
||
<li><strong>(Potentially) Lower Revenue</strong>: While the theory predicts revenue-equivalence between a uniform price and pay-as-bid type of auction, slightly lower revenue for the former type is observed empirically. Arguably, revenue maximization (i.e., squeezing out the maximum willingness to pay from bidders) is not the priority for Polkadot. Instead, it is interested in efficient allocation and the other benefits illustrated above.</li>
|
||
<li><strong>(Technical) Complexity</strong>: Instead of making a final purchase within the auction, the bid is only a deposit. Some refunds might happen after the auction is finished. This might pose additional challenges from the technical side (e.g., storage requirements).</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<h3 id="prior-art-and-references"><a class="header" href="#prior-art-and-references">Prior Art and References</a></h3>
|
||
<p>This RFC builds extensively on the available ideas put forward in <a href="https://github.com/polkadot-fellows/RFCs/blob/6f29561a4747bbfd95307ce75cd949dfff359e39/text/0001-agile-coretime.md">RFC-1</a>. </p>
|
||
<p>Additionally, I want to express a special thanks to <a href="https://samuelhaefner.github.io/">Samuel Haefner</a>, <a href="https://sites.google.com/site/dobzin/">Shahar Dobzinski</a>, and Alistair Stewart for fruitful discussions and helping me structure my thoughts.</p>
|
||
|
||
</main>
|
||
|
||
<nav class="nav-wrapper" aria-label="Page navigation">
|
||
<!-- Mobile navigation buttons -->
|
||
<a rel="prev" href="../approved/0014-improve-locking-mechanism-for-parachains.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
||
<i class="fa fa-angle-left"></i>
|
||
</a>
|
||
|
||
<a rel="next prefetch" href="../approved/0022-adopt-encointer-runtime.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
||
<i class="fa fa-angle-right"></i>
|
||
</a>
|
||
|
||
<div style="clear: both"></div>
|
||
</nav>
|
||
</div>
|
||
</div>
|
||
|
||
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
||
<a rel="prev" href="../approved/0014-improve-locking-mechanism-for-parachains.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
||
<i class="fa fa-angle-left"></i>
|
||
</a>
|
||
|
||
<a rel="next prefetch" href="../approved/0022-adopt-encointer-runtime.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
||
<i class="fa fa-angle-right"></i>
|
||
</a>
|
||
</nav>
|
||
|
||
</div>
|
||
|
||
|
||
|
||
|
||
<script>
|
||
window.playground_copyable = true;
|
||
</script>
|
||
|
||
|
||
<script src="../elasticlunr.min.js"></script>
|
||
<script src="../mark.min.js"></script>
|
||
<script src="../searcher.js"></script>
|
||
|
||
<script src="../clipboard.min.js"></script>
|
||
<script src="../highlight.js"></script>
|
||
<script src="../book.js"></script>
|
||
|
||
<!-- Custom JS scripts -->
|
||
|
||
|
||
</div>
|
||
</body>
|
||
</html>
|