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

[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.