Fix ChainBridge migration for ZLK (2nd try) - motion #190

This is a retry of the motion #188.

The original motion was not executed successfully because the permission was set incorrectly. It requires root permission to execute. So in this motion, we are going to execute the same steps but in a referenum.

Original proposal

This motion is a batch call to fix the ChainBridge migration issue on ZLK after we upgrade to XCM v3.
With the new XCM version, GeneralKey definition was changed, which influence our resource id
and reserve account calculation on ChainBridge. The batch contains 6 calls:

  1. Call-1 set ZLK to a temporary location (1, X2(Parachain(2001), GeneralIndex(0))
  2. Call-2 set ZLK back to its real location (1, X2(Parachain(2001), GeneralKey(2, 0x0207..00))
    The above two call will trigger ZLK resource id updated to proper value automatically
  3. Call-3 force burn 196247848001219224432700 units ZLK from old reserve account(pub key): 0xde50ca45c8f7323ea372fd5d7929b9f37946690b0b668985beebe60431badcea
  4. Call-4 force mint 196247848001219224432700 units ZLK to new reserve account(pub key): 0x95f793efdd6b1f7894f6c4d9bcb3de87d4e58385c56ebf1bfef91f9ab2144b91
  5. Call-5 force burn 2026420000000000000000 units ZLK from temporary account: 427Xv1Y1bNNQ5XU6pCCVGbqTgEe41t6s4GAYCCCDwASWsXpa
  6. Call-6 force mint 2026420000000000000000 units LK to external account: 43L9xU7zKU2ByNKvsgb4QLnhBU4pVvfbphh52TeH8byRtPuj

There are 5 transaction that have their ZLK locked in the temporary account:

And the external account will bridge ZLK to user account on Moonriver

  • Business
  • Call
  • Metadata
  • Timeline2
There are no comments here