cannot use AA ac in normal dapp like Uniswap

[cwhcheng]

I create an AA account in snap and I can connect the AA ac to Uniswap. But when i try to perform a token swap, it throws me an error Invalid options to add user operation smartContractAccount - Expected an object, but received: undefined { "originalError": {} }. Then I try to add some debug log msg in packages/snap/src/index.ts of onRpcRequest and onKeyringRequest, but i cannot get any log msg, so i suspect it never go into the snap when i try to do a swap. Do you know how to deal with this issue? Appreciate any help!

[meanMonk]

Hello @cwhcheng Looks like we are on same boat ⛵

I was also debugging the same but it goes through the onRpcRequest if you invoke snap with below way.

await window.ethereum.request({
      method: 'wallet_invokeSnap',
      params: {
        snapId: snapId// local:http://localhost:8080,
        request: { 
          method: 'customMethod, 
          params: [ParamsIfAny] 
        },
      },
    });
      

KeyRingClient submitRequest can only be send through MM as per the keyring api docs so I am stuck at invoking the prepareUserOps or other.

Hope to get the some insights or working example to understand how does the flow work.

Thank you!

[cwhcheng]

@meanMonk thanks for your info! I guess your solution requires the change in all existing web3 frontend website? But what I am thinking is a good AA snap should transform an existing transaction request into a userOp so u can use the AA snap in all existing web3 dapp without any change.

I found an example that is close to what i want to do. Maybe u can have a look as well! https://ethglobal.com/showcase/snaaps-aa-on-0wx76

[souradeep-das]

Then I try to add some debug log msg in packages/snap/src/index.ts of onRpcRequest and onKeyringRequest, but i cannot get any log msg

The log msgs on snap can be found through - manage extensions -> enable dev mode -> Inspect views"background.html"

The example snaaps-aa-on-0wx76 above seems to intercept eth_signTransaction in order to create and send the userOp. Since potentially the subsequent eth_sendTransaction cannot be intercepted but will be attempted, this would make the tx show up as a failed tx on metamask.