I have proposed <a href="https://github.com/polkadot-fellows/RFCs/pull/14">RFC14 - Improve locking mechanism for parachains</a> and it has been accepted by the Fellowship. I have also completed the <a href="https://github.com/paritytech/polkadot-sdk/pull/1290">implementation for RFC14.</a>
Summary for RFC 14:
This RFC proposes a set of changes to the parachain lock mechanism. The goal is to allow a parachain manager to self-service the parachain without root track governance action.
This is achieved by remove existing lock conditions and only lock a parachain when:
&mdash; A parachain manager explicitly lock the parachain
&mdash; OR a parachain block is produced successfully
Motivation for RFC14
The manager of a parachain has permission to manage the parachain when the parachain is unlocked. Parachains are by default locked when onboarded to a slot. This requires the parachain wasm/genesis must be valid, otherwise a root track governance action on relaychain is required to update the parachain.
The current reliance on root track governance actions for managing parachains can be time-consuming and burdensome. This RFC aims to address this technical difficulty by allowing parachain managers to take self-service actions, rather than relying on general public voting.
The key scenarios this RFC seeks to improve are:
1. Rescue a parachain with invalid wasm/genesis.
While we have various resources and templates to build a new parachain, it is still not a trivial task. It is very easy to make a mistake and resulting an invalid wasm/genesis. With lack of tools to help detect those issues1, it is very likely that the issues are only discovered after the parachain is onboarded on a slot. In this case, the parachain is locked and the parachain team has to go through a lengthy governance process to rescue the parachain.
2. Perform lease renewal for an existing parachain.
One way to perform lease renewal for a parachain is by doing a least swap with another parachain with a longer lease. This requires the other parachain must be operational and able to perform XCM transact call into relaychain to dispatch the swap call. Combined with the overhead of setting up a new parachain, this is an time consuming and expensive process. Ideally, the parachain manager should be able to perform the lease swap call without having a running parachain2.

I have proposed [RFC14 - Improve locking mechanism for parachains](https://github.com/polkadot-fellows/RFCs/pull/14) and it has been accepted by the Fellowship. I have also completed the [implementation for RFC14.](https://github.com/paritytech/polkadot-sdk/pull/1290)

**Summary for RFC 14:**

This RFC proposes a set of changes to the parachain lock mechanism. The goal is to allow a parachain manager to self-service the parachain without root track governance action.

This is achieved by remove existing lock conditions and only lock a parachain when:

— A parachain manager explicitly lock the parachain

— OR a parachain block is produced successfully

**Motivation for RFC14**

The manager of a parachain has permission to manage the parachain when the parachain is unlocked. Parachains are by default locked when onboarded to a slot. This requires the parachain wasm/genesis must be valid, otherwise a root track governance action on relaychain is required to update the parachain.

The current reliance on root track governance actions for managing parachains can be time-consuming and burdensome. This RFC aims to address this technical difficulty by allowing parachain managers to take self-service actions, rather than relying on general public voting.

The key scenarios this RFC seeks to improve are:

1\. Rescue a parachain with invalid wasm/genesis.

While we have various resources and templates to build a new parachain, it is still not a trivial task. It is very easy to make a mistake and resulting an invalid wasm/genesis. With lack of tools to help detect those issues1, it is very likely that the issues are only discovered after the parachain is onboarded on a slot. In this case, the parachain is locked and the parachain team has to go through a lengthy governance process to rescue the parachain.

2\. Perform lease renewal for an existing parachain.

One way to perform lease renewal for a parachain is by doing a least swap with another parachain with a longer lease. This requires the other parachain must be operational and able to perform XCM transact call into relaychain to dispatch the swap call. Combined with the overhead of setting up a new parachain, this is an time consuming and expensive process. Ideally, the parachain manager should be able to perform the lease swap call without having a running parachain2.

- The writer proposed a change to the parachain lock mechanism.
- The goal is to allow the manager of a parachain to make changes without needing approval from others.
- The proposed changes would only lock a parachain when the manager explicitly locks it or when a parachain block is produced successfully.
- The motivation for this change is to make it easier and faster for the manager to make changes to the parachain without needing public voting.
- The proposed changes would help in scenarios like rescuing a parachain with invalid wasm/genesis and performing lease renewal for an existing parachain.

#408 Create & implement RFC14 - Improve locking mechanism for parachains