EDIT - *No-one has objected, so I'm going to go ahead with this.*

EDIT AGAIN - Passed and executed correctly.  Thank you to everyone who supported it!

I'm interested in the communities views on whether the following is technically feasible and whether they would likely support it, please.

We're coming to the end of the Kabocha parachain lease (paraid 2113), and we've secured another lease on another paraid (2268).  Unfortunately, I hadn't realised that the parathread would instantly upgrade to a parachain and lock lease swaps, so we're going to need to use a root referendum to resolve it.

However, there are a few other longer term issue that we'd like to resolve at the same time, if possible.  The current paraid is on a regular single owner account.  We'd like to move it to another account - probably a pure proxy so we can update control of the account as key people move in and out of the project.  I believe there isn't currently a way to update the manager of a paraid?

With that in mind, and noting that Kabocha will revert to a parathread in a few days, I'd like to set up a root track referendum that does the following in a batch (in order):

1. registrar.deregister(2113) - release the paraid from the current holder and free the reserved balance.

<wait 2 epoch for offboarding>

2. registrar.forceRegister() - with the pure proxy account, standard 280.3KSM deposit (see below), paraid 2113, and the head hash and validation_code at the point where Kabocha stops making blocks (not yet known).

<wait 2 epoch for onboarding - might not be strictly necessary>

3. registrar.swap(2113,2268)
4. registrar.swap(2268,2113)

My assumption is that this will move the paraid to the new account, offboard 2268 and onboard 2113 as parachains, and Kabocha should start making blocks again.  Is there anything fundamentally wrong with this assumption?  Or, indeed, is it too complex for the community to allow, perhaps?

Validation wise, we can set remarks from the accounts involved (the current manager accounts for the two paraids and the new pure proxy), to confirm intent.  Is this sufficient?

[About Kabocha, for anyone not familiar](https://forum.polkadot.network/t/introducing-kabocha-an-experimental-kusama-parachain-incubated-by-the-edgeware-community/327)


EDIT to add **validation on-chain remarks**

[Paraid 2268 manager account](https://kusama.subscan.io/extrinsic/18149800-2)

[New paraid 2113 manager account, via proxy](https://kusama.subscan.io/extrinsic/18149835-2)

[Old paraid 2113 manager account](https://kusama.subscan.io/extrinsic/18154737-2)


EDIT to add **notes on deposit for forceRegister()**

The fee for setting the parachain PVF and head is just under 280.3KSM (this is more than the fee when Kabocha was first registered).  I will use the current fee in the forceRegister() extrinsic.

![image](https://i.ibb.co/RpQRz5S/4031-jelliedowl-1685570490210.png)

EDIT: In case it's useful for anyone in future - this is the preimage I used:
![image](https://i.ibb.co/jLtPpdB/4031-jelliedowl-1687038852464.png)

EDIT - *No-one has objected, so I'm going to go ahead with this.*

I'm interested in the communities views on whether the following is technically feasible and whether they would likely support it, please.

We're coming to the end of the Kabocha parachain lease (paraid 2113), and we've secured another lease on another paraid (2268).  Unfortunately, I hadn't realised that the parathread would instantly upgrade to a parachain and lock lease swaps, so we're going to need to use a root referendum to resolve it.

However, there are a few other longer term issue that we'd like to resolve at the same time, if possible.  The current paraid is on a regular single owner account.  We'd like to move it to another account - probably a pure proxy so we can update control of the account as key people move in and out of the project.  I believe there isn't currently a way to update the manager of a paraid?

With that in mind, and noting that Kabocha will revert to a parathread in a few days, I'd like to set up a root track referendum that does the following in a batch (in order):

1. registrar.deregister(2113) - release the paraid from the current holder and free the reserved balance.

<wait 2 epoch for offboarding>

2. registrar.forceRegister() - with the pure proxy account, standard 280.3KSM deposit (see below), paraid 2113, and the head hash and validation_code at the point where Kabocha stops making blocks (not yet known).

<wait 2 epoch for onboarding - might not be strictly necessary>

3. registrar.swap(2113,2268)
4. registrar.swap(2268,2113)

My assumption is that this will move the paraid to the new account, offboard 2268 and onboard 2113 as parachains, and Kabocha should start making blocks again.  Is there anything fundamentally wrong with this assumption?  Or, indeed, is it too complex for the community to allow, perhaps?

Validation wise, we can set remarks from the accounts involved (the current manager accounts for the two paraids and the new pure proxy), to confirm intent.  Is this sufficient?

[About Kabocha, for anyone not familiar](https://forum.polkadot.network/t/introducing-kabocha-an-experimental-kusama-parachain-incubated-by-the-edgeware-community/327)


EDIT to add **validation on-chain remarks**

[Paraid 2268 manager account](https://kusama.subscan.io/extrinsic/18149800-2)

[New paraid 2113 manager account, via proxy](https://kusama.subscan.io/extrinsic/18149835-2)

[Old paraid 2113 manager account](https://kusama.subscan.io/extrinsic/18154737-2)


EDIT to add **notes on deposit for forceRegister()**

The fee for setting the parachain PVF and head is just under 280.3KSM (this is more than the fee when Kabocha was first registered).  I will use the current fee in the forceRegister() extrinsic.

![image](https://i.ibb.co/RpQRz5S/4031-jelliedowl-1685570490210.png)

Moving a paraid to a new manager address - Kabocha

Root

Send a batch of dispatch calls.

May be called from any origin except `None`.

- `calls`: The calls to be dispatched from the same origin. The number of call must not
  exceed the constant: `batched_calls_limit` (available in constant metadata).

If origin is root then the calls are dispatched without checking origin filter. (This
includes bypassing `frame_system::Config::BaseCallFilter`).

## Complexity
- O(C) where C is the number of calls to be batched.

This will return `Ok` in all circumstances. To determine the success of the batch, an
event is deposited. If a call failed and the batch was interrupted, then the
`BatchInterrupted` event is deposited, along with the number of successful calls made
and the error of the failed call. If all were successful, then the `BatchCompleted`
event is deposited.



1. Create a root referendum to move paraid 2113 to a pure proxy account
2. Deregister paraid 2113 and free reserved balance
3. Wait two epochs for offboarding
4. Force register paraid 2113 to the proxy account with a 280.3KSM deposit
5. Wait two epochs for onboarding (might not be necessary)
6. Swap paraid 2113 and 2268
7. Swap paraid 2268 and 2113 
8. Give validation on-chain remarks for the manager accounts for the two paraids and the new proxy account
9. Use a preimage with the proposed fee for setting the parachain PVF and head to the forceRegister() extrinsic.

#213 Moving a paraid to a new manager address - Kabocha