I posted this in on the Kusama Polkassembly, but there might be some of it that’s relevant to the ecosystem in general.
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 (Kusama Gov 2) root track referendum that does the following in a batch (in order):
- registrar.deregister(2113) - release the paraid from the current holder and free the reserved balance.
- registrar.forceRegister() - with the pure proxy account, standard 40KSM deposit, paraid 2113, and the head hash and validation_code at the point where Kabocha stops making blocks (not yet known).
- registrar.swap(2113,2268)
- 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
I don’t see any problems with the proposed approach. The different steps you mention seem to make sense.
Having into account that 2113 is going to loose its parachain lifecycle status shortly ( being LP#29 its last one ) there are not many options other than going through governance.
Even more, steps 2 and 3 require you to open this to community scrutiny.
{
manager: F37GR5PvHiNj8YWVegr8r2nMosBDtiPVdUrfBSAMZg3e5HJ
deposit: 58,675,999,813,240
locked: true
}
And by the time it stops producing blocks won’t be able to dispatch this call with para as origin.
This said, I would expect the community to come with questions around the manager account change, there are better forums for that conversation anyway.
EDIT: Typo
1 Like
Thank you Alejandro
Plus we don’t have XCM open on Kabocha, and 2268 is also manager looked, so I think step 1 is the only one that wouldn’t need root. But it makes sense to do step 1 as part of the batch, I think.
Do I need to include any delays between steps (assuming you can do that with a batch) or should be all work OK on the same block?
It should work fine just by batching all those calls together, I don’t see any need of scheduling any of those calls for a later execution.
EDIT: At the moment of writing I was just thinking about operations 2, 3 and 4. Which makes this statement wrong.
1 Like
Ah, it looks like it does need some scheduling:
Step 1 → wait 2 epochs for the parathread to offboard → step 2 → wait 2 epochs for the parathread to onboard → steps 3 & 4
registrar.forceRegister() fails with “registrar.AlreadyRegistered” if called too quickly after registrar.deregister()
Indeed.
With that para lock in place you will have to deregister the para via governance as well. So that forces you to do everything from step 1 on some epochs later.
1 Like
I think the swaps might fail if the parathread is still onboarding too? Anyway, it’s only a few extra hours of delay, so I’ll schedule 3 and 4 to wait after 2 happens as well.
(I think the lock on 2113 might be removed when the crowdloan is dissolved - which should happen shortly - but I think I want to include it in the referendum for completeness, rather than releasing it now and it being less clear who had it before.)
1 Like
The referendum passed and executed correctly. Making block again.
In case it’s useful for anyone in future, since a lot of the explorers don’t seem to display the preimage correctly, here is a copy:
1 Like
