Skip to content

Commit fd74122

Browse files
0xLucca0xLucca
committed
Apply suggestions
1 parent 7fad330 commit fd74122

File tree

2 files changed

+80
-74
lines changed

2 files changed

+80
-74
lines changed

‎develop/parachains/deployment/coretime-renewal.md‎

Lines changed: 28 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ description: Learn how to renew coretime manually or automatically to ensure uni
77

88
## Introduction
99

10-
Coretime can be purchased in bulk for a period of 28 days, providing access to Polkadot's shared security and interoperability for Polkadot Rollups (Parachains). The bulk purchase of coretime includes a rent-control mechanism that keeps future purchases within a predictable price range of the initial purchase. This allows cores to be renewed at a known price without competing against other participants in the open market.
10+
Coretime can be purchased in bulk for a period of 28 days, providing access to Polkadot's shared security and interoperability for Polkadot parachains. The bulk purchase of coretime includes a rent-control mechanism that keeps future purchases within a predictable price range of the initial purchase. This allows cores to be renewed at a known price without competing against other participants in the open market.
1111

1212
## Bulk Sale Phases
1313

@@ -125,27 +125,27 @@ To configure auto-renewal, you'll need to gather specific information for the `e
125125

126126
**Example for parachain `2000`:**
127127

128-
Current assignment (workload)
129-
```
130-
[
131-
[50]
132-
[{
133-
mask: 0xffffffffffffffffffff
134-
assignment: {Task: 2,000}
135-
}]
136-
]
137-
```
138-
139-
Future assignment (workplan)
140-
```
141-
[
142-
[[322,845, 48]]
143-
[{
144-
mask: 0xffffffffffffffffffff
145-
assignment: {Task: 2,000}
146-
}]
147-
]
148-
```
128+
- Current assignment (workload)
129+
```txt
130+
[
131+
[50]
132+
[{
133+
mask: 0xffffffffffffffffffff
134+
assignment: {Task: 2,000}
135+
}]
136+
]
137+
```
138+
139+
- Future assignment (workplan)
140+
```txt
141+
[
142+
[[322,845, 48]]
143+
[{
144+
mask: 0xffffffffffffffffffff
145+
assignment: {Task: 2,000}
146+
}]
147+
]
148+
```
149149
150150
**Note:** use the core from workplan (`48` in this example) if your task appears there. Only use the core from workload if it's not listed in workplan.
151151
@@ -246,6 +246,11 @@ Here's how to submit this XCM using Acala (Parachain 2000) as an example:
246246
247247
![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-6.webp)
248248
249-
After successful execution, your parachain should have auto-renewal enabled. To verify this, check the events emitted in the Coretime chain. You should see confirmation events similar to:
249+
After successful execution, your parachain should have auto-renewal enabled. To verify this, check the events emitted in the Coretime chain. You should see a confirmation event named `broker.AutoRenewalEnabled`, which includes two parameters:
250+
251+
- **core** - the core currently assigned to your task, in this example, `48`
252+
- **task** - the task for which auto-renewal was enabled, in this example, `2000`
253+
254+
You can find this event in the list of recent events. It should look similar to the following:
250255
251256
![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-7.webp)

‎llms.txt‎

Lines changed: 52 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -3870,21 +3870,21 @@ description: Learn how to renew coretime manually or automatically to ensure uni
38703870

38713871
## Introduction
38723872

3873-
Coretime can be purchased in bulk for a period of 28 days, providing access to Polkadot's shared security and interoperability for Polkadot Rollups (Parachains). The bulk purchase of coretime includes a rent-control mechanism that keeps future purchases within a predictable price range of the initial purchase. This allows cores to be renewed at a known price without competing against other participants in the open market.
3873+
Coretime can be purchased in bulk for a period of 28 days, providing access to Polkadot's shared security and interoperability for Polkadot parachains. The bulk purchase of coretime includes a rent-control mechanism that keeps future purchases within a predictable price range of the initial purchase. This allows cores to be renewed at a known price without competing against other participants in the open market.
38743874

38753875
## Bulk Sale Phases
38763876

38773877
The bulk sale process consists of three distinct phases:
38783878

3879-
- **Interlude phase** - the period between bulk sales when renewals are prioritized
3880-
- **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
3881-
- **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
3879+
1. **Interlude phase** - the period between bulk sales when renewals are prioritized
3880+
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
3881+
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
38823882

38833883
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.
38843884

38853885
## Renewal Timing
38863886

3887-
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.
3887+
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.
38883888

38893889
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).
38903890
Your renewal must be completed during bulk sale #2, ideally during its interlude phase, to secure coretime for the subsequent period.
@@ -3907,26 +3907,26 @@ To manually renew a core:
39073907

39083908
![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-2.webp)
39093909

3910-
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.
3910+
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.
39113911

3912-
## Auto Renewal
3912+
## Auto-Renewal
39133913

3914-
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.
3914+
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.
39153915

39163916
When auto-renewal is enabled, the system follows this process at the start of each sale:
39173917

39183918
1. The system scans all registered auto-renewal records
3919-
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)
3919+
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)
39203920
3. Upon successful payment, the system emits a `Renewed` event and secures the core for the next period
39213921
4. If payment fails due to insufficient funds or other issues, the system emits an `AutoRenewalFailed` event
39223922

3923-
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.
3923+
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.
39243924

3925-
To enable auto-renewal for your parachain, you'll need to configure several components as detailed in the following sections.
3925+
To enable auto-renewal for your parachain, you must configure several components, as detailed in the following sections.
39263926

3927-
### Set Up HRMP Channel
3927+
### Set Up an HRMP Channel
39283928

3929-
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.
3929+
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.
39303930

39313931
For instructions on establishing this connection, consult the [Opening HRMP Channels with System Parachains](/tutorials/interoperability/xcm-channels/para-to-system/){target=\_blank} guide.
39323932

@@ -3936,7 +3936,7 @@ The [sovereign account](https://github.com/polkadot-fellows/xcm-format/blob/1072
39363936

39373937
To determine your parachain's sovereign account address, you can:
39383938

3939-
- Use the "Para ID" to Address section in [Substrate Utilities](https://www.shawntabrizi.com/substrate-js-utilities/){target=\_blank} with the **Sibling** option selected
3939+
- Use the **"Para ID" to Address** section in [Substrate Utilities](https://www.shawntabrizi.com/substrate-js-utilities/){target=\_blank} with the **Sibling** option selected
39403940

39413941
- Calculate it manually:
39423942

@@ -3957,7 +3957,7 @@ To determine your parachain's sovereign account address, you can:
39573957

39583958
The Coretime chain provides two primary extrinsics for managing the auto-renewal functionality:
39593959

3960-
- [`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
3960+
- [**`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
39613961

39623962
**Parameters:**
39633963

@@ -3975,49 +3975,47 @@ The Coretime chain provides two primary extrinsics for managing the auto-renewal
39753975

39763976
**Parameters:**
39773977

3978-
- **`core`**: the core currently assigned to the task
3979-
- **`task`**: the task for which auto-renewal is enabled
3978+
- **`core`** - the core currently assigned to the task
3979+
- **`task`** - the task for which auto-renewal is enabled
39803980

3981-
### Construct the Enable Auto Renewal Extrinsic
3981+
### Construct the Enable Auto-Renewal Extrinsic
39823982

39833983
To configure auto-renewal, you'll need to gather specific information for the `enable_auto_renew` extrinsic parameters:
39843984

39853985
- **`core`** - identify which core your parachain is assigned to when the it expires. This requires checking both current assignments and planned future assignments:
3986-
- For current period - query `broker.workload()`
3987-
- For next period - query `broker.workplan()`
3986+
- **For current period** - query `broker.workload()`
3987+
- **For next period** - query `broker.workplan()`
39883988

39893989
**Example for parachain `2000`:**
39903990

3991-
Current assignment (workload)
3992-
```
3993-
[
3994-
[50]
3995-
[{
3996-
mask: 0xffffffffffffffffffff
3997-
assignment: {Task: 2,000}
3998-
}]
3999-
]
4000-
```
3991+
- Current assignment (workload)
3992+
```txt
3993+
[
3994+
[50]
3995+
[{
3996+
mask: 0xffffffffffffffffffff
3997+
assignment: {Task: 2,000}
3998+
}]
3999+
]
4000+
```
40014001

4002-
Future assignment (workplan)
4003-
```
4004-
[
4005-
[[322,845, 48]]
4006-
[{
4007-
mask: 0xffffffffffffffffffff
4008-
assignment: {Task: 2,000}
4009-
}]
4010-
]
4011-
```
4002+
- Future assignment (workplan)
4003+
```txt
4004+
[
4005+
[[322,845, 48]]
4006+
[{
4007+
mask: 0xffffffffffffffffffff
4008+
assignment: {Task: 2,000}
4009+
}]
4010+
]
4011+
```
40124012

40134013
**Note:** use the core from workplan (`48` in this example) if your task appears there. Only use the core from workload if it's not listed in workplan.
40144014

40154015
- **`task`** - use your parachain ID, which can be verified by connecting to your parachain and querying `parachainInfo.parachainId()`
40164016

40174017
- **`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:
4018-
- If the parachain uses bulk coretime:
4019-
4020-
Query `broker.saleinfo`. You’ll get a result like:
4018+
- If the parachain uses bulk coretime, query `broker.saleinfo`. You’ll get a result like:
40214019

40224020
```json
40234021
{
@@ -4039,9 +4037,7 @@ To configure auto-renewal, you'll need to gather specific information for the `e
40394037
- 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`
40404038

40414039

4042-
- If the parachain has a lease:
4043-
4044-
Query `broker.leases`, which returns entries like:
4040+
- If the parachain has a lease, query `broker.leases`, which returns entries like:
40454041

40464042
```json
40474043
[
@@ -4069,15 +4065,15 @@ Once you have these values, construct the extrinsic:
40694065

40704066
![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-3.webp)
40714067

4072-
For parachain `2000` on core `48` with `workload_end_hint` `327885`, the encoded call data would be:`0x32153000d007000001cd000500`
4068+
For parachain `2000` on core `48` with `workload_end_hint` `327885`, the **encoded call data** is:`0x32153000d007000001cd000500`
40734069

4074-
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:
4070+
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
40754071

40764072
![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-4.webp)
40774073

4078-
### Submit the XCM from your Parachain
4074+
### Submit the XCM from Your Parachain
40794075

4080-
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.
4076+
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.
40814077

40824078
The XCM needs to execute these operations:
40834079

@@ -4113,7 +4109,12 @@ Here's how to submit this XCM using Acala (Parachain 2000) as an example:
41134109

41144110
![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-6.webp)
41154111

4116-
After successful execution, your parachain should have auto-renewal enabled. To verify this, check the events emitted in the Coretime chain. You should see confirmation events similar to:
4112+
After successful execution, your parachain should have auto-renewal enabled. To verify this, check the events emitted in the Coretime chain. You should see a confirmation event named `broker.AutoRenewalEnabled`, which includes two parameters:
4113+
4114+
- **core** - the core currently assigned to your task, in this example, `48`
4115+
- **task** - the task for which auto-renewal was enabled, in this example, `2000`
4116+
4117+
You can find this event in the list of recent events. It should look similar to the following:
41174118

41184119
![](/images/develop/parachains/deployment/coretime-renewal/coretime-renewal-7.webp)
41194120
--- END CONTENT ---

0 commit comments

Comments
 (0)