User Transfer's Failing on Beamer dApp

[0xidkcrypto]

Description

A user KINDMIND#6463 faced issues when bridging USDC from Optimism to Arbitrum. (seen below)

Discord message link: https://discord.com/channels/958324380226695188/1077479897372557352/1077480370557173800

---

The user later opened a ticket and shared their screenshots and explained what had happened:

1. User bridged USDC from Optimism to Arbitrum
2. Transaction showed that it failed but,
3. Later became successful after 1 minute.
4. User used Bitkeep Wallet
5. User not sure what version of Optimism RPC was used
6. Wallet connected automatically
7. Error messages popped up (seen below).

---

System information

OS & Version: Windows/Linux/OSX
Browser & Version: Chrome/Firefox
Commit hash: when using checkout

Expected behavior

Actual behavior

Steps to reproduce the behavior

[manuelwedler]

Findings so far (all on goerli):

• when I'm first connected to optimism, then switch to arbitrum by using the source selector, I get the following error when trying to make a transfer:
  underlying network changed (event="changed", network={"name":"arbitrum-goerli","chainId":421613,"ensAddress":null,"_defaultProvider":null}, detectedNetwork={"name":"optimism-goerli","chainId":420,"ensAddress":null,"_defaultProvider":null}, code=NETWORK_ERROR, version=providers/5.7.2)
  It seems like they do the network change but don't emit the chainChanged event, because the page is not reloaded.
• when connecting to optimism and reloading, trying to make a transfer leads to the following error text for the ensure token allowance step: [object Object]
  It's really hard to debug without access to the console.
• when the above [object Object] error text is shown for the ensure token allowance step, trying to make the same transfer again leads to an error in the request transaction step (again [object Object]). This means the first transaction actually goes through. After checking the other rollup, I realized the transfer actually went through.
• I found a way to debug the integrated Bitkeep browser by connecting my phone to my laptop via USB and using the desktop chrome. Allows seeing errors in the console. See https://developer.chrome.com/docs/devtools/remote-debugging/#discover
• Using the debugging method, I could find more information. The goerli.optimism.io RPC throws the following error when requested to do a transaction:
  {"jsonrpc":"2.0","error":{"code":-32601,"message":"invalid JSON-RPC version"},"id":null}
  So it's the same as the user from Discord experienced. So something in the decoding of the JSON error is also wrong in our app. Not sure at the moment if the mainnet and testnet deployments diverged in that regard.
  The corresponding request to the error is:
  {"method":"eth_getTransactionByHash","params":["0xddedde0179b8a6a8dfc965bd50c2b86c2aee76abdea053b575973ea5017e986c"],"id":1677003171008}
  It's always this RPC method that leads to the error.

So overall it seems like there is more than one problem to solve.

[manuelwedler]

Further investigations:

• I tried to query the rpc manually. The issue about the request is that the payload is missing the "jsonrpc":"2.0" field. ethers.js seems to not add it in this method call. All other calls are fine.
• Interestingly, ethers.js does not generate this method call in a desktop browser environment, only in Bitconnect.
• When doing a transfer the other way round (arbitrum -> optimism), this method's payload is also missing the jsonrpc version field, but the arbitrum rpc does not respond with an error in that case.

We found that the issue comes from the window.ethereum object injected by Bitkeep. I could fix it by monkeypatching it. Will open a PR next week.

[andfletcher]

Done

[andfletcher]

Check if we contacted bitkeep @manuelwedler did you?

[manuelwedler]

Yes, I wrote an email about the bug, but didn't get a response yet.