Kusama’s runtime has been recently upgraded, and with such the setTopic
instruction was added to XCM. This instruction is compatible only with XCM v3, which raised some issues in the ecosystem.
Teams are encouraged to do the following, both for Polkadot and Kusama, in order to use XCM without any issues:
-
If the parachain runtime is already using XCM v3, check that the Relay Chain is aware of that being the version that the parachain is running.
-
If the parachain runtime is not using XCM v3, upgrade ASAP to it.
-
Update the
xcmSafeVersion
from 2 to 3 on the XCM configuration.
The Parity Data Team has been deeply investigating this issue to be able to understand what action needs to be taken for each team, which has been extremely helpful in already having XCM working in most cases. A summary of this information is shown below, however, please note that all the is at a specific time of querying, therefore it might get outdated. Every parachain team is highly encouraged to double check the information by themselves, or engage on this post for further clarifications and discussions.
1. Check the Relay Chain storage for the XCM Supported Version
Query XCMPallet.supportedVersion
, and look for your parachain on the response.
Response will look something like this
Compare the version the relay chain has in storage versus the version the Parachain is on.
What to do if the Stored Version is outdated
If this is the case, there is no major issue. The best way to deal with the situation is to send an XCM message from the Parachain to the Relay Chain notifying the XCM change. The Moonriver team has discussed this on their forum, and Bryan Chen from Karura issued this very good twitter thread about it.
let response = Response::Version(xcm_version);
let message = Xcm(vec![QueryResponse { query_id,
querier: None,
}]);
Here’s Moonriver’s XCM example message which serves as a guide (beware of inputting the right information) on how to craft this message.
Current Status
It is highly recommended for teams to check this by themselves to be absolutely sure on how to proceed. However a first analysis of the current status of parachains that are currently on XCM v3 but the Relay Chain map has them as on XCM v2, can be found below.
Kusama
- Quartz (paraID 2,095)
- Examples of execution
- Karura: UMP update version message
- Kintsugi: UMP update version message
- Moonriver: UMP update version message
- Turing: UMP update version message
- Imbue: Message Event
- Picasso: UMP update version message
Polkadot
- Unique Network (paraID 2,037)
- Darwinia (paraID 2,046)
- Examples of execution
- Composable Finance: UMP update version message
2. Upgrade to XCM v3
There are still several teams that are running with XCM v2. It is highly encouraged for teams to upgrade to XCM v3, otherwise utilising XCM can be severely compromised.
A first analysis of the current status of parachains that are currently on XCM v2, can be found below, however is highly recommended for parachains to double check this information.
Kusama
- Robonomics (paraID 2,048)
- Calamari (paraID 2,084)
- Litmus (paraID 2,106)
- Crust Shadow (paraID 2,012)
- DAO IPCI (paraID 2,222)
Polkadot
- Manta Network (paraID 2,104)
- Clover (paraID 2,002)
- Crust Network (paraID 2,008)
3. Update the xcmSafeVersion from 2 to 3 on the XCM configuration
Referendum #305 has been proposed on Kusama to make the xcmSafeVersion of the Relay Chain be 3. This implies that the default XCM version for messages from the Relay Chain will be 3 if the version of the destination chain is unknown. Hence the strong recommendation to upgrade to XCM v3.
With this in mind, it is also encouraged for all parachains to change their XCM configuration to make xcmSafeVersion be 3. This would enable the system to be more resilient, as XCM v3 is compatible with 2D Weights.
In order to upgrade the xcmSafeVersion from 2 to 3 on the XCM configuration, please call force_default_xcm_version with the argument 3. This needs to be executed from Root.
Recomposing balances - all funds are SAFU
No funds have been lost with this issue. However, what needs to be reconstructed is the mapped assets within the parachain. Parachains need to use root to mint the lost mapped KSM on their parachains and allocate them to the users with the trapped assets. A more detailed answer on this can be found on Substrate StackExchange.
Big thanks again to the Parity Data Team for collecting all the needed information to present this to the community.