WETH does not show up for all wallets types after trading ETH to WETH

[tshifty]

Brief Description: Weth no longer shows up with a balance for all wallet types after trading ETH to WETH. Doing a trade from ERC-20 to WETH fixes the issue. I believe this is caused because the "trade" from ETH to WETH is a contract deposit and not a trade. https://etherscan.io/tx/0x947a29772a9c7f123fffb650bede6dcc07a1af716de221c93b8a18d93564346f for example

Recreation Steps:

1. Trade into WETH with ETH on app.shapeshift.com
2. Once the trade completes notice how the weth doesn't show up with a balance

Acceptance Criteria:

• Find the reporting issue for KK, MM and native
• Fix the issue and have ops test the environment

[0xean]

Can you please add some more details to this ticket, or a screenshot? I am paired with metamask and see my dust balance of wETH on the dashboard.

[tshifty]

Native wallet

[tshifty]

Native balance

[tshifty]

KeepKey Screenshots

[0xean]

thanks @tshifty - super helpful, can you shoot me the address of one of these wallets? curious if its the same "WETH" since there are multiple versions of WETH

[tshifty]

Keepkey: https://etherscan.io/address/0xf6Fb864F185f14E8d7da00c0E4a55a09E4152Ff6 Native wallet: https://etherscan.io/address/0xE7F92E3d5FDe63C90A917e25854826873497ef3D Metamask: https://etherscan.io/address/0x71d20703f2a66522f3d9d18673693a968277aeee

[0xean]

Okay, thanks! It's all the same WETH, that rules that out

On Fri, Jan 7, 2022 at 10:25 AM tshifty @.***> wrote:

Keepkey: https://etherscan.io/address/0xf6Fb864F185f14E8d7da00c0E4a55a09E4152Ff6 Native wallet: https://etherscan.io/address/0xE7F92E3d5FDe63C90A917e25854826873497ef3D Metamask: https://etherscan.io/address/0x71d20703f2a66522f3d9d18673693a968277aeee

— Reply to this email directly, view it on GitHub https://github.com/shapeshift/web/issues/650#issuecomment-1007590944, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADTFXIK36TGNDQGCIA7H5QDUU4O2JANCNFSM5LNJ2LSA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[tshifty]

Did you trade into Weth using that account? or did you send weth to it from another address?

[tshifty]

Can this be moved over to the bug board?

[0xdef1cafe]

@tshifty did this happen immediately after trading, before refreshing the page? does it show up correctly after refreshing the page?

if it does work after a refresh, https://github.com/shapeshift/web/issues/706#issuecomment-1010314312 is related and will address it. we're not refetching the account with the new asset in it once a new tx comes in, if you previously didn't have the asset in your portfolio

[tshifty]

Refresh doesn't fix the issue. the only work around I have found is to trade an ERC-20 to WETH.

[0xean]

To add a summary of what we know for the next person who looks at this:

We aren't handling wrapping of ETH into WETH as a transaction that is understood by the system.

[helr441]

I saw what @tshifty saw, which was after the ETH->WETH trade, the asset list remained unchanged. Refreshing the page also did not make the asset list update. Looking at the network calls, it seems dev-api.ethereum.shapeshift.com/api/v1/account/<addr> is not returning WETH in the list of tokens after the ETH->WETH transaction.

So, that's one problem (A).

Thereafter, I did an ERC-20->WETH trade, specifically, DAI->WETH. After the trade txn confirmed, it showed up in Recent transactions. I didn't see a fresh API call dev-api.ethereum.shapeshift.com/api/v1/account/<addr>. Based on what @0xdef1cafe mentioned this is probably because Recent transactions gets updated by websockets, while asset list / Your assets gets updated by a REST API call. So, that's another problem (B).

If I manually invoke the dev-api.ethereum.shapeshift.com/api/v1/account/<addr> call, I do see WETH now show up.

Should we rope in the shapeshift/unchained folks to have an idea how to go about problem (A)?

[0xean]

@helr441 plans to take a look at this further over the coming 4-5 days.

[helr441]

Hi, an update - I haven't been able to spend much time on this so far. It is on my list of to-dos, nevertheless.

[0xdef1cafe]

closing as root cause is captured in https://github.com/shapeshift/web/issues/706 and this is not actually specific to WETH

[kaladinlight]

The case for missing WETH balance is as follows:

• If a user has had no previous WETH transfers on their account and makes a trade from ETH -> WETH, this calls the deposit() function which does not result in any form of transfer event. Blockbook tracks token balances by listening for transfer events associated with an address, so in this case, Blockbook does not think the user has interacted with and therefore has any balance to fetch for WETH.
• When a user creates a trade from ERC20 -> WETH, or simply sends or receives WETH from another address, these cases result in a transfer event and the balance will be tracked and provided accurately thereafter which is why balances were seen populating correctly after these actions.

The ideal fix would be adding detection for this event in blockbook or potentially just more generic contract interaction tracking which would allow us to catch this scenario and ensure balances are fetched accordingly. We would need to do a full resync to build out the correct token maps for addresses or we could continue syncing and it would just catch and update correctly thereafter.

An alternative fix would just be a client side patch that detects if there is WETH transaction history, but no balance entry and we could manually fetch the balance from the WETH contract to fill in the missing information as a stop gap.

[0xdef1cafe]

@kaladinlight @tshifty is this fixed/can be closed?

[kaladinlight]

@kaladinlight @tshifty is this fixed/can be closed?

Not fixed, though still low priority edge case imo. I will take a look at blockbook in more detail surrounding contract events and see if this will be fixed in blockbook v4 upgrade (I would think it should be), and we can go from there

[0xdef1cafe]

closing as stale and users aren't reporting