[Kusama] Request for a Root referendum: deregister ParaId 2270 to release a locked 235.468 KSM registration deposit

Governance
1

Hi everyone,

I am the manager of ParaId 2270 on Kusama. The lease expired long ago and the chain is dead, but the registration deposit of ~235.468 KSM is permanently stuck because the para is still flagged as locked. No signed extrinsic from the manager account can release it. I would like to request a Root-origin referendum to deregister the ParaId so that the deposit is returned.

On-chain state (anyone can verify)

Manager account: Ggyx6maeuWuKR6RkF4UiSEANZLejTVypJ9atP6jwCVvthJj

registrar.paras(2270):
  manager: Ggyx6maeuWuKR6RkF4UiSEANZLejTVypJ9atP6jwCVvthJj
  deposit: 235,467,999,804,532   (235.467999804532 KSM)
  locked:  true

slots.leases(2270):    []      -> no current or upcoming lease
crowdloan.funds(2270): None    -> crowdloan fully refunded and dissolved, contributors repaid in 2024
Para lifecycle:        parathread, not producing blocks

The manager account currently holds 0.000333 KSM free and 235.467 KSM reserved, so it cannot even pay transaction fees.

Dry-run evidence (dryRunApi.dryRunCall)

(1) Signed(manager) -> registrar.deregister(2270)
    Err: Module { index: 70, error: 0x0a000000 }  = registrar.ParaLocked

(2) Signed(manager) -> registrar.removeLock(2270)
    Err: BadOrigin

(3) Signed(manager) -> registrar.swap(2270, other)
    Err: Module { index: 70, error: 0x0a000000 }  = registrar.ParaLocked

(4) Origins::LeaseAdmin -> registrar.deregister(2270)
    Err: BadOrigin

(5) Origins::GeneralAdmin -> registrar.deregister(2270)
    Err: BadOrigin

(6) Root -> registrar.deregister(2270)
    Ok. Emitted events:
      balances.Unreserved { who: Ggyx6maeuWuKR6RkF4UiSEANZLejTVypJ9atP6jwCVvthJj,
                            amount: 235,467,996,471,199 }
      registrar.Deregistered { paraId: 2270 }

(7) ParachainsOrigin::Parachain(2270) -> registrar.removeLock(2270)
    Ok  (not actionable: para 2270 produces no blocks and cannot send XCM)

In other words, the runtime accepts exactly two origins here: Root, or the parachain itself. The second one is unreachable because the chain is dead.

Proposed call

Primary option, which returns the deposit to the manager in a single step:

registrar.deregister(id: 2270)
call data: 0x4602de080000

Alternative, if a less destructive action is preferred (I would then submit and pay for the deregistration myself):

registrar.removeLock(para: 2270)
call data: 0x4604de080000

Notes

No treasury funds are requested. The only effect is unreserving a deposit that already belongs to the manager account. It also frees ParaId 2270 and removes dead state from the relay chain.

I can cover the submission deposit (3.3333 KSM), but the Root track decision deposit is 3,333.33 KSM, which I cannot fund. Since the decision deposit can be placed by any account and is refunded when the referendum concludes, I would be very grateful if someone were willing to place it.

Happy to provide any further verification, or to reproduce the dry runs live for anyone who asks.

Thanks for reading.

2

Update: the referendum is now live. Kusama OpenGov referendum 664, on the Root track.

Since I opened this thread Kusama completed the Asset Hub migration, so OpenGov now lives on Kusama Asset Hub while the registrar pallet stays on the relay chain. The proposal therefore had to be built as a cross-chain call rather than a plain registrar.deregister. With Root origin on Asset Hub it dispatches polkadotXcm.send to the relay chain carrying UnpaidExecution followed by Transact with originKind Superuser and the call registrar.deregister(2270).

Referendum: SubSquare | kusama governance platform

Relay chain call: 0x4602de080000 which is registrar.deregister(2270)

Asset Hub call: 0x1f0003010003082f000006020300286bee02350c00184602de080000

I verified the whole path with the runtime dry-run APIs before spending anything, so there is no guesswork about the outcome. DryRunApi.dryRunXcm on the relay chain, with origin location (0, X1(Parachain(1000))) and exactly the message above, returns Ok and Complete and emits precisely two events: balances.Unreserved for Ggyx6maeuWuKR6RkF4UiSEANZLejTVypJ9atP6jwCVvthJj of 235,467,996,471,199 planck, and registrar.Deregistered for paraId 2270. Nothing else is touched. DryRunApi.dryRunCall on Asset Hub confirmed that the submission itself succeeds and creates the referendum on track 0. Both dry runs are free and anyone can reproduce them.

Why Root is the only route. registrar.paras(2270) still reports locked as true. A signed call from the manager returns ParaLocked, removeLock from the manager returns BadOrigin, and swap returns ParaLocked. The only non-Root path is the parachain calling removeLock on itself through its own ParachainsOrigin, which I also dry-ran successfully, but it is unusable in practice: ParaId 2270 was registered by a third-party team that no longer operates, the chain has not produced a block since the lease ended, and nobody is able to run it in order to emit that message.

Precedent. This is not a new category of request. Referendum 590, titled Deregister paraID 2114: Turing Network, was the same ask on the Root track. It passed with roughly 1.62M KSM aye and zero nay across 140 votes, a third party placed the 3,333.33 KSM decision deposit on 2025-09-12, and it entered its confirmation period on 2025-10-06. It was then cancelled on 2025-10-07 and never executed. registrar.paras(2114) today still reports locked as true with 63.14 KSM stuck, so that team is in exactly the same position I am in.

What I am asking for. Referendum 664 is in the preparing phase and needs the Root track decision deposit of 3,333.33 KSM before it can start deciding. I cannot cover that myself. The deposit is fully refundable, it can be placed by anyone through referenda.placeDecisionDeposit(664) on Kusama Asset Hub, and it is returned when the referendum concludes. If nobody places it, the referendum times out in 14 days and the deposit stays locked for good.

Two further points I would welcome input on. First, if it makes a single Root deposit easier to justify, I am entirely happy for one referendum to deregister both 2270 and 2114 so that one deposit clears both stuck cases at once. The manager of 2114 is CmxJEdEniSV6hGWoKfHWLR6h4A1dh5gD1vgzmD12osJvGsk. Second, I noticed that recent referenda such as 660 to 663 dispatch polkadotXcm.send from the Staking Admin track rather than from Root. If some cheaper Asset Hub track is able to send a Superuser Transact to the relay chain, the deposit requirement would drop enormously and I would gladly withdraw this one and resubmit there. I was not able to verify that myself, so if anyone familiar with the post-migration Asset Hub XCM origin configuration can confirm or rule it out, that would help a great deal.

Thanks to anyone who takes the time to look at this.

3

I will downvote this with my Kusama whale friends, specially how you call KSM “dead”. This will bring greater sell pressure for KSM and if it says that you need 3,333.33 KSM then you need 3,333.33 KSM.

4

Thanks for reading it and for saying it straight. I think we disagree less than it looks, so let me clear up two things.

I did not call KSM dead. The phrase in the opening post is that the deregistration removes dead state from the relay chain, and that refers to ParaId 2270 itself. Its lease ended long ago, it has not produced a block since, and nobody can run it because the team that registered it no longer exists. What is dead is that parachain entry, not the network. I am going through OpenGov precisely because I think the process works.

On sell pressure, a deregistration does not mint anything. The 235.468 KSM already exist and are already counted in issuance. They only move from reserved to free inside one account, and nothing else on chain changes. The alternative is not fewer KSM in circulation, it is the same KSM frozen forever in a registration for a chain that will never run again.

On the deposit, you are right that the rule is the rule, and I am not asking anyone to waive it. The Root track requires 3,333.33 KSM and it has to be posted. What I am asking is whether someone is willing to place it, because it is refundable and it returns to whoever placed it once the referendum concludes. That is exactly what happened in referendum 491, deregister parathread 3390, where a third party placed the same 3,333.33 KSM on 2025-02-10 and the referendum executed on 2025-02-26.

And of course you are free to vote nay. I would much rather have this decided on its merits by people who actually looked at it than have it time out unseen. If you think a cheaper track is the right home for this kind of cleanup, that pointer would genuinely help, I raised the question in my previous post and I have no attachment to Root.

5

I would suggest setting up an on-chain identity through https://dotid.app/. People may be hesitant to engage with an anonymous proposer, especially when the referendum needs someone else to place a decision deposit. An identity makes it easier to find support. I would also like to get in touch with you directly. Could you send me a message?

6

Thanks for the suggestion. The manager account Ggyx6maeuWuKR6RkF4UiSEANZLejTVypJ9atP6jwCVvthJj now has an on-chain identity on Kusama People (CanaryNest2270). Happy to talk. My forum account is new, so it can’t send private messages yet. Could you DM me here instead? I’ll reply right away.

7

Im unable to dm you. You can reach me on X or TG (@Just_Luuuu) or Matrix: @just_luuu:matrix.org

8

Update on Ref 664: the decision deposit was placed on Sept 30 (thank you to whoever placed it), and support keeps growing: 23 aye votes (~4.79K KSM) vs 1 nay (900 KSM), i.e. ~84% approval.

However, the referendum has been stuck in Queueing since then. On-chain it shows inQueue: true and deciding: null, while no other Root-track referendum is currently deciding (SubSquare shows 0/1 for the track).

That suggests referenda.decidingCount(0) on Kusama Asset Hub may be out of sync, possibly since the migration. If so, the queue will never advance on its own, and a Root referendum to fix it would get stuck in the same queue. Could someone with chain access check referenda.decidingCount(0) and referenda.trackQueue(0)?

If the count is indeed stuck, would the Fellowship consider whitelisting either a fix or the deregister call itself, so it can go through the Whitelisted Caller track?

@Luuu thanks, I’ll reach out on Matrix.

9

@CheeryEmber62 There is an issue with the stuck Root track. The fix is on the way: https://kusama.subsquare.io/referenda/668 . Should be whitelisted; hopefully fixed soon.

10

Thanks a lot @Luuu, and thanks to whoever put together Ref 668 and tested it on a Chopsticks fork, much appreciated. I’ll keep an eye on the Fellowship whitelist and on 664 once it enters Deciding. If there’s anything I can do to help move this along, just let me know.