HydraDX <> Moonbeam XCM Issues 2024-03-15

1

Hey community,

HydraDX applied a runtime upgrade (see this block) in which they changed some functions that affected how the Moonbeam dApp fetched token decimals for XCM transfers from HydraDX to Moonbeam.

Consequently, there were some XCM transfers that suffered from being executed correctly in HydraDX, but failed to execute on Moonbeam (see the transfers that failed starting on 2024-03-15 here).

I’ve compiled a list of the affected users with the assets they’ve now locked in HydraDX Sovereign account on Moonbeam:

Origin Destination Token Amount GLMR Amount Explorer
7NSzbPmboW99jDFj9MoHDU8R1oNxs4pVDnNzWogcoyE2DhVZ 0xb32b41625e14e55757a5d0cfcdd9768a1695c5f3 20 (Eth) 0.6738235523 0.00000004 Subscan | Aggregate Substrate ecological network high-precision Web3 explorer
7NSzbPmboW99jDFj9MoHDU8R1oNxs4pVDnNzWogcoyE2DhVZ 0xb32b41625e14e55757a5d0cfcdd9768a1695c5f3 21 (USDC) 1 0.000000045 Subscan | Aggregate Substrate ecological network high-precision Web3 explorer
7NTPhcyNuy1JfW6tvZoeoGMyM6D2VsCcnMEjo2jA26K8d1Gx 0xd90dDeeaCb4f9DF83c74733899fA9Bf2c2CFba99 - - 0.003 Subscan | Aggregate Substrate ecological network high-precision Web3 explorer
7LYNw7aNBTJRLUXMMKeaMKxcP8v2irsQXfNepD7JkcoRz5fY 0x5C4a7eD0908eF825B4Cb8e4A7206e47312f505b9 - - 0.00108 Subscan | Aggregate Substrate ecological network high-precision Web3 explorer
7NwzAHckkFHW81cUYSZm98wMCpc4byVHVTQsgmwhVtGPztKm 0xbcBbe0af190fB5610dDb7f3Bb04B35c3549cD452 21 (USDC) 51.02 0.00000004 Subscan | Aggregate Substrate ecological network high-precision Web3 explorer
7NBDd9FFnUC4GZVyAZAcUF6TjFWjqib7Y1nAWJNBhLd9qCkq 0xccb3d79521602342ce2F03F523F9d1A645523cD6 18 (BTC) 0.00998133 0.00000004500000001 Subscan | Aggregate Substrate ecological network high-precision Web3 explorer
7MNBdz5RAMGq88AjLSB9hmtuYLeQxBxaLSm5QCcbnimaYBnc 0x6CED59A8D2dA7bdf3E6c2920F632421A8f3c34D1 21 (USDC) 2 0.00000004500000001 Subscan | Aggregate Substrate ecological network high-precision Web3 explorer
7MNBdz5RAMGq88AjLSB9hmtuYLeQxBxaLSm5QCcbnimaYBnc 0x6CED59A8D2dA7bdf3E6c2920F632421A8f3c34D1 21 (USDC) 2 0.00000004 Subscan | Aggregate Substrate ecological network high-precision Web3 explorer

I propose that the OpenGov Tech Committee should whitelist a proposal to unlock funds for the users and transfer them to the destination account in Moonbeam.

I’ll be posting an update in the coming days.

10 Likes
2

Hi @AlbertoV19 Thanks for bringing this up, I support fixing this asap

5 Likes
3

Further updates.

I’ve checked the balance that HydraDX’s Sovereign account holds in Moonbeam, and once we return user funds, the balance still corresponds to the number of assets that exist in HydraDX (which is good!).

Working on creating a proposal for the OpenGov Tech Committee

image
image1462×143 14.1 KB

6 Likes
4

Awesome, thanks. Once the proposal is ready, I can bring this to the committee.

4 Likes
5

So, after thinking of strategies to execute this call in the “most correct way,” I concluded that the best way is to ask HydraDX to submit a proposal on their end to send an XCM message so that their Sovereign Account transfers the token.

This is also the most “politically correct” path, as we will not enforce anything on Moonbeam’s HydraDX Sovereign Account.

I’m discussing the next steps with the HydraDX team and will keep everyone posted.

5 Likes
6

How soon will this be resolved?

7

hey, please check out Alberto’s response above, he will update us ASAP: HydraDX <> Moonbeam XCM Issues 2024-03-15 - #5 by AlbertoV19

1 Like
8

Hey,

So after a lot of thought and testing, I’ve proposed HydraDX to do a governance proposal to refund the following users:

[
  {
    "amount": "673823552287033000",
    "from": "7NSzbPmboW99jDFj9MoHDU8R1oNxs4pVDnNzWogcoyE2DhVZ",
    "decoded": "0xd6a5278d06644f0ca64831082203b30484d98d5a34af53f05e41ba6f6a7a8356",
    "url": "https://hydradx.subscan.io/xcm_message/polkadot-0da690ac512a6a2b3c0a2fb709ca4a3a8ecb94c9",
    "to": "0xb32b41625e14e55757a5d0cfcdd9768a1695c5f3",
    "assetID": "20 - ETH"
    "assetAddress": "0xab3f0245b83feb11d15aaffefd7ad465a59817ed"
  },
  {
    "amount": "51020000",
    "from": "7NwzAHckkFHW81cUYSZm98wMCpc4byVHVTQsgmwhVtGPztKm",
    "decoded": "0xecc1d06726f784c0c559779d4c088b5cc276ad31a8ca3d2380532a6c348db144",
    "url": "https://hydradx.subscan.io/xcm_message/polkadot-b86e2955f5a3ebe9b086e94aadb4f83c20100c31",
    "to": "0xbcBbe0af190fB5610dDb7f3Bb04B35c3549cD452",
    "assetID":  "21 - USDC" ,
    "assetAddress": "0x931715fee2d06333043d11f658c8ce934ac61d0c"
  },
  {
    "amount": "998133",
    "from": "7NBDd9FFnUC4GZVyAZAcUF6TjFWjqib7Y1nAWJNBhLd9qCkq",
    "decoded": "0xca9d176ac64d7babb52d656158082ad3c160501eceeb2901bad47d30e903194d",
    "url": "https://hydradx.subscan.io/xcm_message/polkadot-c13cab00ed52b5f7b9d7dd66766aef7e3910313d",
    "to": "0xccb3d79521602342ce2F03F523F9d1A645523cD6",
    "assetID": "19 - BTC" ,
    "assetAddress": "0xe57ebd2d67b462e9926e04a8e33f01cd0d64346d"
  }
]

The main reason is that the solution entails sending separate XCM messages. If we send more, it will run into an Overweight problem in which we just consume all resources destined for XCM in a specific block. Another solution would require two separate proposals. The 3 transfers left out are for 1 USDC , 2 USDC and 2 USDC that could be manually funded in Moonbeam if needed.

If you are curious, I created this script to calculate the call data for the proposal in HydraDX. I tested it out via Chopsticks and I get the following ERC-20 tokens logs:

Address: 0xab3f0245b83feb11d15aaffefd7ad465a59817ed
Event Name: 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
Topics:
1. 0x0000000000000000000000007369626cf2070000000000000000000000000000
2. 0x000000000000000000000000b32b41625e14e55757a5d0cfcdd9768a1695c5f3
Data: 0x0000000000000000000000000000000000000000000000000959e6f3635c46a8

Address: 0x931715fee2d06333043d11f658c8ce934ac61d0c
Event Name: 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
Topics:
1. 0x0000000000000000000000007369626cf2070000000000000000000000000000
2. 0x000000000000000000000000bcbbe0af190fb5610ddb7f3bb04b35c3549cd452
Data: 0x00000000000000000000000000000000000000000000000000000000030a80e0

Address: 0xe57ebd2d67b462e9926e04a8e33f01cd0d64346d
Event Name: 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
Topics:
1. 0x0000000000000000000000007369626cf2070000000000000000000000000000
2. 0x000000000000000000000000ccb3d79521602342ce2f03f523f9d1a645523cd6
Data: 0x00000000000000000000000000000000000000000000000000000000000f3af5

According to the ERC-20 spec, the event corresponds to Transfer (index_topic_1 address from, index_topic_2 address to, uint256 value), which means that Topic 1 is the address from, Topic 2 is the address to. The value in Data is the hex representation of the amount being transferred.

This means that the call data successfully transferred these tokens as described in the previous post.

3 Likes
9

Hey all,

A motion is currently being voted on by the HydraDX council → Refund MRL trapped assets

6 Likes
10

This is now live for referendum for HDX holders - this will take 3 days and should enact immediately:

7 Likes
11

This is now executed on HydraDX governance

4 Likes