Ambire Wallet is a next-generation Web3 wallet focused on DeFi and the EVM ecosystem.
This document explains the common user experience issues of Ethereum/EVM wallets, and how smart contract (account abstraction) wallets and in particular Ambire Wallet solve most of them.
It requires some level of prior knowledge of the Ethereum ecosystem and cryptocurrencies.
Throughout this document, when we say Ethereum, we mean the broad EVM ecosystem including all EVM chains like Polygon, Arbitrum, Optimism, Avalanche, Fantom, BSC, etc.
The Ethereum and EVM ecosystem has always been particularly challenging to build a wallet for, due to a few underlying characteristics that ultimately lead to user inconveniences, due to leaky abstractions (complexity "leaking" to the UX layer):
Transaction fees have always been particularly unintuitive for users: for example, you may be inclined to think about increasing the gas limit in the hopes of getting a transaction mined faster, when in fact achieving the opposite.
Fee parameters are even more complicated since EIP-1559, where the gas price is split in base fee and tip. To make matters more complicated, you need to broadcast the transaction with a 'realistic' base fee, but the tip is the main parameter that matters when competing with other transactions.
Historically wallets have opted for exposing the underlying complexities without an attempt to educate users or visually distinct values that should be modified (gas price) vs values that should be automatically calculated (e.g. gas limit).
Finally, gas must be paid in ETH, which is particularly inconvenient for someone who's just starting out their crypto journey and doesn't hold ETH yet, adding an extra step to their journey.
Transactions in Ethereum are sequential, meaning that you can't mine a subsequent transaction if there's another one pending before it.
However, most wallets are not doing a good job of conveying this, leading users to believe that they can 'speed up' a transaction by increasing its fee, despite it being blocked by a prior transaction.
In Ethereum, every transaction can trigger arbitrary code execution, making it potentially dangerous. It's very difficult to visualize the full consequences of a transaction in a wallet, but existing wallets haven't even tried: normally what wallets visualize is just the "to" (interacting with) address, value (ETH sent) and hex data, which is misleading, as multiple value transfers may be happening in this transaction, and obviously not human friendly, as most users can't read the hex data.
This poor visualization has lead to other issues, such as users sending tokens to smart contract addresses because the "to" field of existing transactions that send tokens is not actually the user they sent the tokens to, but the smart contract address, leading them to copy the wrong destination address.