WETH contract (0x42...) not responding to ETH deposit for larger deposits, but responding for smaller ones

[newcodave]

Bug Description
Juniper (https://app.juniperfi.com/) is a ERC-4337 smart wallet built on OP using ZeroDev's Kernel smart wallet SDK. Its ETH deposit flow is:

1. Send ETH to the smart contract wallet address (e.g. https://optimistic.etherscan.io/address/0x3048FC9d14188a3B7d7f720252f46008b0BbA3a8#internaltx)
2. Juniper sees the deposit and uses a ZeroDev session key to send ETH to 0x42... to get WETH
3. WETH is swapped to wstETH and collateralized at Aave
4. User can then send stables to wherever

Lately (earliest user report 22 May 2024), the WETH contract at 0x42... will sometimes not send back any WETH in response, and this correlates with larger deposits as seen in this smart wallet where a E0.003 send to 0x42... receives WETH, whereas a E0.34 wrap operation never receives WETH:

https://optimistic.etherscan.io/address/0x3048FC9d14188a3B7d7f720252f46008b0BbA3a8#internaltx

The earliest example of the behavior/eventually/ responded with WETH, but only after 14 hours:

https://optimistic.etherscan.io/address/0x4cdce7541b42dc1537b75114a9160aa5e0b9f445#internaltx

Steps to Reproduce

1. Create a Juniper smart contract wallet on the site
2. Send E0.003 and watch the wrap, swap, stake & collateralize flow work correctly
3. Send E0.3 and watch 0x42... never respond with WETH

Expected behavior
An equal amount of WETH for ETH after a send to 0x42...

Note that we haven't reduced the case yet via EOA usage of 0x42..., these are customer cases.

Environment Information:

• OP mainnet
• ZeroDev Kernel, EntryPoint 0.6

Configurations:

• N/A

Logs:

Smart contract wallets exhibiting the WETH behavior follow.

https://optimistic.etherscan.io/address/0x3048FC9d14188a3B7d7f720252f46008b0BbA3a8#internaltx

https://optimistic.etherscan.io/address/0x65aa028301f9F9eD96e56971F0452aef108D8866#internaltx

The first wallet exhibits the small amount vs larger amount behavior

Additional context
Also discussed in #devsupport on Discord

---

⚠️ Notice: Issues that do not include the following sections will be subject to closure:

• Bug Description
• Steps to Reproduce
• Environment Information

Please ensure all required sections are filled out accurately to expedite the debugging process and improve issue resolution efficiency.

[newcodave]

This deposit as of this morning processed correctly, other ones in the ticket are still stuck / need remediation

https://optimistic.etherscan.io/tx/0x90670b4c3af320138af59eddcc56ac2554edf21b3b504a50bd0745c0942994a5

[jbarry786]

I am a user directly impacted by this.

It's now been 5 days since I merely made an ETH deposit (txid-here).

After which I see ETH was deposited to wETH contract... but strangely no wETH appears to have been transferred back from the contract. Op-Etherscan displays no balance on the address.

@sbvegan are you not able to have a look at this or engage some OP team member who perhaps can figure out what happened here and how to retrieve the coins/fix it?

It has been very difficult do grasp what happened here and the lack of feedback is just making it harder to cope with the situation.

[sbvegan]

Let me flag this internally

[sbvegan]

Hey @jbarry786, it looks like it worked successfully, but the etherscan indexer might not be working as expected. You can see this blockscout transaction showing the weth being distributed. If you use the following foundry query, you see the expected result:

cast call 0x4200000000000000000000000000000000000006 "balanceOf(address)(uint256)" 0x65aa028301f9F9eD96e56971F0452aef108D8866 -r $OP_MAINNET_RPC_URL

# returning the expected value:
310000000000000000 [3.1e17]

I can flag this to etherscan to investigate. cc @newcodave

[sbvegan]

Etherscan is investigating the indexing issue, they've reported that they're not properly picking up the Deposit event from WETH to reflect the balance under the EOA. They're working on a fix.

[newcodave]

our software using Infura doesn't see it either

[tynes]

It's now been 5 days since I merely made an ETH deposit (txid-here).

Looking into the tx hash, it looks like its a simple eth send from a binance controlled account to 0x65aa028301f9F9eD96e56971F0452aef108D8866?

Is the source code available for the code at the account? I am guessing that the source code attempts to wrap the ether on receive?

Nothing about the WETH predeploy has changed on OP Mainnet. Was this flow working previously? I see that you are saying it only works with small amounts.

[sbvegan]

iirc in the discord conversation with Juniperfi, this was a very recent change of behavior cc @newcodave

[jbarry786]

@tynes thank you for looking at this.

I understand this situation may be quite confusing to read, so just to try to clarify what I saw from a user perspective (so a user of Juniper, which uses Optimism).

1. I deposited ETH to smart wallet contract address. A normal ETH deposit initiated by me.
2. Under "internal transfers", we can see ETH being sent to wETH contract.
3. After that transaction, the optimistic.etherscan never displayed the tokens (wETH) under the balance. The "juniper" UI/contract also never processed anything.

What confused me was that the optimistic.etherscan never displayed the token balance. That balance not displaying has been fixed now, at least for my smart wallet contract address.

@sbvegan contacting etherscan appears to have fixed this for me, but there's a strange thing. If you check this other wallet (referenced in the first post here on this thread), this one doesn't display the balance of wETH.

It only shows the smaller amount, not the 0.34 weth (address)

Mine (address) now shows the token holdings now (previously was completely blank):

It's strange that they must have fixed an issue, but that fix doesn't appear to have fixed the other one.

Since I am just a Juniper user, I don't exactly know what the contract/code sets out to do exactly after it receives the wETH. However, it's fair to assume that this etherscan "display"/indexing issue may be correlated with the failure of Juniper code to process the wETH. @newcodave should be able to dig further into this, now that etherscan appears to be applying some fixes.

Apologies for the long message and in case I didn't use the best terms at times to describe the vents.

Thanks for your feedback, helps learning.

[newcodave]

@jbarry786 if you go hit the Deposit screen in Juniper again, does it now "see" the WETH and begin the collateralization process?

If so, it's likely that Etherscan didn't "fix" anything (as neither did we, we have deployed no new code since this issue was raised) and instead some underlying issue with 0x42/OP finally resolved

In other cases reported by users, we have seen (pun intended) that the issue "resolves itself" after some hours/days.

FYI @sbvegan @tynes the Juniper contract code is just a stock ZeroDev Kernel (https://github.com/zerodevapp/kernel) and it manipulates the SCW using session keys. But getBalance() of WETH does need to return that there is WETH after the send to 0x42... for the process to continue.

[newcodave]

@sbvegan @tynes surely Etherscan didn't only fix the issue for just one address? This wallet still displays less WETH than was sent to 0x42... via "internal txns"

https://optimistic.etherscan.io/address/0x3048FC9d14188a3B7d7f720252f46008b0BbA3a8#tokentxns

Additionally it exhibits the "smaller sends receiving WETH, larger ones not" issue

[sbvegan]

No they are rolling out the fix so its being reindexed and the rest will be updated soon. I spoke to the team and they mentioned they would hop in to provide context later, but its very early for them at the moment. One comment from them:

One quick workaround to get the WETH's figures updated on an address is to navigate to this page
https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006?a=0x3048FC9d14188a3B7d7f720252f46008b0BbA3a8
Which will refresh the cached amount and will also update the figures reflected on the dropdown.
Moving forward, WETH deposits and withdrawals done for smart contract wallets should reflect correctly, with past addresses refreshed shortly in a day or so.

[newcodave]

I'm still somewhat confused why our software that just does

const erc20Contract = new ethers.Contract(contractAddress, ERC20_ABI, provider)
const balanceTokenDecimals = await erc20Contract.balanceOf(address)

... also doesn't/didn't/sometimes see(s) the swapped WETH, independent of Etherscan. The only reason our users are looking at Etherscan is because we/they didn't see it either. We do use Etherscan's API in some places, though I don't think it's a dependency of this code path

provider is just

        case Network.optimism:
            return new ethers.providers.JsonRpcProvider('https://optimism-mainnet.infura.io/v3/' + process.env.NEXT_PUBLIC_INFURA_API_KEY)

[Enigmatic331]

So yea if it appears "fixed" for some addresses and not others it's likely because there are subsequent transfers which triggers a balance refresh on the address. :) The recalculate we are running site wide (halfway through) + an update to our indexer should fix this permanently whenever a Deposit()/Withdraw() is triggered on the WETH contract.

Perhaps one thing you can try @newcodave - If it doesn't show up when you do an erc20Contract.balanceOf(address) could you also cross reference on https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006?a=0x3048FC9d14188a3B7d7f720252f46008b0BbA3a8 (with the address parameter changed)?

[newcodave]

Hmm, we've had at least one successful wrap/stake/collateralize flow of >=E0.3 in the last 24 hours, monitoring...

https://optimistic.etherscan.io/address/0x29ADcEe18b0F39c404934c8B3526A317CD07B716