Vitalik: 5 lessons learned about the experience of the crypto user experience

Written by Vitalik Buterin

Compiled: The Way of DeFi Overnight porridge

Image source: Generated by Maze AI

In 2013, I went to a sushi restaurant next to the Internet Archive in San Francisco because I heard that Bitcoin was accepted and I wanted to try it. When it was time to pay the bill, I asked to pay in BTC. I scanned the QR code and clicked "Send". To my surprise, the deal was not completed, it seemed to be sent, but the restaurant did not receive it. I tried again and still couldn't finish. I quickly discovered that the problem was with my cell phone connection. I had to walk more than 50 meters to the nearby Internet Archive to access the wifi, which eventually allowed me to send the deal.

Lesson learned: The Internet is not 100% reliable, and the customer Internet is not as reliable as the merchant Internet. We need face-to-face payment systems with certain features (NFC, customers presenting QR codes, etc.) to allow customers to transmit their transaction data directly to the merchant (if this is the best way to broadcast).

In 2021, I tried to buy tea for myself and my friends at a coffee shop in Argentina. According to the coffee shop owner, the shop didn't specifically accept cryptocurrencies, he just recognized me and showed me one of his accounts on a cryptocurrency exchange, so I recommend paying with ETH (in Latin America, using a cryptocurrency exchange account as a wallet is the standard way to make in-person payments). Unfortunately, my first trade of 0.003 ETH was not accepted, probably because it was below the minimum deposit of 0.01 ETH on the exchange, then I sent another 0.007 ETH and soon both transactions were confirmed (I don't mind paying 3x more and taking it as a tip).

In 2022, I tried to buy tea at a different location and the first transaction failed because the default transaction of my mobile wallet only sent 21000 gas, while the receiving account is a contract that requires additional gas to process the transfer. The attempt to send a second transaction also failed because a UI glitch in my mobile wallet prevented scrolling down and editing the field containing the gas limit.

Lesson learned: Simple yet powerful UIs are better than fancy and sleek UIs. Also, most users don't even know what gas limits are, so we really just need to have better defaults.

Many times there is a surprisingly long delay between when my transaction is accepted on-chain and when the service confirms the transaction, and sometimes, I do worry that something is wrong with the payment system on their side.

Many times, there is a surprisingly long and unpredictable time delay between sending a transaction and when that transaction is accepted in a block. Sometimes, a transaction is accepted within seconds, but sometimes it can take minutes or even hours. Recently, EIP-1559 has significantly improved this, ensuring that most transactions are accepted into the next block, and even more recently, Merge has improved this further by stabilizing block times.

The chart is from a report by Yinhong (William) Zhao and Kartik Nayak

However, outliers remain. If you send a transaction at the same time that many other people send it, and the base fee skyrockets, you may run the risk that the base fee will be too high and your transaction will not be accepted. To make matters worse, the wallet UI is not good at displaying this. There won't be a big red flashing alert and no clear indication of how you should fix the issue. Even for an expert who knows that in this case you should "speed up" the transaction by posting a new transaction with the same data but a higher base fee, it is often not clear what to do.

Lesson learned: The user experience around transactions needs to be improved. Thanks to the Brave Wallet team for taking my advice on this topic seriously, starting with increasing the base fee tolerance from 12.5% to 33%, and recently exploring how to show stuck transactions more visibly in the UI.

In 2019, I tested one of the first wallets to try to offer social recovery features. Unlike my preferred smart contract-based approach, their approach is to split the account's private key into five parts using the Shamir secret sharing scheme, so that any three of them can be used to recover the private key. Users are required to select five friends ("guardians"), convince them to download a separate mobile app, and provide a confirmation code to create an encrypted connection from the user's wallet to the friend's app via Firebase and send them a share of the key.

This approach quickly caused me problems. A few months later, something went wrong with my wallet and I needed to use a recovery program to recover it. I asked my friend to perform the recovery procedure with me through their app, but it didn't go as planned. Two of them lost key fragmentation because they changed phones and forgot to migrate the recovery app. Third, the Firebase connection mechanism does not work properly for a long time. Eventually, we figured out how to fix the problem and recover the key. However, a few months later, the wallet broke again. This time, somehow, regular software updates accidentally reset the application's storage and remove its keys. But I didn't add enough recovery guardians because the Firebase connection mechanism was too bad for me to do this successfully. In the end, I lost a small amount of BTC and ETH.

Lesson: Off-chain social recovery based on secret sharing schemes is really fragile unless there is no other choice, and it's not a good idea either. Your recovery guardian doesn't have to download a separate app, because if you only have one app for special cases like recovery, it's easy to forget it and lose it. In addition, the need for separate centralized communication channels poses various problems. Instead, the way to add guardians should be to provide their ETH address, and recovery should be done through smart contracts, using ERC-4337 account abstract wallets. That way, guardians only need to help recover without losing their Ethereum wallets (which is something they're already more concerned about).

In 2021, I tried to save money when using Tornado Cash by using the "self-relay" option. Tornado Cash uses a "relay" mechanism where third parties push transactions on-chain because when you withdraw, you usually don't have coins in your withdrawal address yet, and you don't want to pay for transactions with your deposit address because that creates a public link between the two addresses, and that's all Tornado Cash tries to prevent. The problem is that relay mechanisms are often expensive, and relays can charge much higher than the actual gas fees for transactions.

To save costs, at one point, I made my first small withdrawal using a relay, which would charge a lower fee, and then used the "self-relay" feature in Tornado Cash to send a second larger withdrawal on my own without using a relay. The problem is, I messed up and accidentally did this while logging into my deposit address, so the deposit address paid the fee instead of the withdrawal address, which caused me to create a public link between the two.

Lesson learned: Wallet developers should start thinking more explicitly about privacy. In addition, we need better forms of account abstraction to eliminate the need for centralized or even federated relays and commoditize the relay role.

miscellaneous

A lot of apps still don't work with the Brave wallet or Status browser, most likely because they didn't do their homework and relied on Metamask-specific APIs. Even Gnosis Safe hadn't used these wallets for a long time, forcing me to write my own mini Javascript dapp to confirm it. Fortunately, the latest UI has fixed this issue.

ERC20 transfer pages on Etherscan (e.g. https://etherscan.io/address/0xd8da6bf26964af9d7eed9e03e53415d37aa96045#tokentxns) are vulnerable to counterfeit transaction attacks, anyone can create a new ERC20 token with logic that emits a log, Claims that I or any other specific person sent someone else's token. This is sometimes used to trick people into thinking that I support some scam token when in fact I have never heard of it.

Uniswap used to offer a really handy feature, with the ability to exchange tokens and send output to different addresses. It's really handy when I have to pay someone with USDC but I don't have USDC in my wallet. Now the interface no longer provides this functionality, so I have to convert it first and then send it in a separate transaction, which is less convenient and wastes more gas. Since then, I've learned that Cowswap and Paraswap offer that functionality, although Paraswap... It doesn't seem to work with the Brave wallet at the moment.

Logging in with Ethereum is great, but it's still hard to use if you're trying to log in on multiple devices and your Ethereum wallet can only be used on one device.

conclusion

A good user experience is not about the average, but about the worst. A clean and stylish UI, but it does something weird and unexplained 0.723% of the time, then that leads to big problems, which is worse than a user interface that exposes more details to the user.

In addition to the very important issue of high transaction fees brought about by scale that has not yet been fully addressed, user experience is also a key reason why many Ethereum users, especially those in the Global South, often choose centralized solutions rather than on-chain decentralized solutions that put power in the hands of users and their friends, family, or local communities. Over the years, Crypto's user experience has made huge progress, especially from an average transaction before EIP-1559 that took a few minutes to complete to an average transaction that took only a few seconds to complete after EIP-1559 and after the merger, making Ethereum's user experience very pleasant. However, we still have more work to do.