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

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)