## Change core count to 100 on Kusama
Our referendum will send an XCM to the coretime chain with a transact containing [`request_core_count` with 100 cores](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-coretime-rpc.polkadot.io#/extrinsics/decode/0x32126400).
[This](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.dwellir.com#/extrinsics/decode/0x630004000100b50f04082f00000602028c8f84f1551032126400) is the call for the referendum (including ~1.5x safety factor), which has the hash: `0x630004000100b50f04082f00000602028c8f84f1551032126400`.

We can fire up chopsticks and use the scheduler to execute this.

bunx --bun @acala-network/chopsticks@latest xcm -r kusama.yml -p ./kusama-people.yml

Open the [Coretime Chain](https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A8000) to watch the events.
Go to the [Javascript](https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A8001#/js) tab on the relay chain, clear the code and add:

// Grab the block number of the current head
// api is already imported, no need to add anything but the following.
const number = (await api.rpc.chain.getHeader()).number.toNumber()

// use chopsticks dev_setStorage to inject the call into the scheduler state for the next block. The value of `Inline` is just the call data. Crucially with this call we can set the origin to `Root`
await api.rpc('dev_setStorage', {
  scheduler: {
    agenda: [
      [
        [number + 1], [
          {
            call: {
              Inline: '0x630004000100b50f04082f00000602028c8f84f1551032126400'
            },
            origin: {
              system: 'Root'
            }
          }
        ]
      ]
    ]
  }
})
// Make a block to include the extrinsic
await api.rpc('dev_newBlock', { count: 1 })

Now we can see from the events that the message was sent on the relay, received and executed on the coretime chain and we have a `broker.CoreCountRequested` event with 100 cores.

Back to the relay chain, we can check the chain state `configuration.pendingConfig` and scroll down to find `coretimeCores: 100`.
Sweet! now let's make some blocks on the relay to get through the two session boundaries and make sure there are no problems with the coretime chain when we apply the config. This number depends on when you forked the chain, but you can watch the chain state `session.index` and wait until it is equal to the one that the `pendingConfig` containing the 100 cores is at.
Go to the [Javascript](https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A8001#/js) tab on the relay chain, clear the code and add:

await api.rpc('dev_newBlock', { count: 1200 })

My laptop makes around 2 blocks per second, so this won't take long.

We're looking for the new session, then we can double check that the configuration has changes the `coretimeCores: 100`, then go to the coretime chain and we see that a message has been processed, and we get a `broker.CoreCountChanged` event with a value of 100.

Also checking the coretime chain state `broker.status` should show `coreCount: 100`. If you want you can keep spinning out cores on the coretime chain to check that the cores are offered for sale at the next sale boundary, then buy them all and assign them, but I'll not go that far.