Abstract
When RT3100 was enacted, it affected XCM token transfers of MRL assets. Consequently, some Hydration users were affected, as their XCM message was correctly executed in Hydration but failed to execute in Moonbeam properly.
What this means is that the assets were burned on the Hydration side but were never unlocked on the Moonbeam side to the user’s Remote Origin account. All these transactions can be found here (the ones from 2024-09-03 13:06:54 (+UTC) to 2024-09-03 18:21:24 (+UTC)):
This proposal executes an XCM transfer from Hydration Sovereign account to send the funds back to the users.
Details
To fix the problem, we first created an indexer that would provide the XCM message hash of the messages that failed on execution from Hydration within the blocks were the issue was present: devrel-indexers/moonbeam/rt3100-failed-xcm-mrl at main · papermoonio/devrel-indexers · GitHub
This returned that at least 18 transactions resulted in XCM execution failures → devrel-indexers/moonbeam/rt3100-failed-xcm-mrl/output.json at main · papermoonio/devrel-indexers · GitHub
With this, we created another indexer that went through Hydration and matched the XCM message hash of the failed Moonbeam messages. Then we narrowed down which messages were related to a XCM token transfer, and retrieved the sender, amount, and asset being transferred → devrel-indexers/hydration/mb-rt31100-mrl-fails/output_asset_fail.json at main · papermoonio/devrel-indexers · GitHub
Then, a script was used to create the proposal to ensure it was filled properly → PolkaTools/calculateMBRT3100_MRLFix.ts at main · albertov19/PolkaTools · GitHub
The preimage 0x0a62f809e23bf7159249101c10f20e9f0457fa2de02c0da66e9809ecdcaa672b was tested in Chopsticks, and its execution resulted in the assets being properly transferred to Hydration users initially affected by the problem.
We also verified that this did not affect the balance of Hydration Sovereign Account, meaning that the account holds more assets than those issued in Hydration.
