XLabs / wormscan-ui

5 stars 3 forks source link

Implement "USDT Transfer" Display for USDT Transactions in AppID #661

Open SamantaCasal opened 2 months ago

SamantaCasal commented 2 months ago

Description:

As a user, I want the application to display "USDT Transfer" as the appID whenever I am sending USDT tokens so that I can easily identify and confirm the specific bridge being used for my transactions.

Acceptance Criteria:

  1. When a user initiates a transaction involving USDT, the appID should automatically display as "USDT Bridge."
  2. Add USDT Transfer in the Protocol filter
  3. Add functionality to the vaaa-payload-parser to identify USDT transactions and display them in the appID.

Resources

Contracts: https://docs.google.com/spreadsheets/d/1O6g_g8GQsgB_UJt06JxaX7dLozseHfct-CcxBe6YUkY/edit#gid=0

mliu-xlabs commented 1 month ago

There is a known issue that we may have with this because for OP, Polygon, and Avax - these are still using the original Eth transfer portico contracts. What this means is that for origins from OP, Polygon, or Avax, the App ID will show as Eth Transfer instead of USDT Transfer, since AppID is currently based off of the contract. we will need to find a method (Snale had idea to additionally parse the token bridge details to determine if the transfer is USDT or ETH. If USDT then USDT Transfer, if ETH then Eth Transfer)

valentinoConti commented 1 month ago

@mliu-xlabs I'm almost sure I can handle that in the vaa-payload-parser 👍🏼, good info

M-Picco commented 1 month ago

A small tidbit of info mentioned on a slack thread:

For the USDT Bridge, the new emitters will be:

  • ethereum: 0x4db1683d60e0a933A9A477a19FA32F472bB9d06e
  • bsc: 0xF352DC165783538A26e38A536e76DceF227d90F2
  • arbitrum: 0xE70946692E2e56ae47BfAe2d93d31bd60952B090
  • base: 0x4568aa1eA0ED54db666c58B4526B3FC9BD9be9bf

For the other chains (polygon, avalanche, and optimism), the emitter will be the same as it is for ETH Bridge transfers

Basically when transferring USDT, it calls the new contracts since those chains have a PancakeSwap pool. But if the chain doesn't have a PancakeSwap pool, the it calls the "old" contracts which swap via Uniswap pool

That's why there weren't new contracts deployed to all of the chains (because the new ones use PancakeSwap for USDT swaps)

I'd double check the emitters with the spreadsheet that Sami linked on the ticket

SamantaCasal commented 1 month ago

There are no transactions yet to test this implementation. We send the filter to Prod, when transactions appear, if we find any bugs we will report it in a separate issue. FYI: @M-Picco @mliu-xlabs @valentinoConti

Image