Apply suggestions from code review

Co-authored-by: Erin Shaben <[email protected]>

Author: 0xLucca

develop/parachains/deployment/coretime-renewal.md

@@ -13,15 +13,15 @@ Coretime can be purchased in bulk for a period of 28 days, providing access to P
 
 The bulk sale process consists of three distinct phases:
 
-- **Interlude phase** - the period between bulk sales when renewals are prioritized
-- **Lead-in phase** - following the interlude phase, a new `start_price` is set, and a Dutch auction begins, lasting for `leadin_length` blocks. During this phase, prices experience downward pressure as the system aims to find market equilibrium. The final price at the end of this phase becomes the `regular_price`, which will be used in the subsequent fixed price phase
-- **Fixed price phase** - the final phase where remaining cores are sold at the `regular_price` established during the leading phase. This provides a stable and predictable pricing environment for participants who did not purchase during the price discovery period
+1. **Interlude phase** - the period between bulk sales when renewals are prioritized
+2. **Lead-in phase** - following the interlude phase, a new `start_price` is set, and a Dutch auction begins, lasting for `leadin_length` blocks. During this phase, prices experience downward pressure as the system aims to find market equilibrium. The final price at the end of this phase becomes the `regular_price`, which will be used in the subsequent fixed price phase
+3. **Fixed price phase** - the final phase where remaining cores are sold at the `regular_price` established during the lead-in phase. This provides a stable and predictable pricing environment for participants who did not purchase during the price discovery period
 
 For more comprehensive information about the coretime sales process, refer to the [Coretime Sales](https://wiki.polkadot.network/learn/learn-agile-coretime/#coretime-sales){target=\_blank} section in the Polkadot Wiki.
 
 ## Renewal Timing
 
-While renewals can technically be made during any phase, it is strongly recommended to complete renewals during the interlude phase. Delaying renewal introduces the risk that the core could be sold to another participant in the market, preventing successful renewal. Renewals must be initiated well in advance to avoid the aforementioned scenario. 
+While renewals can technically be made during any phase, it is strongly recommended that they be completed during the interlude phase. Delaying renewal introduces the risk that the core could be sold to another market participant, preventing successful renewal. Renewals must be initiated well in advance to avoid the scenario above. 
 
 For example, if you purchase a core in bulk sale #1, you obtain coretime for the upcoming bulk period (during which bulk sale #2 takes place).
 Your renewal must be completed during bulk sale #2, ideally during its interlude phase, to secure coretime for the subsequent period.
@@ -44,26 +44,26 @@ To manually renew a core:
 
     ![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-2.webp)
 
-For optimal results, the renewal should be performed during the interlude phase. Upon successful submission, your core will be renewed for the next coretime period, ensuring continued operation of your parachain.
+For optimal results, the renewal should be performed during the interlude phase. Upon successful submission, your core will be renewed for the next coretime period, ensuring the continued operation of your parachain.
 
-## Auto Renewal
+## Auto-Renewal
 
-The coretime auto-renewal feature simplifies the process of maintaining continuous coretime allocation by automatically renewing cores at the beginning of each sale period. This eliminates the need for parachains to manually renew their cores for each bulk period, reducing operational overhead and the risk of missing renewal deadlines.
+The coretime auto-renewal feature simplifies maintaining continuous coretime allocation by automatically renewing cores at the beginning of each sale period. This eliminates the need for parachains to manually renew their cores for each bulk period, reducing operational overhead and the risk of missing renewal deadlines.
 
 When auto-renewal is enabled, the system follows this process at the start of each sale:
 
 1. The system scans all registered auto-renewal records
-2. For each record, it attempts to process renewal payments from the task's [sovereign account](/polkadot-protocol/glossary/#sovereign-account){target=\_blank} (which is the sibling account on the Coretime chain derived from the Parachain ID)
+2. For each record, it attempts to process renewal payments from the task's [sovereign account](/polkadot-protocol/glossary/#sovereign-account){target=\_blank} (which is the sibling account on the Coretime chain derived from the parachain ID)
 3. Upon successful payment, the system emits a `Renewed` event and secures the core for the next period
 4. If payment fails due to insufficient funds or other issues, the system emits an `AutoRenewalFailed` event
 
-Even if an auto-renewal attempt fails, the auto-renewal setting remains active for subsequent sales. This means once you've configured auto-renewal, the setting persists across multiple periods.
+Even if an auto-renewal attempt fails, the auto-renewal setting remains active for subsequent sales. This means the setting persists across multiple periods once you've configured auto-renewal.
 
-To enable auto-renewal for your parachain, you'll need to configure several components as detailed in the following sections.
+To enable auto-renewal for your parachain, you must configure several components, as detailed in the following sections.
 
-### Set Up HRMP Channel
+### Set Up an HRMP Channel
 
-A Horizontal Relay-routed Message Passing (HRMP) channel must be open between your parachain and the Coretime System Chain before auto-renewal can be configured. 
+A Horizontal Relay-routed Message Passing (HRMP) channel must be opened between your parachain and the Coretime system chain before auto-renewal can be configured. 
 
 For instructions on establishing this connection, consult the [Opening HRMP Channels with System Parachains](/tutorials/interoperability/xcm-channels/para-to-system/){target=\_blank} guide.
 
@@ -73,7 +73,7 @@ The [sovereign account](https://github.com/polkadot-fellows/xcm-format/blob/1072
 
 To determine your parachain's sovereign account address, you can:
 
-- Use the "Para ID" to Address section in [Substrate Utilities](https://www.shawntabrizi.com/substrate-js-utilities/){target=\_blank} with the **Sibling** option selected
+- Use the **"Para ID" to Address** section in [Substrate Utilities](https://www.shawntabrizi.com/substrate-js-utilities/){target=\_blank} with the **Sibling** option selected
 
 - Calculate it manually:
 
@@ -94,7 +94,7 @@ To determine your parachain's sovereign account address, you can:
 
 The Coretime chain provides two primary extrinsics for managing the auto-renewal functionality:
 
-- [`enable_auto_renew(core, task, workload_end_hint)`](https://paritytech.github.io/polkadot-sdk/master/pallet_broker/pallet/struct.Pallet.html#method.enable_auto_renew){target=\_blank} - use this extrinsic to activate automatic renewals for a specific core. This transaction must originate from the sovereign account of the parachain task
+- [**`enable_auto_renew(core, task, workload_end_hint)`**](https://paritytech.github.io/polkadot-sdk/master/pallet_broker/pallet/struct.Pallet.html#method.enable_auto_renew){target=\_blank} - use this extrinsic to activate automatic renewals for a specific core. This transaction must originate from the sovereign account of the parachain task
 
     **Parameters:**
 
@@ -112,16 +112,16 @@ The Coretime chain provides two primary extrinsics for managing the auto-renewal
 
      **Parameters:**
 
-    - **`core`**: the core currently assigned to the task
-    - **`task`**: the task for which auto-renewal is enabled
+    - **`core`** - the core currently assigned to the task
+    - **`task`** - the task for which auto-renewal is enabled
 
-### Construct the Enable Auto Renewal Extrinsic
+### Construct the Enable Auto-Renewal Extrinsic
 
 To configure auto-renewal, you'll need to gather specific information for the `enable_auto_renew` extrinsic parameters:
 
 - **`core`** - identify which core your parachain is assigned to when the it expires. This requires checking both current assignments and planned future assignments:
-    - For current period - query `broker.workload()`
-    - For next period - query `broker.workplan()`
+    - **For current period** - query `broker.workload()`
+    - **For next period** - query `broker.workplan()`
 
     **Example for parachain `2000`:**
 
@@ -152,9 +152,7 @@ To configure auto-renewal, you'll need to gather specific information for the `e
 - **`task`** - use your parachain ID, which can be verified by connecting to your parachain and querying `parachainInfo.parachainId()`
 
 - **`workload_end_hint`** - you should always set it explicitly to avoid misbehavior. This value indicates when your assigned core will expire. Here's how to calculate the correct value based on how your core is assigned:
-    - If the parachain uses bulk coretime:
-
-        Query `broker.saleinfo`. You’ll get a result like:
+    - If the parachain uses bulk coretime, query `broker.saleinfo`. You’ll get a result like:
 
         ```json
         {
@@ -176,9 +174,7 @@ To configure auto-renewal, you'll need to gather specific information for the `e
         - If the core has already been renewed and will expire in the next sale, use the `regionEnd` value. In this example, that would be `327885`
 
 
-    - If the parachain has a lease:
-
-        Query `broker.leases`, which returns entries like:
+    - If the parachain has a lease, query `broker.leases`, which returns entries like:
 
         ```json
         [
@@ -206,15 +202,15 @@ Once you have these values, construct the extrinsic:
 
     ![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-3.webp)
 
-    For parachain `2000` on core `48` with `workload_end_hint` `327885`, the encoded call data would be:`0x32153000d007000001cd000500`
+    For parachain `2000` on core `48` with `workload_end_hint` `327885`, the **encoded call data** is:`0x32153000d007000001cd000500`
 
-3. Check the transaction weight for executing the call. You can estimate this by executing the `transactionPaymentCallApi.queryCallInfo` runtime call with the encoded call data previously obtained:
+3. Check the transaction weight for executing the call. You can estimate this by executing the `transactionPaymentCallApi.queryCallInfo` runtime call with the encoded call data previously obtained
 
     ![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-4.webp)
 
-### Submit the XCM from your Parachain
+### Submit the XCM from Your Parachain
 
-To activate auto-renewal, you must submit an XCM from your parachain to the Coretime chain using Root origin. This can be done either through the sudo pallet (if available) or through your parachain's governance system.
+To activate auto-renewal, you must submit an XCM from your parachain to the Coretime chain using Root origin.  This can be done through the sudo pallet (if available) or your parachain's governance system.
 
 The XCM needs to execute these operations: