Investigation into Screen Behaviour (UX)

# Investigation into Screen Behaviour (UX) The UX for web3 payments can often be a sticking point for many users. Getting started with crypto can a challenge and so part of OnRamper's appeal is that it takes the guess work out of this process. Doing the swap from ETH to ERCC20 requires that the user has a web3 wallet. For the MVP of the L2 portion of OnRamper we'll only be integrating MetaMask. Jira ticket [here](https://onramper.atlassian.net/jira/software/c/projects/ONRMP/boards/10/backlog?view=detail&selectedIssue=ONRMP-259&issueLimit=100) ## Challenges Wallet * User might need an explanation of how the swap will work. * User could connectoo to the incorrect network. * User might not have MetaMask installed, in which case we must * User might want to pay with MetaMask wallet, but receive funds in other wallet. Swap * One user's ETH arrives in wallet, the user might want to edit the amount of ETH to swap for ERC20. * After user receives ETH, but before user does swap, the user might have spent some or all of their ETH. * User might want to know the estimated fees/gas. * Slippage & deadline are variables that *must* be set. ## Conclusions Some suggestions are made regarding these potential sticking points: See Figma file [here](https://www.figma.com/file/kie1kPMjSTp6OAKAxEhzwz/Onramper-Swap?node-id=0%3A1) Wallet * MetaMask install tutorial or link to setup. * We assume user wants to receive erc20 in the *same* wallet address, otherwise they may enter a different one. Swap * We assume that the swap parameters have not changed. For example if the user originally receives 2 ETH in the L1 transaction, we prefill the swap input value with 2ETH. If all is set, the user can simply click "swap", however the user is still able to edit the input amount. * Fee breakdown: here we show the estimated gas fee + the swap fee. * At any point, if the user has insufficient balance for the input token (ETH), we show a warning message and disable the swap function. * For the swap, we assume some *reasonable* values for slipppage and deadline. For example 1% slippage & 200 deadline (seconds). The depth of the LP will dictate how much slippage will be needed to make the transaction succeed (otherwise it will revert). So since the transaction *could* revert, ie if 1% slippage or 200 deadline is *too low*, we must make these variables adjustable. We can hide this functionality behind an *advanced settings* icon button.