Auction #64 fix winner's para ID

Background

On the Kusama Relay Chain, teams need to compete for a slot on an Auction to be able to become a parachain and start producing blocks. This competition can host 1 or multiple registered parathreads.

However, any competing parachain can deregister at anytime, even if competing for an ongoing auction. If that’s the case, it can happen that when the auction ends the selected winning block was one that the deregistered parachain won, and hence nobody wins the auction.

The Bittensor case

The Bittensor team registered paraID 2242 on Kusama with the intent on becoming a parachain. They added their WASM and Genesis to this parathread, and waited for the next auction to start.

When Auction #64 started on Kusama, the Bittensor team decided to place a direct bid on on paraID 2242 to win that slot over.

However, whilst the auction was running, they realized that the WASM and Genesis registered for paraID 2242 where the wrong ones. They decided therefore to deregister paraID 2242 and register paraID 2244 to compete on the same auction. After doing that, they placed a direct bid on paraID 2244.
From the Kusama Relay Chain perspective, paraID 2242 and paraID 2244 are two different things, whereas from the perspective of the Bittensor team they are the same.

What ended up happening is that, in the end, paraID 2242 won Auction #64 on Kusama, but at that point was alredy deregistered, therefore the slot was given to no parachain.

For reference, all interactions of the account can be found here.

Recommendation

Given that it can be proven on chain that the Bittsensor team is owner of paraID 2242 and paraID 2244, and the fact that they did a direct bid (i.e. not involving individual contributors), what can be done is to give the slot that paraID 2242 won to paraID 2244.

Encoded Call Hash:0xdd09c9c15bd8cc8cc8b973f7710b1b907a44431a08bd864ae86f78bc91b62785
Encoded Call Data: 0x4700c4080000387f657be6913b17c0d5ad2eb24d10cbbd319e142f39c60a000b175744aaad42000000000000000000000000000000001a00000021000000

Opengov on Kusama

In order to execute this proposal, the team needs to provide the call details and a member of the Fellowship needs to whitelist the hash of the call. However, given that this needs to go through OpenGov, it needs to be wrapped in the right origin.

Leveraging the OpenGov Submit tool, the hash of the call with the WhitelistedCaller track.

The result is then:

Submit the preimage for the Fellowship referendum:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x2000882c00dd09c9c15bd8cc8cc8b973f7710b1b907a44431a08bd864ae86f78bc91b62785

Open a Fellowship referendum to whitelist the call:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x17002b0f021da6c9df28af6dca02fba8f9f421917b4a1a19c6da58f42dcb3f1bd3117dc2ee22000000010a000000

Submit the preimage for the public referendum:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x200001012c034700c4080000387f657be6913b17c0d5ad2eb24d10cbbd319e142f39c60a000b175744aaad42000000000000000000000000000000001a00000021000000

Open a public referendum to dispatch the call:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x15002b0d0252096a4be42f75e4db75e470c3ec9059e0b4326b7c236aaf2265e8d0e28a90dd40000000010a000000