Special thanks to Liraz Siri, Yoav Weiss, and the ImToken, Metamask, and OKX developers for their feedback and review.
A critical layer of the Ethereum infrastructure stack, but one that is often underestimated by core L1 researchers and developers, is the wallet. The wallet is the window between the user and the Ethereum world, and the user can only benefit from any decentralization, censorship resistance, security, privacy, or other properties provided by Ethereum and its applications if the wallet itself also possesses these properties.
Recently, weve seen a lot of progress in Ethereum wallets to improve UX, security, and functionality. The purpose of this post is to give my own take on some of the features an ideal Ethereum wallet should have. This is not a complete list; it reflects my cypherpunk tendencies, it focuses on security and privacy, and its almost certainly incomplete in terms of UX. However, I think wish lists are less effective in optimizing UX than simply deploying and iterating based on feedback, so I think focusing on security and privacy properties is the most valuable.
User experience for cross-L2 transactions
There is an increasingly detailed roadmap for improving the user experience across L2, and that roadmap has both a short-term and a long-term part. Here I’ll talk about the short-term part: ideas that are theoretically implementable even today.
The core idea is (i) built-in cross-L2 sends, 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 ) that looks like this:
When someone (or some application) gives you an address in this format, you should be able to paste it into the To field of your wallet and click Send. The wallet should automatically handle the sent data in any way possible:
If you already have enough tokens of the desired type on the target chain, send the tokens directly
If you have a token of the desired type on another chain (or multiple other chains), send the token using a protocol such as ERC-7683 (effectively a cross-chain DEX)
If you have different types of tokens on the same chain or other chains, use a decentralized exchange to convert them to the right type of currency on the right chain and send it. This should require explicit permission from the user: the user will see how much they paid in fees, and how much the recipient received in fees.
A mockup of a possible wallet interface with cross-chain address support
The above works for the “you copy-paste an address (or ENS, e.g. vitalik.eth@optimism.eth ) and someone pays you” use case. If a dapp requests a deposit (e.g. see this Polymarket example ) then the ideal flow would be to extend the web3 API and allow the dapp to make a chain-specific payment request. Your wallet would then be able to fulfill that request in whatever way it needs to. For the user experience to be good, getAvailableBalance requests also need to be standardized, and wallets need to think carefully about which chains to store user assets on by default to maximize security and ease of transfer.
Chain-specific payment requests can also be put into a QR code, which can be scanned by mobile wallets. In an in-person (or online) consumer payment scenario, the recipient will issue a QR code or web3 API call saying I want X units of token Y Z on-chain, with a reference ID or callback W , and the wallet will be free to fulfill that request in any way. Another option is the claim chain protocol, where the users wallet generates a QR code or URL containing a claim authorization to take a certain amount of funds from their on-chain contract, and it is the recipients job to figure out how to transfer those funds to their own wallet.
Another related topic is gas payments. If you receive assets on an L2 that doesnt have ETH yet, and need to send a transaction on that L2, the wallet should be able to automatically use a protocol (e.g. RIP-7755 ) to pay for the gas on the chain where you have ETH. If the wallet wants you to do more transactions on L2 in the future, it should also only use a DEX to send, e.g. a few million gas worth of ETH so that future transactions can spend gas directly there (because its cheaper that way).
Account Security
One way I conceptualize the account security challenge is that a good wallet should serve two purposes simultaneously: (i) protecting users from hacks or malicious attacks by wallet developers, and (ii) protecting users from their own mistakes.
The error on the left was unintentional. However, when I saw it, I realized it fit the context very well, so 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. A users account has two tiers of keys: a master key and N guardians (e.g. N = 5). The master key is capable of low-value and non-financial operations. Most guardians need to perform (i) high-value operations, such as sending the full value in an account, or (ii) changing the master key or any guardian. If desired, the master key can be allowed to perform high-value operations via a time lock.
The above is a basic design that can be expanded. Permission mechanisms such as session keys and ERC-7715 can help support different balances between convenience and security for different applications. More complex guardian architectures, such as having multiple time lock durations at different thresholds, can help maximize the chances of successfully recovering legitimate accounts while minimizing the risk of theft.
The above is a basic design that can be expanded. Permission mechanisms such as session keys and ERC-7715 can help support different balances between convenience and security for different applications. More complex guardian architectures, such as having multiple time lock durations at different thresholds, can help maximize the chances of successfully recovering legitimate accounts while minimizing the risk of theft.
Who or what should the guardian be?
For experienced crypto users in a community of experienced cryptocurrency users, a viable option is the keys of your friends and family. If you ask each person to provide you with a new address, then no one needs to know who they are - in fact, your guardians dont even need to know who each other is. If they havent tipped you off, the chances of them colluding are slim. However, for most new users, this option is not available.
The second option is institutional guardians: companies that specialize in providing services that only sign transactions when they receive additional confirmation of your request: eg. a confirmation code, or a video call for high-value users. People have been trying to make these for a long time, eg. I profiled CryptoCorp in 2013. However, so far these companies have not been very successful.
The third option is multiple personal devices (e.g. phones, desktops, hardware wallets). This can work, but is also difficult to set up and manage for inexperienced users. There is also the risk of devices being lost or stolen at the same time, especially if they are in the same location.
Lately, we’ve started seeing more security solutions based on master keys. Keys can only be backed up on your device, making it a personal device solution, or in the cloud, making their security dependent on a complexmix of cryptographic security, institutions, and trusted hardware assumptions. In reality, keys are a valuable security gain for the average user, but they alone are not enough to protect a user’s life savings.
Fortunately, with ZK-SNARKs, we have a fourth option: ZK-wrapped centralized IDs. This type includes zk-email , Anon Aadhaar , Myna Wallet , etc. Basically, you can take a centralized ID in many forms (corporate or government) and convert it into an Ethereum address, and you can only send transactions by generating a ZK-SNARK that proves that you have the centralized ID.
With this addition, we now have a wide range of choices and the unique “newbie-friendliness” of centralized IDs for ZK wrappers.
To do this, it needs to be done through a simplified and integrated UI: you should be able to just specify that you want example@gmail.com as a guardian, and it should automatically generate a corresponding zk-email Ethereum address under the hood. Advanced users should be able to enter their email (and a privacy salt that might be saved with that email) into an open source third-party application and confirm that the generated address is correct. The same should be true for any other supported guardian type.
Note that one practical challenge with zk-email today is that it relies on DKIM signatures , which use keys that are rotated every few months, and which themselves are not signed by any other authority. This means that zk-email today has some level of trust requirement beyond the provider itself; this could be reduced if zk-email used TLSNotary inside trusted hardware to verify updated keys, but this is not ideal. Hopefully, email providers will start signing their DKIM keys directly. Today, I recommend zk-email to one guardian, but not to most: do not store funds in a setup where a break in zk-email means you can’t access your funds.
New Users and In-App Wallet
New users don’t really want to enter a ton of guardians when they first sign up. So wallets should offer them a very simple option. A natural path would be to do a 2-of-3 selection using zk-email on their email address, a key stored locally on the user’s device (perhaps a master key), and a backup key held by the provider. As users become more experienced or accumulate more assets, at some point they should be prompted to add more guardians.
Wallet integration into apps is inevitable, as apps trying to attract non-crypto users don’t want users to download two new apps at once (the app itself, plus an Ethereum wallet) which creates a cluttered user experience. However, users of many app wallets should be able to link all of their wallets together so they only have to worry about one “access control problem”. The simplest approach is to have a tiered scheme where there is a quick “linking” process that allows users to set their main wallet as the guardian for all of their 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
Beyond account security, todays wallets do a lot to identify fake addresses, phishing, scams, and other external threats, and do their best to protect users from such threats. At the same time, many countermeasures are still fairly primitive: for example, requiring a click to send ETH or other tokens to any new address, regardless of whether youre sending $100 or $100,000. Theres no single silver bullet here. Its a slow, ongoing series of fixes and improvements for different categories of threats. However, theres a lot of value in continuing to work on improvements here.
privacy
It’s time to start taking privacy on Ethereum more seriously. ZK-SNARK technology is now advanced enough, privacy techniques that don’t rely on backdoors to reduce regulatory risk (such as privacy pools ) are becoming more mature, and secondary infrastructure like Waku and ERC-4337 mempools are slowly becoming more stable. However, until now, making private transfers on Ethereum has required users to explicitly download and use a “privacy wallet” like Railway (or Umbra for stealth addresses ). This has added significant inconvenience and reduced the number of people willing to make private transfers. The solution is that private transfers need to be integrated directly into wallets.
A simple implementation is as follows. The wallet can store part of the users assets as a private balance in the privacy pool. When the user transfers money, it will automatically exit the privacy pool first. If the user needs to receive funds, the wallet can automatically generate a stealth address.
Additionally, the wallet can automatically generate a new address for each application the user participates in (e.g., a defi protocol). Deposits will come from the privacy pool and withdrawals will go directly into the privacy pool. This allows a users activity in any one application to be unlinked from their activity in other applications.
One of the advantages of this technology is that it is a natural path not only for privacy-preserving asset transfers, but also for privacy-preserving identity. Identity already happens on-chain: any application that uses identity proof gating (e.g. Gitcoin Grants), any token-gated chat, the Ethereum Follow protocol , and so on are all on-chain identities. We want this ecosystem to be privacy-preserving as well. This means that a users on-chain activity should not be collected in one place: each project should be stored separately, and the users wallet should be the only thing with a global view that can see all of your proofs at once. A native ecosystem with multiple accounts per user helps achieve this, as do off-chain proof protocols like EAS and Zupass .
This represents a pragmatic vision for privacy on Ethereum in the medium term. It is achievable today, although some features could be introduced at L1 and L2 to make privacy-preserving transfers more efficient and reliable. Some privacy advocates argue that the only acceptable thing is complete privacy for everything: encrypting the entire EVM. I think this is likely the ideal long-term outcome, but it requires a more fundamental rethinking of the programming model, and it is not yet at a level of maturity that is ready for deployment on Ethereum. We do need privacy by default to get a sufficiently large anonymity 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 implement, and wallets can start using today.
Ethereum wallets also need to be data wallets
One consequence of any effective privacy solution, whether for payments, identity, or other use cases, is that it creates a need for users to store data off-chain. This is evident in Tornado Cash, which requires users to keep “notes” that each represent a deposit 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 is compromised, or quantum computers become feasible, the data becomes public. The need for off-chain data storage is even more evident in off-chain proofs such as EAS and Zupass.
Wallets need to be software that not only stores on-chain access permissions, but also stores your private data. This is increasingly recognized in the non-crypto world, e.g. see Tim Berners-Lee’s recent work on personal data storage . All the problems we need to solve around robust access control, we also need to solve around robust accessibility and non-leakage of data. Perhaps these solutions can be stacked together: if you have N guardians, use M-of-N secret sharing between those N guardians to store your data. The data is inherently harder to protect because you can’t revoke someone’s share of the data, but we should come up with decentralized custody solutions that are as secure as possible.
Secure chain access
Today, wallets trust their RPC providers to tell them anything about the chain. This is a vulnerability in two ways:
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 with which the user is interacting.
Ideally, we want to close both of these holes. To solve the first problem, we need standardized light clients for L1 and L2 that can directly verify blockchain consensus. Helios already does this for L1, and has been doing some preliminary work to support some specific L2s. In order to properly cover all L2s, we need a standard by which the configuration contract representing an L2 (also for chain-specific addresses) can declare a function, perhaps in a manner similar to ERC-3668 , containing the logic to get the most recent state root and verify proofs of state 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 realistic approach today is to run your own full node. However, now that L2 is coming into view, it is becoming increasingly difficult to run a full node for everything. The equivalent of a light client here is Private Information Retrieval (PIR) . PIR involves a server that keeps a copy of all the data and a client that sends an encrypted request to the server. The server performs computations on all the data, returns the data the client needs, encrypted to the clients key, without revealing to the server which piece of data the client accessed.
To keep the server honest, the individual database entries are themselves Merkle branches, so clients can verify them using a light client.
PIR is computationally expensive. There are several ways to solve this problem:
Brute force: Improvements in algorithms or specialized hardware might make PIR run fast enough. These techniques may depend on preprocessing: the server could store encrypted and scrambled data for each client, and the clients could query that data. The main challenge in the Ethereum environment is adapting these techniques to rapidly changing datasets (like states). This makes real-time computation cheaper, but will likely make total computation and storage costs higher.
Weakens privacy requirements: for example, there can only be 1 million mixins per lookup, so the server will know about the million possible values the client can access, but not any finer granularity.
Multi-server PIR: If you use multiple servers and the honesty between these servers is assumed to be 1-of-N, then the PIR algorithm is usually faster.
Anonymity rather than confidentiality: Requests can be sent through a mixnet, thereby hiding the sender of the request, rather than hiding the content of the request. However, doing so effectively inevitably increases latency, thereby worsening the user experience.
Figuring out the right combination of techniques to maximize privacy while maintaining practicality in the Ethereum context is an open research problem, and I welcome cryptographers to try to do so.
Ideal Keystore Wallet
In addition to transfers and state access, another important workflow that needs to work smoothly in a cross-L2 context is changing the verification configuration of an account: whether it is changing its keys (such as recovery), or making deeper changes to the entire logic of the account. There are three tiers of solutions here, arranged in order of increasing difficulty:
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 owns assets. Potentially, the message format and validation rules can be chain-independent and therefore automatically replayed on as many chains as possible.
Keystore on L1: The configuration information is located on L1, and the wallet on L2 reads it using L1S LOAD or remote static call . In this way, you only need to update the configuration on L1, and the configuration will automatically take effect.
Keystore on L2: Configuration information exists on L2, and wallets on L2 read it using ZK-SNARK. This is the same as (2), except that keystore updates may be cheaper, but on the other hand reads are more expensive.
Solution (3) is particularly powerful because it plays well with privacy. In a normal privacy solution, a user with 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-revealed) secret they control. An invalidator N is published such that future spends of the same leaf fail without revealing L, which depends on the user s being secure. A recovery-friendly privacy solution would say: s is a location (e.g. an address or storage slot) onchain, and a user must prove state queries: L = hash(sload(s), 1).
Dapp Security
The weakest link in user security is often a dapp. Most of the time, users interact with an application by visiting a website, which implicitly downloads the user interface code from a server in real time and then executes it in the browser. If the server is hacked, or the DNS is hacked, the user will get a fake copy of the interface, which could trick the user into performing arbitrary actions. Wallet features such as transaction simulation are very helpful in reducing risk, but they are far from perfect.
Ideally, we will move the ecosystem to on-chain content versioning: users will access dapps by their ENS name, which will contain the IPFS hash of the interface. Updating the interface requires an on-chain transaction from a multisig or DAO. Wallets will show users if they are interacting with a more secure on-chain interface or a less secure Web2 interface. Wallets can also show users if they are interacting with a secure chain (e.g. Phase 1+, multi-security audit).
For privacy-conscious users, the wallet can also add a paranoid mode that requires users to click to accept HTTP requests, not just web3 operations:
Possible interface models for paranoid mode
A more advanced approach would be to go beyond HTML+Javascript and write the business logic of the dapp in a dedicated language (perhaps a relatively thin overlay on Solidity or Vyper). The browser can then automatically generate a UI for any desired functionality. OKContract is already doing this.
Another direction is crypto-economic information defense: dapp developers, security firms, chain deployers, and others could set up a bond that would pay out to the affected users (as determined by some on-chain adjudication DAO) if the dapp was hacked or otherwise harmed users in a highly misleading manner. Wallets could display scores based on the size of the bond to users.
The Longer Future
The above is all in the context of traditional interfaces that involve pointing and clicking things and typing things into text fields. However, we are also on the cusp of a more profound paradigm shift:
Artificial intelligence, which could lead us to move from a point-and-click typing paradigm to a “say what you want to do and the robot will figure it out” paradigm
Brain-computer interfaces, ranging from “gentle” methods like eye tracking to more direct and even invasive techniques (see: First Neuralink patient this year )
Client-side active defense: Brave browser actively protects users from ads, trackers, and many other bad actors . Many browsers, plugins, and crypto wallets have entire teams actively working to protect users from a variety of security and privacy threats. These “active guardians” will only get stronger over the next decade.
Together, these three trends will lead to a deeper rethinking of how interfaces work. Through natural language input, eye tracking, or eventually more direct brain-computer interfaces, coupled with your history (perhaps including text messages, as long as all data is processed locally), a wallet could have a clear and intuitive understanding of what you want to do. The AI could then translate that intuition into a specific 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 a user does interact with a third-party application (or other users), the AI should think adversarially on the users behalf, identifying any threats and proposing an action plan to avoid them. Ideally, there should be an open ecosystem of these AIs, produced by different groups with different biases and incentive structures.
These more radical ideas depend on technology that is very immature today, so I wouldn’t put my assets into a wallet that relies on them today. However, it seems clear that things like this are the trend of the future, so it’s worth starting to explore more actively in this direction.
