# Polkadot Coretime Auto-Renewal

Link to official docs created based on this document
: https://docs.polkadot.com/develop/parachains/deployment/coretime-renewal/

Coretime can be purchased in bulk for a period of 28 days, which providing access to Polkadot's shared security and interoperability to the Polkadot Rollups (Parachains). The purchase of bulk coretime comes with the benefit of rent-control mechanism where the future purchases are within a predictable range of the initial price. Check out the coretime reneal FAQ [here](https://docs.regionx.tech/docs/faq/renewal-questions).

This tutorial is created based on the information presented in this document: [Coretime Auto-Renewal](https://hackmd.io/iPBa8A5uSGawhSkk4API2w)

The snapshot below is from [RegionX Parachains Dashboard](https://app.regionx.tech/paras?network=polkadot) which shows the parachain with `ParaID 2000` has purchased coretime on the core number `48`.


It is possible to renew the core by issuing the `broker.renew(CoreNumber)` extrinsic during the interlude period during coretime sale period when rent-control still applies. While this is pretty straightforward, it requires this manual step of issuing the extrinsic. If this task is forgotten, and all the available cores are sold, the parachain will be in a pickle like the one below!


## Enable Auto-Renewal of Coretime

To enable auto-renewal of coretime for a parachain, we need to ensure the following information is handy.

- **ParaID** - you can query the chain state using `parachainInfo.parachainId()` on your parachain. For the example in this document, we will use `ParaID 2000` shown earlier in the snapshot.
- **Core Number** - To which core the parachain is assigned to when the lease is going to expire and will be up for renewal. This may not be trivial to find out. For instance, Acala parachain shown in the earlier snapshot is assigned to a different core in the current period and in the next period when its lease is set to expire, it is assigned to `core 48`. This was evident when querying `broker.workload()` which shows current period information and `broker.workplan()` which shows next period information.
- **Workload End Hint** - this is the last time slice number of the sale period during which the lease is set to expire (more on this later in this tutorial). For chains with long lasting leases that were acquired through auctions, this information can be queried on-chain through `broker.leases()`.

It is also important to know

- Who has `Root` Origin access on Parachain? - If the parachain has a sudo pallet, it can be used to dispatch the XCM call containing the auto-renewal extrinsic to the Coretime chain. If `Root` Origin can only be controlled by the governance on-chain, then the parachain needs to issue the XCM call via governance.
- What is the Sibling account address for the parachain on the Coretime chain? I used [Shawn Tabrizi's Substrate Utilities](https://www.shawntabrizi.com/substrate-js-utilities/) to figure out the sibling account of Acala (ParaID 2000) on the Coretime chain. This Sibling account address `5Eg2fntJ27qsari4FGrGhrMqKFDRnkNSR6UshkZYBGXmSuC8` is the sovereign account of Acala on Coretime chain. Add enough funds on this account to buy XCM execution time on the Coretime chain and also to pay for auto-renewal costs.


## Chopsticks Demo

[Acala Chopsticks](https://github.com/AcalaNetwork/chopsticks/) is a resourceful tool when it comes to runtime testing and cross-chain testing.

`npx @acala-network/chopsticks@latest xcm -p polkadot-coretime -p acala`

This creates a cross-chain runtime test setup where you can use tools like Polkadot-JS or PAPI explorer to listen to ports 8000 and 8001 on the local machine and you are plugged into both Acala and Polkadot Coretime chain runtime instances with chain configs imported from Acala Chopsticks GitHub repository. The beauty of this setup is that it does not require running full nodes and comes with a lot of customizability.

The configs allow for adding new accounts and balances, sudo privileges (if the chain allows for it) and whole lot of other customizations to the chain state. If you like to make any custom changes, you can do it on your local machine and ensure you pick that local config when you start Chopsticks.

`npx @acala-network/chopsticks@latest xcm -p polkadot-coretime -p configs/acala.yml`

The tutorial below uses the former command where the configs are used as is from Acala Chopsticks GitHub repository.

### Coretime Chain

Navigate to the Polkadot Coretime chain running on Chopsticks and send some DOT to Acala's sovereign account (Sibling account of ParaID 2000)


Construct the extrinsic that will enable Auto-Renewal for Acala given its ParaID 2000, Core Number 48 and the lease ending timeslice number 327885. Wait, how did I get that number? A little backdrop on timeslices: Each timeslice is 80 blocks in length. 5040 timeslices make up for 403200 blocks of 6 seconds which correspond to 28 days (bulk coretime period).

As I know Acala already renewed for the next period, I queried `broker.saleinfo()` on-chain and figured that the last timeslice of that period is 327885.


Now, with the information above, we can construct the extrinsic for auto-renewal as shown below and here is the call data for your reference `0x32153000d007000001cd000500`. Copy over the call data as this needs to be sent via XCM from your parachain.


One last thing before we move to our parachain: check the transaction weights for executing the auto-renew call on Coretime chain. You can query them through the `transactionCallPaymentApi` made available as a runtime call.


### Parachain

Here is the call data for sending sudo call from the parachain that dispatches through PolkadotXCM pallet, which

- withdraws 1 DOT from the parachain's sovereign account on coretime chain
- Buys execution for 1 DOT
- transacts `0x32153000d007000001cd000500` with weights specified through the sovereign account of the parachain
- refunds surplus DOT back to the sovereign account

Here is the call data for your reference:

`0xff00330003010100b50f03140004000100000700e40b540213000100000700e40b5402000601623e71e5d1603432153000d007000001cd000500140d0100000100411f`

**If there are problems with sending this call**, ensure the XCM configuration on your chain is correct. For this demo, I sent `polkadotXcm.forceSubscribeVersionNotify(location)` and that resolved the error for me. Here is the call data`0xff00330603010100b50f` I used.


The XCM call is then executed on the Coretime chain and the following events are emitted


You can query the chain state to check if your chain is up for auto-renewal