Due to a human error, integritee's sudo account has been reaped and the team can no longer operate its parachain nor migrate its solochain to the parachain. This proposal aims to restore the integritee parachain by setting a new genesis head.

what happened

Integritee launched its parachain with a shell runtime which features basic pallets like sudo, balances, vesting. This runtime has an extrinsic filter in place, so only sudo is allowed to send extrinsics

The sudo account initially was endowed with 10M TEER, the total supply planned. Because integritee launched its mainnet as a solochain before onboarding as a parachain, the team wanted to destroy the TEER tokens on its parachain before migrating its solochain state to the parachain. This should avoid confusion because we'd no longer have 10M TEER on solo plus 10M TEER on para.

It was planned to leave 10 TEER for sudo, to be able to pay fees.

Due to a human error, the sudo call balances.setBalance was called with the argument 10 instead of 10_000_000_000_000, so the account went below the existential deposit and was reaped.

Now, the integritee team can no longer operate its parachain because sudo can't pay fees

remedy

The integritee team suggests to set its state back to a new genesis using

paras.forceSetCurrentHead

See the tracking issue with test logs

preimage

The new genesis will be based on integritee's latest release 1.5.13 with --chain integritee-kusama

Hash of the state (sha256): 518a9815127523202516b7ddeb80410efc673492a316e73d52978a118036b87b

preimage hash:
0x83dd12cdda556c4e91e7a4c199c4589a81f8b4ecd3665dc036c0964cb8cd0eab

consequences

The shell parachain was still at genesis state, apart from trivial internal transfer tests.
Therefore, no one is affected by rolling the state back to genesis. No data nor funds are lost.

The positive consequence is that Integritee can continue on its path to decentralization and migrate it's solochain to the Kusama parachain following the hopefully successful referendum