I agree that whatever the solution is, that it needs to be programmable. Personally, I’d much prefer a pallet over a smart contract since we could add this e.g., to frame or orml and many parachains, not just the ones with smart contracts, can then support the recovery mechanism.
The pallet (or whatever implements the code) should be the acting parachain manager. The fallback mechanism should not rely on relay chain governance as is.
My proposal for how this could work:
- Parachains can add a pallet to their runtime (if they opt-in) that allows other parachains to delegate emergency rights to them. Implementation can be based on parachain requirements. Some parachains might just want to have privileged accounts like a TC that can invoke emergency procedures. Some might want to mirror their governance and be able to vote on the measures.
- In case of an emergency, the pallet on the recovery parachain is able to
paras.forceSetCurrentCodeon the relay chain (decided by whatever emergency procedure a particular parachain has configured).
One way around sending the blob over XCM would be if there was a “parachain” governance track:
- The parachain team could note a preimage with
paras.forceSetCurrentCodeand open a “parachain” track proposal - From a recovery parachain, the parachain that wants to recover sends an XCM message that approves the upgrade. For this, the relay-chain would have to track which parachain(s) and which origins from that chain are allowed to approve.
Instead of using each others parachains for recovery, this could also be placed on an existing common good chain. To be very resilient, a parachain could also have a recovery option from two or more parachains.