With on-demand parachain functionality enabled by Agile Coretime on Polkadot, there will be a significant growth in the number of parachains registering a ParaID and their wasm code, which locks away several hundreds of DOT.
Currently, only the root origin is capable of deregistering a parachain that has produced blocks. For more context, please view this discussion on StackExchange.
The key argument presented in that discussion is that the parachain manager account should forego their privilege of deregistering the parachain if it has produced blocks, as it aligns with the principles of decentralized networks. Do we want to hold every on-demand parachain to this standard? In the current setup, each on-demand parachain’s deposit in DOT is held hostage till the lock is removed through Polkadot OpenGov. Please let me know if there is any other way to deregister parachain that does not involve governance.
Two years later this is still exactly the situation, and I ran into it last week on Kusama with ParaId 2270. The lease ended long ago, the chain has not produced a block since, the team that registered it no longer operates, and 235.468 KSM stay reserved. From the manager account, registrar.deregister returns ParaLocked, removeLock returns BadOrigin, and swap returns ParaLocked, so Root really is the only door.
One detail worth recording for anyone who hits this after the Asset Hub migration. OpenGov now lives on Kusama Asset Hub while the registrar pallet stays on the relay chain, so the proposal can no longer be a plain registrar.deregister. It has to be polkadotXcm.send from Asset Hub to the relay chain carrying UnpaidExecution and then Transact with originKind Superuser. DryRunApi.dryRunXcm on the relay chain confirms it returns Complete and emits exactly balances.Unreserved and registrar.Deregistered, so the whole thing can be verified for free before spending anything.
The economics of the current design are the real problem. On Kusama the Root decision deposit is 3,333.33 KSM, which is more than fourteen times the 235.468 KSM that the referendum would release, and on Polkadot the ratio is worse. The deposit is refundable, but somebody still has to own it and immobilise it for the length of the referendum, so in practice a modest stuck deposit is unrecoverable unless a large holder volunteers to front it. That turns a mechanical cleanup into a favour.
Two questions I would genuinely like answered. Is there any cheaper Asset Hub track whose origin is allowed to send a Superuser Transact to the relay chain, or is Root strictly required for this class of call. And would it be reasonable to let the manager deregister once a para has been out of a lease and has produced no blocks for some long, clearly defined period, or alternatively to route these cleanups through a dedicated low deposit track. As things stand, every abandoned ParaID quietly locks its deposit forever, and the number of them only grows.