Original title: What I would love to see in a wallet Original author: Vitalik Buterin Original translation: 深潮 TechFlow
Special thanks to Liraz Siri, Yoav Weiss, and the developers of ImToken, Metamask, and OKX for their feedback and review.
A key layer in the Ethereum infrastructure stack is the wallet, but it is often underestimated by core L1 researchers and developers. Wallets are the window between users and the Ethereum world, and users can only benefit from any decentralized, censorship-resistant, secure, private, or other attributes offered by Ethereum and its applications if the wallets themselves also have these attributes.
Recently, we have seen Ethereum wallets make significant progress in improving user experience, security, and functionality. The purpose of this article is to provide my own views on some characteristics that an ideal Ethereum wallet should have. This is not an exhaustive list; it reflects my cypherpunk tendencies, which focus on security and privacy, and it is almost certainly incomplete in terms of 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 most valuable.
User experience of cross-L2 transactions
There is now an increasingly detailed roadmap for improving the cross-L2 user experience, with both short-term and long-term components. Here, I will discuss the short-term component: ideas that are theoretically still possible to implement 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 application) 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 tokens on the target chain, 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 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. This should require explicit permission from the user: the user will see how much they paid in fees and how much the recipient received.
Model of possible wallet interfaces with cross-chain address support
The above applies to the use case of 'you copy and paste an address (or ENS, e.g., vitalik.eth @ optimism.eth) for someone to pay you'. If the dapp requests a deposit (e.g., see this Polymarket example), then the ideal flow would extend the web3 API and allow the dapp to issue chain-specific payment requests. Then, your wallet will be able to satisfy that request in any way needed. To ensure a good user experience, standardization of the getAvailableBalance request is also needed, and the wallet needs to seriously consider which chains to default to store user assets in order to maximize security and transfer convenience.
Chain-specific payment requests can also be placed in QR codes, which mobile wallets can scan. In face-to-face (or online) consumer payment scenarios, the recipient issues a QR code or web3 API call indicating 'I want X units of token Y Z on-chain, with reference ID or callback W', and the wallet can freely satisfy that request in any way. Another option is the claim link protocol, where the user's wallet generates a QR code or URL containing the claim authorization to retrieve a certain amount of funds from their on-chain contract, and the recipient's job is to figure out how to transfer these funds to their own wallet.
Another related topic is gas payments. If you receive assets on an L2 without ETH and need to send transactions on that L2, the wallet should be able to automatically use a protocol (e.g., RIP-7755) to pay for gas on the chain where you have ETH. If the wallet expects you to conduct 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 (since it's cheaper).
Account Security
One way I conceptualize the challenges of account security is that a good wallet should serve both roles: (i) protecting users from hacks or malicious attacks by wallet developers, and (ii) protecting users from their own mistakes.
The 'error' on the left is unintentional. However, when I saw it, I realized it fit the context very well, so I decided to keep it.
My preferred solution for this, for over a decade, has been social recovery and multi-signature wallets with hierarchical access control. A user's account has 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 are required 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 necessary, the master key may be allowed to execute high-value operations through a time lock.
The above is a basic design that can be expanded. Session keys and permission mechanisms like ERC-7715 can help support different balances between convenience and security across different applications. More complex guardian architectures, such as having multiple time-lock durations at different thresholds, can help maximize the chances of successfully recovering a legitimate account while minimizing the risk of theft.
The above is a basic design that can be expanded. Session keys and permission mechanisms like ERC-7715 can help support different balances between convenience and security across different applications. More complex guardian architectures, such as having multiple time-lock 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 the experienced crypto user community, 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 don't tip you off, the likelihood of them colluding is very low. However, this option is not available for most new users.
The second option is institutional guardians: companies that offer services that only sign transactions upon receiving other confirmation information from you, for example, confirmation codes or video calls for high-value users. People have long tried to create these, for example, 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 it can also be difficult to set up and manage for inexperienced users. There is also the risk of devices being lost or stolen simultaneously, especially when located in the same place.
Recently, we are starting 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, making its security rely on complex mixed assumptions of password security, institutional, and trusted hardware. In practice, keys provide a valuable security gain for ordinary users, but relying solely on them is not enough to protect users' life savings.
Fortunately, with ZK-SNARK, we have a fourth option: ZK-wrapped centralized ID. This type includes zk-email, Anon Aadhaar, Myna Wallet, etc. Essentially, you can take various forms (corporate or governmental) of centralized ID and convert them to Ethereum addresses, allowing you to send transactions only by generating a proof of ownership of the centralized ID via ZK-SNARK.
With this addition, we now have a broad range of options, and ZK-wrapped centralized IDs have a unique 'newbie friendliness'.
To do this, it needs to be achieved 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 privacy salt stored in that email) into an open-source third-party application and confirm that the generated address is correct. This should also apply to any other supported guardian types.
It is worth noting that a practical challenge zk-email faces today is that it relies on DKIM signatures, which use keys that rotate every few months, and these keys are not signed by any other entity. This means that zk-email today has a level of trust requirement that exceeds that of the provider itself; if zk-email uses TLSNotary within trusted hardware to verify updated keys, it could mitigate this, but that is not ideal. Ideally, email providers could start directly signing their DKIM keys. Today, I suggest using zk-email as a guardian, but I do not recommend most guardians to use it: do not store funds in zk-email as losing access means you cannot use the funds.
New users and in-app wallets
New users do not actually want to enter a large number of guardians at the time of their first registration. Therefore, wallets should offer them a very simple option. One natural way is to use zk-email on their email address, a key 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 to add more guardians at some point.
Wallet integration into applications is inevitable because applications trying to attract non-crypto users do not want users to download two new applications (the application itself, plus an Ethereum wallet) at the same time, which brings a confusing user experience. However, many application wallet users should be able to link all their wallets together, so they only have to worry about a single 'access control issue'. The simplest approach is to adopt a hierarchical scheme, where there is a quick 'link' process that allows users to set their main wallet as a guardian for 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.
Protect users from scams and other external threats.
In addition to account security, today’s wallets also do a lot of work to identify fake addresses, phishing, scams, and other external threats, making efforts to protect users from such threats. Meanwhile, many countermeasures remain quite primitive: for example, requiring a click to send ETH or other tokens to any new address, regardless of whether you're sending $100 or $100,000. There is no single silver bullet here. It's a series of slow, ongoing fixes and improvements against different categories of threats. However, there is a lot of value in continuing to work on improvements here.
Privacy
Now is the time to start taking Ethereum privacy more seriously. ZK-SNARK technology is now very advanced, and privacy technologies (such as privacy pools) that do not rely on backdoors to reduce regulatory risk are becoming increasingly mature, while secondary infrastructures such as Waku and ERC-4337 mempools are also 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 Umbra for stealth addresses). This adds significant inconvenience and reduces the number of people willing to conduct private transfers. The solution is to integrate private transfers directly into wallets.
A simple implementation is 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 will 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 privacy pools, and withdrawals will go directly into the privacy pool. This allows user activity in any one application to be unlinkable from their activities in other applications.
One advantage of this technology is that it is not only a natural way to protect privacy of asset transfers but also a natural way to protect privacy of identity. Identities have occurred on-chain: any application using identity proofing gates (e.g., Gitcoin Grants), any token-gated chat, Ethereum-following protocols, etc. are all on-chain identities. We want this ecosystem to protect privacy as well. This means that a user's on-chain activities should not be collected in one place: each project should store individually, and the user's wallet should be the only thing with a 'global view' that can see all of your proofs simultaneously. A native ecosystem where each user has multiple accounts helps achieve this goal, as do off-chain proof protocols like EAS and Zupass.
This represents a pragmatic vision for Ethereum privacy in the medium term. While some features can be introduced on L1 and L2 to make privacy-preserving transfers more efficient and reliable, it can be achieved right now. Some privacy advocates argue that the only acceptable thing is complete privacy for everything: encrypting the entire EVM. I think this might be the ideal long-term outcome, but it requires a more fundamental rethink of the programming model and is not yet at the level of maturity ready for deployment on Ethereum. We do need default privacy to achieve a sufficiently large anonymous set. However, focusing first on (i) transfers between accounts and (ii) identity and identity-related use cases (e.g., private proofs) is a pragmatic first step that is easier to achieve and that wallets can start using now.
Ethereum wallets also need to become data wallets.
One consequence of any effective privacy solution is that it creates a need 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 store encrypted data on-chain and use a single private key to decrypt it. This is risky because if the key is compromised, or if quantum computers become feasible, all the data will be exposed. Off-chain proofs like EAS and Zupass make the need for off-chain data storage even more apparent.
Wallets not only need to become software that stores on-chain access permissions but also software that stores your private data. The non-crypto world is increasingly recognizing this, e.g., see Tim Berners-Lee's recent work on personal data storage. All the issues we need to address regarding robust guarantees of access control, we also need to address regarding robust guarantees of data accessibility and non-leakage. Perhaps these solutions can build on each other: if you have N guardians, use M-of-N secret sharing among these N guardians to store your data. Data is inherently harder to protect because you cannot revoke someone's data share, but we should propose the safest possible decentralized custody solutions.
Secure chain access
Today, wallets trust their RPC providers to tell them anything about the chain. This is a vulnerability with two aspects:
RPC providers may attempt to steal money by providing them with false information, for example, about market prices.
RPC providers can extract private information about the applications and other accounts a user is interacting with.
Ideally, we want to plug 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 already done this for L1 and has been doing some preliminary work to support some specific L2s. To correctly cover all L2s, we need a standard through which the configuration contract representing L2 (also used for chain-specific addresses) can declare a function that may contain logic to obtain the most recent state root and verify proofs against those state roots. This way we can have a universal light client that allows wallets to safely verify any state or event on L1 and L2.
For privacy, the only practical way today is to run your own full node. However, with L2 coming into people's 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 a server that keeps copies of all data and a client that sends encrypted requests to the server. The server performs computations on all the data and returns the data the client needs, encrypted to the client's key, without revealing which data the client accessed to the server.
To keep the server honest, individual database projects themselves are Merkle branches, allowing the client to use a light client to verify them.
The computation involved in PIR (Private Information Retrieval) is quite large. There are several ways to address this problem:
· With brute force: Improvements in algorithms or dedicated hardware may allow PIR to run fast enough. These techniques 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 (like countries). This lowers the computation costs in real-time but is likely to increase overall computation and storage costs.
· Weakening privacy requirements: For example, there can only be a million 'mixins' per lookup, so the server will know the million possible values 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 PIR algorithms can often be faster.
· Anonymity instead of confidentiality: Requests can be sent through mixing networks, hiding the sender of the request instead of hiding the content of the request. However, effectively doing so inevitably increases latency, which worsens the user experience.
Figuring out the right technical combination in the Ethereum environment to maximize privacy while maintaining practicality is an open research question, and I welcome cryptographers to try to do so.
Ideal key vault wallet
In addition to transfer and state access, another important workflow that needs to work smoothly in the cross-L2 context is changing the account's verification configuration: whether changing its keys (e.g., recovery) or making deeper changes to the logic of the entire account. There are three-layer solutions arranged in increasing difficulty:
1. Replay updates: When a user changes their configuration, the message authorizing this change will be replayed on every chain where the wallet detects that the user has assets. It is possible that the message format and verification rules can be independent of the chain, so they can be automatically replayed on as many chains as possible.
2. Key vault on L1: Configuration information is located on L1, and wallets on L2 read it using L1SLOAD or remote static calls. This way, configuration only needs to be updated on L1, and it will automatically take effect.
3. Key vault on L2: Configuration information exists on L2, and wallets on L2 read it using ZK-SNARK. This is similar to (2), except that updating the key vault may be cheaper, but on the other hand, reading it is more expensive.
Solution (3) is particularly powerful because it works well with privacy. In a normal 'privacy solution', the user has a secret s, publishes a 'leaf value' L on-chain, and the user proves that L = hash(s, 1) and N = hash(s, 2) for some (never disclosed) secret they control. The invalid symbol N is published so that ensuring future expenditures of the same leaf fails without revealing L depends on the security of the user's 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 state queries: 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 the server in real-time and execute it in the browser. If the server is hacked, or if the DNS is compromised, the user will receive a false copy of the interface, which may trick them into performing arbitrary actions. Wallet features like transaction simulation are very helpful in reducing risk, but they are still far from perfect.
Ideally, we would shift the ecosystem to on-chain content version control: users would access dapps through their ENS names, which would contain the IPFS hash of the interface. Updating the interface would require an on-chain transaction from a multi-signature or DAO. Wallets would show users whether they are interacting with a more secure on-chain interface or a less secure Web2 interface. Wallets could also show users whether they are interacting with a secure chain (e.g., stage 1+, multi-security audits).
For privacy-conscious users, wallets can also add a paranoid mode that requires users to click to accept HTTP requests, not just web3 operations:
Possible interface model for paranoid mode
A more advanced approach is to go beyond HTML + Javascript, and write the business logic of the dapp in a dedicated language (potentially a relatively thin layer on Solidity or Vyper). Then, the browser can automatically generate the UI for any necessary functionality. OKContract is already doing this.
Another direction is cryptoeconomic information defenses: dapp developers, security companies, 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. Wallets can show users scores based on the size of the bond.
A longer-term future
All of the above is done in the context of traditional interfaces, which involve pointing and clicking on things and entering things into text fields. However, we are also at the cusp of a more profound shift in paradigms:
· Artificial Intelligence could lead us from a click-based typing paradigm to a paradigm where 'you say what you want to do, and the robot figures it out'.
· Brain-machine interfaces: both 'gentle' methods like eye tracking and more direct or 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 malefactors. Many browsers, plugins, and cryptocurrency wallets have entire teams actively dedicated to protecting users from various security and privacy threats. These 'active guardians' will only become stronger over the next decade.
These three trends will collectively lead to a deeper rethinking of how interfaces work. Through natural language input, eye tracking, or eventually more direct brain-machine interfaces, combined with your history (possibly including text messages, as long as all data is processed locally), the 'wallet' can clearly and intuitively understand what you want to do. Then, AI can translate this intuition into a concrete 'action plan': a series of on-chain and off-chain interactions to accomplish what you want to do. This could greatly reduce the need for third-party user interfaces. If users do interact with third-party applications (or other users), AI 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 technologies that are currently very immature, so I would not put my assets in wallets that rely on them today. However, similar things seem to be clearly the trend of the future, so it is worth starting to explore this direction more actively.
Original link
