Previously, if a parachain wants to continue running and extend lease on Polkadot/Kusama, after winning first slot with crowdloan, it would need to perform direct bid or to get slot with different ParaId and perform swap of leases.

I am aware that there were some changes in locking mechanism implemented according to RFC-0014: Improve locking mechanism for parachains,

I want to check if I can open a crowdloan with ParaId of already running parachain, and get lease extension for a second time with a new crowdloan, if I also won initial slot with crowdloan and that this slot is not expired.

Target is to have no downtime and also no overlapping leases.

Additionally, what is best way to test this in local environment, is it running a zombienet? How to quickly simulate this situation?

  • I believe you can find the answer to your question here.
    – kianenigma
    Commented Feb 7 at 22:18

1 Answer 1


There are two things to consider here, non of which are changed with RFC-14:

  1. A paraID can't have a Crowdloan Fund if there is already an existing fund mapped to that paraID (source).
  2. A Crowdloan Fund campaign for a specific paraID will last from the moment it's open until it's dissolved.

When a team wins an auction utilizing a Crowdloan, then the funds locked in the Crowdloan Fund are released when the lease of the paraID finishes. This means that until the paraID is out of leases, then a new Crowdloan Fund Campaign can't be open for that paraID.

The reason for this is that the system was design with the idea that projects would use the Crowdloan mechanism for their first onboarding on to Polkadot, but would then renew the leases by direct-bidding.

As for how to test this, the best way that comes to mind is running zombienet locally, but compiling with the fast-runtime flag for building Polkadot. Otherwise times will be very long.

Extending a lease with a Crowdloan and no Overlapping slots

This methodology of extending a Parachain's lease on Polkadot will result in some downtime.

If a team wants to extend their lease using a Crowdloan and with no Overlapping slots, then the steps to execute this are:

  1. Reserve a new paraID (new_para_id) and register a parachain. The registration doesn't need to be a valid parachain, as the objective is not for this parachain to ever work.
  2. Open a Crowdloan with for new_para_id.
  3. Win an Auction.
  4. Call the swap function on the registrar pallet of the parachain from the existing parachain (current_para_id). Swap(current_para_id, new_para_id). If the parachain is unlocked, then the account that owns the paraID on the relay chain can call this, otherwise this needs to be an UMP from the parachain to the relay chain.
  5. Call the swap function from the new_para_id. Swap(new_para_id, current_para_id). With RFC14 parachain will be unlocked unlocked, so the account that owns the paraID on the relay chain can call this function.

Important considerations:

  • Step (4) needs to happen before the current parachain is offboarded. Otherwise this will not work.
  • Step (5) needs to be done as close as possible to the boundary of the change in the Lease Period to minimize downtime. As these are non-overalapping Lease Periods, the moment the swap function is called the leases will be switched. Therefore the closes the swap is executed to the boundary of the change in Lease Period, the smaller the downtime will be.
  • Steps (3) and (4) are not strictly necessary concurrent. The swap from the existing parachain can be called at anytime.

Other references

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.