# Metamask Snaps & 4337 Wallet This document highlights the current challenges and possible solutions if we use Metamask Snaps to develop a 4337 wallet version. ## Sending transaction Currently, there is no way to intercept `eth_sendTransaction`. So if a Dapp initiates the RPC call, by default the call will always go through the Metamask EOA. Metamask does allow us to show any insights on the transaction by exposing the function `onTransaction` but neither can we stop the EOA transaction nor can we redirect it through the SCW. We can define a custom RPC method, Starknet's wallet snap also created a new method [`starkNet_sendTransaction`](https://github.com/ConsenSys/starknet-snap/blob/3bb32634aa99c76610392f805a92b393ccec35b0/packages/starknet-snap/src/index.ts#L128). This means that Dapps will have to call this custom RPC method whenever they want to send transactions through the SCW implementation. This may not be ideal as this would restrict the usage of the SCW and require change on Dapp's end. Since Dapps will have to make changes in their codebase to batch transactions & use paymasters, it can be argued that we can expose a new RPC method using the Metamask snaps for sending transactions too. This though will decrease the usage of SCW for normal transactions but can increase its adoption slowly as Dapps start connecting paymasters or batching transactions like `approval` & `deposit`. ## Dapp specific paymasters Metamask doesn't allow snaps to interact with the javascript code of the website, so it will be difficult for Dapps to expose `PaymasterAPI`. **RPC solution** The workaround for this could be that we expose an RPC `eth_buildUserOp` which builds a partial userOp without the `signature`. Then Dapps can add `paymasterAndData` field to it and send the `userOp` via `eth_sendUserOp` RPC method. We will also need to figure out the best way to get `paymasterAndDataSize` while building the partial userOp though. We need it to be added to `preVerificationGas`, since we will not be able to change `preVerificationGas` once the partial userOp is created. To know about the issue you can read more [here](https://github.com/eth-infinitism/bundler/pull/7). **Snap solutions** Another solution could be that we ask the Dapps to release a 4337 Paymaster snap. The specific snap can expose an RPC method `eth_getPaymasterAndData`. Whenever the dapp wants to sponsor the gas they could configure the paymaster via an RPC method `eth_setPaymasterSnapId` exposed by the 4337 snap. This way we can solve the two-way communication between the paymaster & 4337 snap. I would like to know the recommended approach amongst the above-mentioned. Do suggest if there could be a better approach. ## User specified paymasters What will be the best way to add user-specified paymasters to a 4337 snap? Like above can we ask paymaster services to create Paymaster Snaps for metamask. The doubt is how can we filter the snaps which will have an exposed `eth_getPaymasterAndData` method. This will help us show the list of snaps installed by the user which can be used as a paymaster. Also, suggest if there is a better alternative than asking the user to install another Snap. ## Customising UI of a snap Would like to know/read about how we can customise the UI of `snap_confirm`. I did read [here](https://docs.metamask.io/guide/snaps.html#features) that it is going to be coing soon. This will be crucial to inform user about the paymaster being used & show information about the transactions that will be executed from the SCW.