deploy: 54c8225d25

print.html

@@ -227,15 +227,15 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
 <li>This significantly increases the cost for core captures, because captured cores would become increasingly expensive over time.</li>
 </ul>
 </li>
-<li>It exposes the renewal prices, while still being beneficial for longterm tenants, more to market forces. </li>
+<li>It exposes the renewal decision, while still guaranteeing longterm tenants to keep their core, more to market forces. </li>
 <li>It removes the LeadIn period and introduces a (from the perspective of the coretime systemchain) passive Settlement Phase, that allows the secondary market to exert it's force.</li>
 </ul>
-<p>The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority <strong>IF</strong> they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from market prices which allows for core captures and general inefficiencies. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. In particular, prices are bounded upward within a <code>BULK_PERIOD</code> and can be calculated for future periods. It must be stated, however, that under high demand, prices could exponentially increase. This is necessary to allow for proper price discovery and efficient Coretime pricing and allocation.</p>
+<p>The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority and a guaranteed allocation <strong>IF</strong> they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from market prices which allows for core captures and general inefficiencies. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. In particular, prices are bounded upward within a <code>BULK_PERIOD</code> and can be calculated for future periods. It must be stated, however, that under high demand, prices could exponentially increase. This is necessary to allow for proper price discovery and efficient Coretime pricing and allocation.</p>
 <p>Ultimately, this the framework proposed here adheres to all requirements 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 and developers, largely represented by the Polkadot Fellowship and Parity Technologies' Engineering division.</li>
+<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>
@@ -243,12 +243,13 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
 <h3 id="bulk-markets"><a class="header" href="#bulk-markets">Bulk Markets</a></h3>
 <p>The <code>BULK_PERIOD</code> has been restructured into two primary segments: the <code>MARKET_PERIOD</code> and <code>RENEWAL_PERIOD</code>, along with an auxiliary <code>SETTLEMENT_PERIOD</code>. This latter period doesn't necessitate any actions from the coretime system chain, but it facilitates a more efficient allocation of coretime in secondary markets. A significant departure from the original proposal lies in the timing of renewals, which now occur post-market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.</p>
 <h4 id="market-period-14-days"><a class="header" href="#market-period-14-days">Market Period (14 days)</a></h4>
-<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>. The price initiates at a premium, designated as <code>PRICE_PREMIUM</code> (for instance, 200%) and descends linearly to the <code>RESERVE_PRICE</code> throughout the duration of the <code>MARKET_PERIOD</code>. Each bidder is expected to submit both their desired price and the quantity (that is, the amount of Coretime) they wish to purchase. To secure these acquisitions, bidders must make a deposit equivalent to their bid multiplied by the chosen quantity, in DOT. </p>
+<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>. The price initiates at a premium, designated as <code>PRICE_PREMIUM</code> (for instance, 200%) and descends linearly to the <code>RESERVE_PRICE</code> throughout the duration of the <code>MARKET_PERIOD</code>. Each bidder is expected to submit both their desired price and the quantity (that is, the amount of Coretime) they wish to purchase. To secure these acquisitions, bidders must make a deposit equivalent to their bid multiplied by the chosen quantity, in DOT. Bidders are always allowed to post a bid under the current descending price, but never above it. </p>
 <p>The market achieves resolution once all quantities have been sold, or the <code>RESERVE_PRICE</code> has been reached. This situation leads to determining the <code>CLEARING_PRICE</code> either by the lowest bid that was successful in clearing the entire market or by the <code>RESERVE_PRICE</code>. This mechanism yields a uniform price, shaped by market forces (refer to the following discussion for an explanation of its benefits). In other words, all buyers pay the same price (per unit of Coretime). Further down the benefits of this variant of a Dutch auction is discussed.</p>
 <p><strong>Note:</strong> In cases where some cores remain unsold in the market, all buyers are obligated to pay the <code>RESERVE_PRICE</code>. Bids below the <code>RESERVE_PRICE</code> are not valid.</p>
 <h4 id="renewal-period-7-days"><a class="header" href="#renewal-period-7-days">Renewal Period (7 days)</a></h4>
-<p>As the <code>RENEWAL_PERIOD</code> commences, all current tenants are granted the opportunity to renew their cores at the <code>CLEARING_PRICE</code> (optionally, we could grant a small discount, balancing out the non-transferability aspect of renewals). In other words, they have 7 days to pay to renew their cores. After obtaining the information who renewed and who did not, the system has the necessary information to conclusively allocate all cores and transfer ownership.</p>
-<p>In the case where there are combined more renewals and bidders at or above the <code>CLEARING_PRICE</code> than available cores, we allocate cores to the highest to lowest bidders until all available cores are allocated (albeit still at the <code>CLEARING_PRICE</code>). That effectively means that in situations with very high demand, some bidders might not get a core.</p>
+<p>The renewal period guarantees current tenants the right to renew their core even if they did not place a bid above the <code>CLEARING_PRICE</code> in the auction or did not participate at all. For the <code>MARKET_PERIOD</code> to produce the most efficient outcome and properly discover the price, we want as many active bidders as possible. Therefore, as we expect at some point much more renewals than new entrants, we want to nudge even existing tenants to participate and place bids in the auction. We can do that, by making the renewal price slightly less attractive than the <code>CLEARING_PRICE</code> obtained in the auction. To achieve that, we can simply add a small <code>PENALTY</code> (e.g., 10%) to it. The renewal price would thereby be <code>CLEARING_PRICE * PENALTY</code>. We can easily argue that the priviledge not to participate in the auction and having guaranteed coretime warrants a small price hike. </p>
+<p>All current tenants have 7 days to decide whether they want to renew their core or not. After obtaining the information who renewed and who did not, the system has the necessary information to conclusively allocate all cores and transfer ownership.</p>
+<p>In the case where there are combined more renewals and bidders at or above the <code>CLEARING_PRICE</code> than available cores, we allocate cores to the highest to lowest bidders until all available cores are allocated (albeit still at the <code>CLEARING_PRICE</code>). That effectively means that in situations with very high demand, some bidders might not get the coretime they bid for.</p>
 <p>If the supply exceeds the demand, all unallocated cores are transferred to the Instantanous Market.</p>
 <h4 id="reserve-price-adjustment"><a class="header" href="#reserve-price-adjustment">Reserve Price Adjustment</a></h4>
 <p>After all cores are allocated, the <code>RESERVE_PRICE</code> is adjusted similar to the process described in RFC-1, where we define <code>TARGET_CONSUMPTION_RATE</code> as a ratio of the available to unsold cores. Then, the upcoming reserve price is adjusted upwards or downward, depending on whether we over- or undershoot the target consumption. If the consumption is met precisely, the price remains unchanged in the next <code>BULK_PERIOD</code>. </p>
@@ -258,12 +259,12 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
 <code>TARGET_CONSUMPTION_RATE</code>: how many of the available cores we want to sell without increasing the price. We propose 90%. This leaves enough area downward and upward to adjust prices more aggressively.
 <code>K</code>: sensitivity parameter. How aggressively we want to adjust the price. We propose a value between 2.
 <code>P_MIN</code>: A minimum price we never undercut. This is important to bound the price downward and prevent computational issues if prices drop too low.
-<code>DELTA_MIN</code>: A minimum increment after we reached 100% capacity. This is important to quickly recover after long periods of low demand which resulted in low prices.</p>
+<code>MIN_INCREMENT</code>: A minimum increment after we reached 100% capacity. This is important to quickly recover after long periods of low demand which resulted in low prices.</p>
 <p>We update the price according to:</p>
 <p><code>p_new = reserve_price_old * exp(K * (consumption_rate - TARGET_CONSUMPTION_RATE))</code></p>
 <p>The <code>RESERVE_PRICE</code> in the next period will be:</p>
 <p><code>RESERVE_PRICE_NEXT = max(p_new, P_MIN)</code></p>
-<p><strong>Note:</strong> To reduce the recovery time from very low prices it is important to, in the case of 100% capacity, at least increment the <code>RESERVE_PRICE_NEXT</code> by <code>DELTA_MIN</code>, which could be, e.g., 100 DOT. </p>
+<p><strong>Note:</strong> To reduce the recovery time from very low prices it is important to, in the case of 100% capacity, at least increment the <code>RESERVE_PRICE_NEXT</code> by <code>MIN_INCREMENT</code>, which could be, e.g., 100 DOT.</p>
 <h4 id="settlement-period-7-days"><a class="header" href="#settlement-period-7-days">Settlement Period (7 days)</a></h4>
 <p>During the settlement period, participants have ample time to trade Coretime on secondary markets before the onset of the next <code>BULK_PERIOD</code>. This allows for trading with full Coretime availability. Trading transferrable Coretime naturally continues during each <code>BULK_PERIOD</code>, albeit with cores already in use.</p>
 <h3 id="benefits-of-this-system"><a class="header" href="#benefits-of-this-system">Benefits of this system</a></h3>
@@ -276,7 +277,8 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
 </ul>
 <h3 id="implications-of-this-system"><a class="header" href="#implications-of-this-system">Implications of this system</a></h3>
 <ul>
-<li>Bidders above the clearing price might not receive a core: We aim to grant existing coretime users the exclusive right to renew their cores at a fair market price. To facilitate this, we conduct a market phase before the renewal phase, during which all cores are put up for sale. However, current coretime users are not obligated to participate in this market phase. While advantageous for existing users, this condition may occasionally result in bidders not receiving a core despite bidding above the clearing price. After renewals, any remaining cores will be allocated to bidders in descending order of their bids, still applying the uniform clearing price. We consider this scenario a necessary trade-off to ensure that renewals remain influenced by market dynamics. Ultimately, we believe this approach is justified, as it is preferable to risk delaying new projects until subsequent cycles rather than displacing ongoing projects.</li>
+<li>Bidders above the clearing price might not receive their coretime: We aim to grant existing coretime users the exclusive right to renew their cores at the <code>CLEARING_PRICE * PENALTY</code>. To facilitate this, we conduct a market phase before the renewal phase, during which all cores are put up for sale. However, current coretime users are not obligated to participate in this market phase. While the <code>PENALTY</code> still nudges them to participate, it might be the case that, together with renewals, there are less cores available than we offered in the market. This condition may occasionally result in bidders not receiving their coretime despite bidding above the clearing price. After renewals, any remaining cores will be allocated to bidders in descending order of their bids, still applying the uniform clearing price. We consider this scenario a necessary trade-off to ensure that renewals remain influenced by market dynamics. Ultimately, we believe this approach is justified, as it is preferable to risk delaying new projects until subsequent cycles rather than displacing ongoing projects.</li>
+<li>We want current coretime owners to participate in the auction to improve overall efficiency. To encourage this, we introduce a <code>PENALTY</code>, which creates a mild financial incentive to take part during the <code>MARKET_PERIOD</code>. However, there’s a challenge: final allocation of cores can only happen after all renewal decisions have been collected. But current tenants would prefer to know whether they’ve won in the auction before deciding whether to fall back to renewal and pay the <code>PENALTY</code>. This can be resolved by ensuring that any bid from a current coretime owner that is at or above the <code>CLEARING_PRICE</code> is never kicked out. In other words, if a current owner bids at or above the <code>CLEARING_PRICE</code>, they are guaranteed to retain the coretime—avoiding the <code>PENALTY</code> altogether. If they don’t win in the auction, they can still fall back to renewal, paying <code>CLEARING_PRICE * PENALTY</code>. Note that this logic does not apply to new bidders (those without existing coretime): their bids may be displaced (starting from the lowest to highest) depending on the renewal decisions.</li>
 <li>Bids below the current descending price should always be allowed (i.e., we would not want to require teams sitting and waiting for the price to finally be declined to their taget level). That makes it easy to participate for bidders.</li>
 <li>Bids above the current descending price <strong>are not allowed</strong>. This marks a difference to a simple kth-price auction and prevents sniping.</li>
 </ul>

proposed/0015-market-design-revisit.html

@@ -221,15 +221,15 @@
 <li>This significantly increases the cost for core captures, because captured cores would become increasingly expensive over time.</li>
 </ul>
 </li>
-<li>It exposes the renewal prices, while still being beneficial for longterm tenants, more to market forces. </li>
+<li>It exposes the renewal decision, while still guaranteeing longterm tenants to keep their core, more to market forces. </li>
 <li>It removes the LeadIn period and introduces a (from the perspective of the coretime systemchain) passive Settlement Phase, that allows the secondary market to exert it's force.</li>
 </ul>
-<p>The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority <strong>IF</strong> they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from market prices which allows for core captures and general inefficiencies. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. In particular, prices are bounded upward within a <code>BULK_PERIOD</code> and can be calculated for future periods. It must be stated, however, that under high demand, prices could exponentially increase. This is necessary to allow for proper price discovery and efficient Coretime pricing and allocation.</p>
+<p>The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority and a guaranteed allocation <strong>IF</strong> they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from market prices which allows for core captures and general inefficiencies. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. In particular, prices are bounded upward within a <code>BULK_PERIOD</code> and can be calculated for future periods. It must be stated, however, that under high demand, prices could exponentially increase. This is necessary to allow for proper price discovery and efficient Coretime pricing and allocation.</p>
 <p>Ultimately, this the framework proposed here adheres to all requirements 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 and developers, largely represented by the Polkadot Fellowship and Parity Technologies' Engineering division.</li>
+<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>
@@ -237,12 +237,13 @@
 <h3 id="bulk-markets"><a class="header" href="#bulk-markets">Bulk Markets</a></h3>
 <p>The <code>BULK_PERIOD</code> has been restructured into two primary segments: the <code>MARKET_PERIOD</code> and <code>RENEWAL_PERIOD</code>, along with an auxiliary <code>SETTLEMENT_PERIOD</code>. This latter period doesn't necessitate any actions from the coretime system chain, but it facilitates a more efficient allocation of coretime in secondary markets. A significant departure from the original proposal lies in the timing of renewals, which now occur post-market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.</p>
 <h4 id="market-period-14-days"><a class="header" href="#market-period-14-days">Market Period (14 days)</a></h4>
-<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>. The price initiates at a premium, designated as <code>PRICE_PREMIUM</code> (for instance, 200%) and descends linearly to the <code>RESERVE_PRICE</code> throughout the duration of the <code>MARKET_PERIOD</code>. Each bidder is expected to submit both their desired price and the quantity (that is, the amount of Coretime) they wish to purchase. To secure these acquisitions, bidders must make a deposit equivalent to their bid multiplied by the chosen quantity, in DOT. </p>
+<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>. The price initiates at a premium, designated as <code>PRICE_PREMIUM</code> (for instance, 200%) and descends linearly to the <code>RESERVE_PRICE</code> throughout the duration of the <code>MARKET_PERIOD</code>. Each bidder is expected to submit both their desired price and the quantity (that is, the amount of Coretime) they wish to purchase. To secure these acquisitions, bidders must make a deposit equivalent to their bid multiplied by the chosen quantity, in DOT. Bidders are always allowed to post a bid under the current descending price, but never above it. </p>
 <p>The market achieves resolution once all quantities have been sold, or the <code>RESERVE_PRICE</code> has been reached. This situation leads to determining the <code>CLEARING_PRICE</code> either by the lowest bid that was successful in clearing the entire market or by the <code>RESERVE_PRICE</code>. This mechanism yields a uniform price, shaped by market forces (refer to the following discussion for an explanation of its benefits). In other words, all buyers pay the same price (per unit of Coretime). Further down the benefits of this variant of a Dutch auction is discussed.</p>
 <p><strong>Note:</strong> In cases where some cores remain unsold in the market, all buyers are obligated to pay the <code>RESERVE_PRICE</code>. Bids below the <code>RESERVE_PRICE</code> are not valid.</p>
 <h4 id="renewal-period-7-days"><a class="header" href="#renewal-period-7-days">Renewal Period (7 days)</a></h4>
-<p>As the <code>RENEWAL_PERIOD</code> commences, all current tenants are granted the opportunity to renew their cores at the <code>CLEARING_PRICE</code> (optionally, we could grant a small discount, balancing out the non-transferability aspect of renewals). In other words, they have 7 days to pay to renew their cores. After obtaining the information who renewed and who did not, the system has the necessary information to conclusively allocate all cores and transfer ownership.</p>
-<p>In the case where there are combined more renewals and bidders at or above the <code>CLEARING_PRICE</code> than available cores, we allocate cores to the highest to lowest bidders until all available cores are allocated (albeit still at the <code>CLEARING_PRICE</code>). That effectively means that in situations with very high demand, some bidders might not get a core.</p>
+<p>The renewal period guarantees current tenants the right to renew their core even if they did not place a bid above the <code>CLEARING_PRICE</code> in the auction or did not participate at all. For the <code>MARKET_PERIOD</code> to produce the most efficient outcome and properly discover the price, we want as many active bidders as possible. Therefore, as we expect at some point much more renewals than new entrants, we want to nudge even existing tenants to participate and place bids in the auction. We can do that, by making the renewal price slightly less attractive than the <code>CLEARING_PRICE</code> obtained in the auction. To achieve that, we can simply add a small <code>PENALTY</code> (e.g., 10%) to it. The renewal price would thereby be <code>CLEARING_PRICE * PENALTY</code>. We can easily argue that the priviledge not to participate in the auction and having guaranteed coretime warrants a small price hike. </p>
+<p>All current tenants have 7 days to decide whether they want to renew their core or not. After obtaining the information who renewed and who did not, the system has the necessary information to conclusively allocate all cores and transfer ownership.</p>
+<p>In the case where there are combined more renewals and bidders at or above the <code>CLEARING_PRICE</code> than available cores, we allocate cores to the highest to lowest bidders until all available cores are allocated (albeit still at the <code>CLEARING_PRICE</code>). That effectively means that in situations with very high demand, some bidders might not get the coretime they bid for.</p>
 <p>If the supply exceeds the demand, all unallocated cores are transferred to the Instantanous Market.</p>
 <h4 id="reserve-price-adjustment"><a class="header" href="#reserve-price-adjustment">Reserve Price Adjustment</a></h4>
 <p>After all cores are allocated, the <code>RESERVE_PRICE</code> is adjusted similar to the process described in RFC-1, where we define <code>TARGET_CONSUMPTION_RATE</code> as a ratio of the available to unsold cores. Then, the upcoming reserve price is adjusted upwards or downward, depending on whether we over- or undershoot the target consumption. If the consumption is met precisely, the price remains unchanged in the next <code>BULK_PERIOD</code>. </p>
@@ -252,12 +253,12 @@
 <code>TARGET_CONSUMPTION_RATE</code>: how many of the available cores we want to sell without increasing the price. We propose 90%. This leaves enough area downward and upward to adjust prices more aggressively.
 <code>K</code>: sensitivity parameter. How aggressively we want to adjust the price. We propose a value between 2.
 <code>P_MIN</code>: A minimum price we never undercut. This is important to bound the price downward and prevent computational issues if prices drop too low.
-<code>DELTA_MIN</code>: A minimum increment after we reached 100% capacity. This is important to quickly recover after long periods of low demand which resulted in low prices.</p>
+<code>MIN_INCREMENT</code>: A minimum increment after we reached 100% capacity. This is important to quickly recover after long periods of low demand which resulted in low prices.</p>
 <p>We update the price according to:</p>
 <p><code>p_new = reserve_price_old * exp(K * (consumption_rate - TARGET_CONSUMPTION_RATE))</code></p>
 <p>The <code>RESERVE_PRICE</code> in the next period will be:</p>
 <p><code>RESERVE_PRICE_NEXT = max(p_new, P_MIN)</code></p>
-<p><strong>Note:</strong> To reduce the recovery time from very low prices it is important to, in the case of 100% capacity, at least increment the <code>RESERVE_PRICE_NEXT</code> by <code>DELTA_MIN</code>, which could be, e.g., 100 DOT. </p>
+<p><strong>Note:</strong> To reduce the recovery time from very low prices it is important to, in the case of 100% capacity, at least increment the <code>RESERVE_PRICE_NEXT</code> by <code>MIN_INCREMENT</code>, which could be, e.g., 100 DOT.</p>
 <h4 id="settlement-period-7-days"><a class="header" href="#settlement-period-7-days">Settlement Period (7 days)</a></h4>
 <p>During the settlement period, participants have ample time to trade Coretime on secondary markets before the onset of the next <code>BULK_PERIOD</code>. This allows for trading with full Coretime availability. Trading transferrable Coretime naturally continues during each <code>BULK_PERIOD</code>, albeit with cores already in use.</p>
 <h3 id="benefits-of-this-system"><a class="header" href="#benefits-of-this-system">Benefits of this system</a></h3>
@@ -270,7 +271,8 @@
 </ul>
 <h3 id="implications-of-this-system"><a class="header" href="#implications-of-this-system">Implications of this system</a></h3>
 <ul>
-<li>Bidders above the clearing price might not receive a core: We aim to grant existing coretime users the exclusive right to renew their cores at a fair market price. To facilitate this, we conduct a market phase before the renewal phase, during which all cores are put up for sale. However, current coretime users are not obligated to participate in this market phase. While advantageous for existing users, this condition may occasionally result in bidders not receiving a core despite bidding above the clearing price. After renewals, any remaining cores will be allocated to bidders in descending order of their bids, still applying the uniform clearing price. We consider this scenario a necessary trade-off to ensure that renewals remain influenced by market dynamics. Ultimately, we believe this approach is justified, as it is preferable to risk delaying new projects until subsequent cycles rather than displacing ongoing projects.</li>
+<li>Bidders above the clearing price might not receive their coretime: We aim to grant existing coretime users the exclusive right to renew their cores at the <code>CLEARING_PRICE * PENALTY</code>. To facilitate this, we conduct a market phase before the renewal phase, during which all cores are put up for sale. However, current coretime users are not obligated to participate in this market phase. While the <code>PENALTY</code> still nudges them to participate, it might be the case that, together with renewals, there are less cores available than we offered in the market. This condition may occasionally result in bidders not receiving their coretime despite bidding above the clearing price. After renewals, any remaining cores will be allocated to bidders in descending order of their bids, still applying the uniform clearing price. We consider this scenario a necessary trade-off to ensure that renewals remain influenced by market dynamics. Ultimately, we believe this approach is justified, as it is preferable to risk delaying new projects until subsequent cycles rather than displacing ongoing projects.</li>
+<li>We want current coretime owners to participate in the auction to improve overall efficiency. To encourage this, we introduce a <code>PENALTY</code>, which creates a mild financial incentive to take part during the <code>MARKET_PERIOD</code>. However, there’s a challenge: final allocation of cores can only happen after all renewal decisions have been collected. But current tenants would prefer to know whether they’ve won in the auction before deciding whether to fall back to renewal and pay the <code>PENALTY</code>. This can be resolved by ensuring that any bid from a current coretime owner that is at or above the <code>CLEARING_PRICE</code> is never kicked out. In other words, if a current owner bids at or above the <code>CLEARING_PRICE</code>, they are guaranteed to retain the coretime—avoiding the <code>PENALTY</code> altogether. If they don’t win in the auction, they can still fall back to renewal, paying <code>CLEARING_PRICE * PENALTY</code>. Note that this logic does not apply to new bidders (those without existing coretime): their bids may be displaced (starting from the lowest to highest) depending on the renewal decisions.</li>
 <li>Bids below the current descending price should always be allowed (i.e., we would not want to require teams sitting and waiting for the price to finally be declined to their taget level). That makes it easy to participate for bidders.</li>
 <li>Bids above the current descending price <strong>are not allowed</strong>. This marks a difference to a simple kth-price auction and prevents sniping.</li>
 </ul>