# xcm v3 <-> v2: new situations ? As xcmv3 is now merged and would be soon running in production it would be nice to have in mind the possible situations that we can encounter as a result of the migration. Mostly these would be in the space of version negotation. Let's start with a mention to how the relay will choose which version to use to compose a message for its destination. For each parachain (multilocation) the relay maintains its supported version, the version it should compose the message with so destinatary can understand it. We can retreive this value by querying `xcmPallet.supportedVersion`. And in case this entry is not populated, then it defaults to `xcmPallet.safeXcmVersion`. But when is this value set ? In general terms its set after the first exchanged messages, at this point in time subscription to version upgrades is made as well. The storage entry for subscriptions is `xcmPallet.versionNotifiers` and the one for locations that are subscribed to our(point of view of the relay in this text) version changes `xcmPallet.versionNotifyTargets`. So, after introducing v3, some locations in the network will upgrade and then support it as well, but not necessarily all of them, at least at the very moment the runtime with this change is enacted. For locations that are properly subscribed between them we can be sure that they will choose the correct version when creating messages. In case we are interested we can force this subscription with the extrinsic `xcmPallet.forceSubscribeVersionNotify`, in a similar fashion we can set the supported xcm version for a concrete location with `xcmPallet.forceXcmVersion` and even the default xcm version with `xcmPallet.forceDefaultXcmVersion`. As a chain compatible with xcm v3 can decode messages crafted following xcm v2 format(I'm not confident on writing backwards compatibility here, but would be worth checking), then the last possibility is that one v3 message is sent to a only v2 compatible chain, this can happen for instance with freshly onboarded chain that unfortunately doesn't have the relevant storage entries populated in the relay, default version for the relay can happen to be v3, and so these messages will be one version above of the supported by the parachain. In this case what one would observe is that upon reception the v2 chain complains about having receipt a xcm messaage with an invalid format and it cannot be decoded. Something like the following ![dmpQueue.InvalidFormat](https://i.imgur.com/gUvLYHE.png) To solve this situation we can set the correct version for this location with the above mentioned calls. > Something to dig in: Why, at this point version negotation doesn't happen and this is solved automatically ? > Hypothesis: Version negotiation happens exchanging xcm messages, so in this case there cannot be a conversation as the messages are not being decoded in one side. XCM v3 not only is a newer version, but it also includes new xcm instructions, can we send new instructions to an xcm executor that only supports v2(and we are aware that the destination only supports v2) ? The answer is no, the message will not even go out of the source location, and not only that but an error will be returned, `SendFailure` which is avoiding the previous situation. I expect the presence of this two to be minimal in Kusama or Polkadot in the future, but I am afraid this is something Rococo might face more often as this new version is rolled out. Hopefully this can help us understand what the different chains out there are facing.