Special thanks to Liraz Siri, Yoav Weiss, and the feedback and reviews from developers at ImToken, Metamask, and OKX.
A key layer of the Ethereum infrastructure stack is wallets, but they are often underestimated by core L1 researchers and developers. Wallets are the window between users and the Ethereum world, where users can only benefit from any decentralized, censorship-resistant, secure, private, or other attributes provided by Ethereum and its applications, provided that the wallet itself also possesses these attributes.
Recently, we have seen significant progress in Ethereum wallets in improving user experience, security, and functionality. The purpose of this article is to provide my perspective on some of the characteristics that an ideal Ethereum wallet should possess. This is not a complete list; it reflects my cypherpunk tendencies, focusing on security and privacy, and it is almost certainly incomplete regarding user experience. However, I believe that wish lists are less effective in optimizing user experience than simply deploying and iterating based on feedback, so I think focusing on security and privacy attributes is the most valuable.
User experience across L2 transactions
There is now an increasingly detailed roadmap for improving the cross-L2 user experience, with both short-term and long-term parts. Here, I will discuss the short-term part: ideas that can still be implemented theoretically today.
The core idea is (i) built-in cross-L2 sending, and (ii) chain-specific addresses and payment requests. Your wallet should be able to provide you with an address (following the style of this ERC draft) as follows:
When someone (or some applications) provides you with an address in this format, you should be able to paste it into the wallet's 'recipient' field and then click 'send.' The wallet should automatically handle the sending data in any possible way:
If you already have enough of the required type of token on the target chain, please send the tokens directly.
If you have the required type of token on another chain (or multiple other chains), use protocols like ERC-7683 (essentially a cross-chain DEX) to send the tokens.
If you have different types of tokens on the same chain or other chains, use decentralized exchanges to convert them into the correct type of currency on the correct chain and send them. This should require explicit consent from the user: the user will see how much they paid in fees and how much the recipient received.
A potential wallet interface model with cross-chain address support
The above applies to the use case of 'you copy and paste the address (or ENS, e.g., vitalik.eth @ optimism.eth) and someone pays you'. If a dapp requests a deposit (e.g., see this Polymarket example), then the ideal flow is to extend the web3 API and allow the dapp to issue chain-specific payment requests. Then, your wallet will be able to meet that request in any way needed. To ensure a good user experience, it’s also necessary to standardize the getAvailableBalance request, and the wallet needs to seriously consider which chains to default to for storing user assets to maximize security and transfer convenience.
Chain-specific payment requests can also be embedded in QR codes, which mobile wallets can scan. In face-to-face (or online) consumer payment scenarios, the recipient will issue a QR code or web3 API call indicating 'I want X units of token YZ on-chain, with reference ID or callback W,' and the wallet will be free to meet that request in any way. Another option is a claim link protocol, where the user's wallet generates a QR code or URL containing claim authorization to fetch a certain amount of funds from their on-chain contract, and the recipient's job is to figure out how to transfer those funds into their own wallet.
Another related topic is gas payment. If you receive assets on an L2 that does not have ETH yet and need to send transactions on that L2, the wallet should be able to automatically use protocols (e.g., RIP-7755) to pay for gas on the chain where you have ETH. If the wallet expects you to make more transactions on L2 in the future, it should also only use DEX to send, for example, ETH worth millions of gas, so that future transactions can spend gas directly there (as it is cheaper).
Account Security
One way I conceptualize the challenges of account security is that a good wallet should serve effectively in two ways: (i) protecting users from hacks or malicious attacks by wallet developers, and (ii) protecting users from the effects of their own mistakes.
The 'error' on the left is unintentional. However, when I saw it, I realized it fit the context so well that I decided to keep it.
My preferred solution to this, for over a decade, has been social recovery and multi-signature wallets with hierarchical access control. Users' accounts have two layers of keys: a master key and N guardians (e.g., N = 5). The master key is capable of performing low-value and non-financial operations. Most guardians need to perform (i) high-value operations, such as sending the entire value in the account, or (ii) changing the master key or any guardian. If needed, the master key can be allowed to perform high-value operations through time locks.
The above is the basic design, which can be expanded. Session keys and permissions mechanisms like ERC-7715 can help support different balances between convenience and security for different applications. More complex guardian architectures, such as having multiple time-locked durations at different thresholds, can help maximize the chances of successfully recovering a legitimate account while minimizing the risk of theft.
The above is the basic design, which can be expanded. Session keys and permissions mechanisms like ERC-7715 can help support different balances between convenience and security for different applications. More complex guardian architectures, such as having multiple time-locked durations at different thresholds, can help maximize the chances of successfully recovering a legitimate account while minimizing the risk of theft.
Who or what should the guardians be?
For experienced cryptocurrency users in a community of seasoned crypto users, a viable option is the keys of your friends and family. If you ask everyone to provide you with a new address, then no one needs to know who they are - in fact, your guardians don’t even need to know who each other are. If they haven’t tipped you off, the likelihood of collusion is minimal. However, this option is not available to most new users.
The second option is institutional guardians: companies that provide services that only sign transactions when they receive other confirmation information from your request: for example, confirmation codes, or video calls for high-value users. People have long tried to create these, e.g., I introduced CryptoCorp in 2013. However, so far, these companies have not been very successful.
The third option is multiple personal devices (e.g., phone, desktop, hardware wallet). This can work but can also be difficult to set up and manage for inexperienced users. There is also the risk of losing or having devices stolen simultaneously, especially when they are located in the same place.
Recently, we began to see more based on master keys. Keys can only be backed up on your device, making it a personal device solution, and can also be backed up in the cloud, relying on complex hybrid password security, institutional and trusted hardware assumptions. In fact, keys are a valuable security gain for average users, but relying solely on them is not enough to protect users' life savings.
Fortunately, with ZK-SNARK, we also have a fourth option: ZK-wrapped centralized IDs. This type includes zk-email, Anon Aadhaar, Myna Wallet, etc. Essentially, you can take centralized IDs in various forms (company or government) and convert them into Ethereum addresses, which you can only send transactions with by generating a proof that you own the centralized ID via ZK-SNARK.
With this supplement, we now have a wide range of options, and ZK-wrapped centralized IDs have a unique 'newbie friendliness.'
To achieve this, it needs to be done through a simplified and integrated UI: you should be able to specify that you want 'example@gmail.com' as a guardian, and it should automatically generate the corresponding zk-email Ethereum address under the hood. Advanced users should be able to input their email (and possibly a privacy salt value stored in that email) into an open-source third-party application and confirm that the generated address is correct. This should be true for any other supported guardian types as well.
Note that one practical challenge zk-email faces today is that it relies on DKIM signatures, which use keys that rotate every few months, and these keys themselves are not signed by any other authority. This means that today's zk-email has a certain level of trust requirement beyond the provider itself; if zk-email used TLSNotary to verify the updated keys within trusted hardware, it could alleviate this, but it is not ideal. I hope email providers can start directly signing their DKIM keys. Today, I suggest one guardian use zk-email, but I do not recommend most guardians use it: do not store funds in zk-email; a compromise means you cannot use the funds.
New users and in-app wallets
New users actually do not want to enter a large number of guardians at the time of their first registration. Therefore, the wallet should offer them a very simple option. A natural way is to use zk-email on their email address, keys stored locally on the user’s device (possibly a master key), and a backup key held by the provider, creating a 2-of-3 option. As users become more experienced or accumulate more assets, they should be prompted at some point to add more guardians.
It is inevitable that wallets will be integrated into applications, as applications trying to attract non-crypto users do not want users to download two new applications simultaneously (the application itself, plus the Ethereum wallet), which creates a confusing user experience. However, many application wallet users should be able to link all their wallets together, so they only need to worry about one 'access control issue.' The simplest way is to adopt a hierarchical scheme, where there is a quick 'link' process that allows users to set their main wallet as the guardian of all in-app wallets. The Farcaster client Warpcast already supports this:
By default, the recovery of your Warpcast account is controlled by the Warpcast team. However, you can 'take over' your Farcaster account and change the recovery to your own address.
Protecting users from scams and other external threats
In addition to account security, today's wallets also do a lot of work to identify fraudulent addresses, phishing, scams, and other external threats, and do their best to protect users from such threats. Meanwhile, many countermeasures are still quite primitive: for example, requiring a click to send ETH or other tokens to any new address, regardless of whether you are sending $100 or $100,000. There is no single silver bullet here. It is a series of slow, ongoing fixes and improvements for different categories of threats. However, continuing to push for improvements here is very valuable.
Privacy
Now is the time to start taking Ethereum's privacy more seriously. ZK-SNARK technology is now quite advanced, and privacy technologies that do not rely on backdoors to reduce regulatory risks (such as privacy pools) are becoming increasingly mature, while secondary infrastructures like Waku and ERC-4337 mempools are slowly becoming more stable. However, so far, making private transfers on Ethereum requires users to explicitly download and use 'privacy wallets,' such as Railway (or for stealth addresses, Umbra). This adds immense inconvenience and reduces the number of people willing to make private transfers. The solution is to integrate private transfers directly into wallets.
A simple implementation looks as follows. The wallet can store part of the user's assets as a 'private balance' in a privacy pool. When the user makes a transfer, they first automatically exit the privacy pool. If the user needs to receive funds, the wallet can automatically generate a stealth address.
Additionally, wallets can automatically generate a new address for each application the user participates in (e.g., DeFi protocols). Deposits will come from the privacy pool, and withdrawals will go directly into the privacy pool. This allows activities in one application to unlink from activities in other applications.
One advantage of this technology is that it is not only a natural way of transferring assets while protecting privacy but also a natural way of protecting identity. Identities have already happened on-chain: any application that uses identity-proof gating (e.g., Gitcoin Grants), any token-gated chat, Ethereum-following protocols, etc., are all on-chain identities. We want this ecosystem to also protect privacy. This means that users' on-chain activities should not be collected in one place: each project should store its data separately, and the user's wallet should be the only entity with a 'global view' that can simultaneously see all of your proofs. A native ecosystem where each user has multiple accounts helps achieve this, as do off-chain proof protocols like EAS and Zupass.
This represents a pragmatic vision for Ethereum privacy in the medium term. Although some features can be introduced on L1 and L2 to make privacy-preserving transfers more efficient and reliable, it is already achievable now. Some privacy advocates believe that the only acceptable thing is complete privacy for everything: encrypting the entire EVM. I believe this may be an ideal long-term outcome, but it requires a more fundamental rethinking of the programming model, and it is not yet at a mature level ready for deployment on Ethereum. We do need default privacy to achieve sufficiently large anonymous sets. However, first focusing on (i) transfers between accounts, and (ii) identity and identity-related use cases (such as private proofs) is a pragmatic first step that is more easily achievable and that wallets can start using right now.
Ethereum wallets also need to become data wallets.
One consequence of any effective privacy solution is that it creates a demand for users to store off-chain data. This is evident in Tornado Cash, which requires users to keep 'tickets' representing deposits of 0.1-100 ETH. More modern privacy protocols sometimes keep encrypted data on-chain and decrypt it using a single private key. This is risky because if the key leaks or quantum computers become feasible, the data will be fully exposed. Off-chain proofs like EAS and Zupass make the demand for off-chain data storage even more evident.
Wallets need not only to become software for storing on-chain access but also to become software for storing your private data. The non-encrypted world is also increasingly recognizing this; for example, see Tim Berners-Lee's recent work on personal data storage. All the issues we need to solve around robust guarantees of access control, we also need to solve around robust guarantees of data accessibility and non-leakage. Perhaps these solutions can stack: if you have N guardians, use M-of-N secret sharing to store your data among these N guardians. Data is inherently harder to protect because you cannot revoke someone's data share, but we should propose decentralized custody solutions that are as secure as possible.
Secure chain access
Nowadays, wallets trust their RPC providers to tell them any information about the chain. This is a vulnerability with two aspects:
RPC providers may try to steal money by providing them with false information, e.g., about market prices.
RPC providers can extract private information about the applications and other accounts that the user is interacting with.
Ideally, we want to close both of these vulnerabilities. To address the first issue, we need standardized light clients for L1 and L2 that can directly verify blockchain consensus. Helios has done this for L1 and has been doing some preliminary work to support some specific L2s. To properly cover all L2s, we need a standard by which the configuration contract representing L2 (also used for chain-specific addresses) can declare a function, possibly in a manner similar to ERC-3668, that includes the logic for obtaining the latest state root and verifying proof for those state roots and receipts against those state roots. This way we can have a universal light client that allows wallets to securely verify any state or event on L1 and L2.
For privacy, the only practical method today is to run your own full node. However, now that L2s are coming into view, running a full node for everything is becoming increasingly difficult. The equivalent of a light client here is Private Information Retrieval (PIR). PIR involves servers that hold copies of all the data and clients that send encrypted requests to the server. The server computes over all the data and returns the data requested by the client, encrypted with the client's key, without revealing to the server which piece of data the client accessed.
To keep the servers honest, individual database projects themselves are Merkle branches, allowing clients to verify them using light clients.
The computational load of PIR (often referring to 'Private Information Retrieval', a protocol or technique allowing users to retrieve information from a database without disclosing the information retrieved) is very high. There are several ways to solve this problem:
By brute force: improvements in algorithms or dedicated hardware may allow PIR to run fast enough. These technologies may depend on preprocessing: servers can store encrypted and shuffled data for each client, and clients can query that data. The main challenge in the Ethereum environment is adapting these technologies to rapidly changing datasets (just like countries). This makes real-time computation cheaper, but likely makes total computation and storage costs higher.
Weaken privacy requirements: for example, there can only be one million 'mixins' per lookup, so the server will know the million possible values that the client can access, but not any finer granularity.
Multi-server PIR: If you use multiple servers, and the honesty assumption between these servers is 1-of-N, then the PIR algorithm is usually faster.
Anonymity instead of confidentiality: requests can be sent through mixing networks, hiding the sender of the request rather than the content of the request. However, doing so effectively will inevitably increase latency, worsening the user experience.
Finding the right combination of technologies in the Ethereum environment to maximize privacy while maintaining practicality is an open research question, and I welcome cryptographers to try to do this.
Ideal key vault wallet
In addition to transfer and state access, another important workflow that needs to work smoothly in cross-L2 contexts is changing the verification configuration of accounts: whether it is changing their keys (e.g., recovery) or making deeper changes to the logic of the account as a whole. There are three layered solutions arranged in increasing order of difficulty:
Replay updates: when users change their configuration, the message authorizing this change will be replayed across every chain where the wallet detects the user has assets. It is possible that the message format and validation rules could be independent of the chain, allowing for automatic replay on as many chains as possible.
Key vault on L1: configuration information is located on L1, and wallets on L2 use L1SLOAD to read it or remote static calls. Thus, only updating the configuration on L1 will automatically take effect.
Key vault on L2: configuration information exists on L2, and wallets on L2 read it using ZK-SNARK. This is the same as (2), except that key vault updates may be cheaper, but reading is more expensive on the other hand.
Solution (3) is particularly powerful because it integrates well with privacy. In normal 'privacy solutions,' users have secrets s, publish 'leaf value' L on-chain, and users prove L = hash(s, 1) and N = hash(s, 2) for some (never revealed) secret they control. An invalid symbol N is published, ensuring that future expenditures of the same leaf will fail without revealing L, depending on the security of user s. A recovery-friendly privacy solution would say: s is a location (e.g., address and storage slot) on-chain, and the user must prove the state query: L = hash(sload(s), 1).
Dapp Security
The weakest link in user security is often the dapp. Most of the time, users interact with applications by accessing websites, which implicitly download user interface code from servers in real time and execute it in the browser. If the server is hacked, or the DNS is hacked, users will receive a false copy of the interface, which may trick them into executing arbitrary operations. Wallet features like transaction simulation are very helpful in reducing risks, but they are far from perfect.
Ideally, we would transition the ecosystem to on-chain content version control: users would access dapps via their ENS name, which would contain the IPFS hash of the interface. Updating the interface would require an on-chain transaction from a multi-signature or DAO. The wallet would show users whether they are interacting with a more secure on-chain interface or a less secure Web2 interface. The wallet could also show users whether they are interacting with a secure chain (e.g., phase 1+, multi-security audits).
For privacy-focused users, wallets can also add paranoid mode, requiring users to click to accept HTTP requests, not just web3 operations:
Possible interface model for paranoid mode
More advanced approaches move beyond HTML + Javascript and write the business logic of dapps in a dedicated language (possibly a relatively thin layer on top of Solidity or Vyper). Then, the browser can automatically generate the UI for any required functionality. OKContract is already doing this.
Another direction is cryptoeconomic information defenses: dapp developers, security firms, chain deployers, and others can establish a bond that pays affected users (as determined) if the dapp is hacked or harms users in a highly misleading way, by some on-chain adjudication DAO. Wallets can show users a score based on the bond size.
A longer-term future
The above all takes place in the context of traditional interfaces, which involve pointing and clicking at things and entering things into text fields. However, we are also on the cusp of a paradigm shift that is much deeper.
Artificial intelligence, which may lead us from a click-typing paradigm to a paradigm of 'say what you want to do, and the robot will figure it out.'
Brain-computer interfaces, with both 'gentle' methods like eye tracking and more direct, even invasive technologies (see: the first Neuralink patient this year).
Client-side proactive defenses: the Brave browser actively protects users from ads, trackers, and many other malicious entities. Many browsers, plugins, and crypto wallets have entire teams dedicated to protecting users from various security and privacy threats. These 'proactive guardians' will only become stronger over the next decade.
These three trends together will lead to a deeper rethinking of how interfaces work. With natural language input, eye tracking, or ultimately more direct brain-computer interfaces, combined with your historical data (perhaps including text messages, as long as all data is processed locally), the 'wallet' can clearly and intuitively understand what you want to do. Then, artificial intelligence can translate that intuition into a concrete 'action plan': a series of on-chain and off-chain interactions to accomplish what you want. This could greatly reduce the need for third-party user interfaces. If users do interact with third-party applications (or other users), artificial intelligence should engage in adversarial thinking on behalf of the user, identifying any threats and proposing action plans to avoid them. Ideally, these AIs should have an open ecosystem, generated by different groups with different biases and incentive structures.
These more radical ideas depend on technology that is very immature today, so I would not put my assets into wallets that rely on them today. However, similar things seem to clearly be the trend of the future, so it is worth starting to explore this direction more actively.
