HydraDX <> Moonbeam XCM Issues 2024-03-15

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