Vitalik: What I think the ideal Ethereum wallet is like

Original title: What I would love to see in a wallet

Author: Vitalik, founder of Ethereum; Translator: Deng Tong, Golden Finance

Special thanks to Liraz Siri, Yoav Weiss, and ImToken, Metamask, and OKX developers for their feedback and review.

A key layer of the Ethereum infrastructure stack is the wallet, but it is often underestimated by core L1 researchers and developers. 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, provided that the wallet itself also has these properties.

Recently, we have seen great progress in Ethereum wallets in improving user experience, security, and functionality. The purpose of this post is to give my own views on some of the characteristics that an ideal Ethereum wallet should have. This is not a complete list; it reflects my cypherpunk tendencies, it focuses on security and privacy, and it is 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 most valuable.

UX for Cross-L2 Transactions

There is an increasingly detailed roadmap for improving the UX across L2s, and that roadmap has both a short-term and long-term part. Here, I’ll talk about the short-term part: ideas that are theoretically implementable even today.

The core ideas are (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: [email protected] When someone (or some application) gives you an address in this format, you should be able to paste it into the "Recipient" field of your wallet and click "Send". Wallets should automatically handle the data being sent 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 tokens of the desired type on another chain (or multiple other chains), use a protocol such as ERC-7683 (effectively a cross-chain DEX) to send the tokens;

• If you have different types of tokens on the same chain or other chains, use a decentralized exchange to convert them to the correct type of token on the correct chain and send them. 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.

Model of a possible wallet interface with cross-chain address support

The above is for the use case where you copy-paste an address (or ENS, e.g. [email protected]) so that someone pays you. If a dapp requests a deposit (e.g. see the 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 QR codes, 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 on chain Z, with reference ID or callback W", and the wallet will be free to fulfill that request in any way possible. Another option is a claim chain protocol, where the user's wallet generates a QR code or URL containing an authorization to claim a certain amount of funds from a contract on their chain, and it is the recipient's job to figure out how to transfer those funds to their account.

Another related topic is gas payments. If you receive assets on an L2 that doesn't have ETH yet, and need to send a transaction on that L2, the wallet should be able to automatically use a protocol (such as RIP-7755) to pay for 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 DEX to send. A few million gas worth of ETH, so that future transactions can spend gas directly there (because it's cheaper).

Account Security

One way I conceptualize the challenge of account security is that a good wallet should play two roles at the same time: (i) protect users from hacks or malicious attacks by wallet developers, and (ii) protect 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.

For more than a decade, my preferred solution 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 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) change the master key or any guardian. If needed, the master key can be allowed to perform high-value operations via a timelock.

The above is a basic design, and it 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 with multiple timelock 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 crypto users in a community of experienced crypto users, a viable option is the keys of your friends and family. If you ask each of them 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 is. If they haven’t tipped you off, the chances of them colluding are slim. However, for most new users, this option is not available.

The second option is an institutional guardian: a company that specializes in providing services that will only sign a transaction if they get additional confirmation from your request. A confirmation code, or a video call for high-value users. People have been trying to make these things for a long time. I covered CryptoCorp in 2013. However, companies of this type have not been very successful so far.

The third option is multiple personal devices (e.g. mobile, desktop, hardware wallets). This is feasible, but also difficult to set up and manage for inexperienced users. There is also the risk of devices being lost or stolen, especially if they are co-located.

Recently, we have started to see more and more key-based wallets. Passwords can only be backed up on your device, making them a personal device solution, or in the cloud, making their security dependent on a complex mix of assumptions about password security, institutions, and trusted hardware. In practice, keys are a valuable security gain for the average user, but they are not sufficient on their own 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, and many more. Basically, you can take a centralized ID in many forms (corporate or government), and convert it into an Ethereum address that you can only send transactions to by generating a ZK-SNARK that proves possession of the centralized ID.

With this addition, we now have a wide range of choices and a unique "newbie friendliness" for ZK-wrapped centralized IDs.

To do this, it needs to be implemented through a simplified and integrated UI: you should be able to just specify that you want "[email protected]" as a guardian, and it should automatically generate the corresponding zk-email Ethereum address under the hood. Advanced users should be able to enter their email (and the 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.

Possible secure interface models

Note that a practical challenge with zk-email today is that it relies on DKIM signatures, which use keys that are rotated every few months and that are themselves 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 it’s not ideal. Hopefully, email providers will start signing their DKIM keys directly. Today, I recommend zk-email for one guardian, but not for most: don’t store funds in a setup where a broken zk-email means you can’t access your funds.

New Users and In-App Wallets

New users don’t really want to have to enter a ton of guardians in their first sign-up experience. So wallets should offer them a very simple choice. A natural path would be to go with a 2-of-3 choice 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 the same time (the app itself, plus the Ethereum wallet) which creates a confusing user experience. However, users of many app wallets should be able to link all of their wallets together so that they only have to worry about one "access control problem". The simplest way to do this is to have a tiered scheme where there is a quick "linking" 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, 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 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 you're sending $100 or $100,000. There is no single silver bullet here. It's a slow, ongoing series of fixes and improvements for different classes of threats. However, there is 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 very advanced, privacy technologies that do not 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 required users to explicitly download and use a "privacy wallet" such as Railway (or Umbra for stealth addresses). This adds a huge inconvenience and also reduces 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 a portion of the user's assets in a privacy pool as a "private balance". When a user makes a transfer, it will automatically exit the privacy pool first. If the user needs to receive funds, the wallet can automatically generate a stealth address.

In addition, the wallet can automatically generate a new address for each application the user participates in (for example, a defi protocol). Deposits will come from the privacy pool, and withdrawals will go directly to the privacy pool. This allows the user's 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 (such as 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 user's on-chain activity should not be collected in one place: each project should be stored separately, and the user's wallet should be the only thing with a "global view" that can see all your proofs at once. A native multi-account-per-user ecosystem 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 now, 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 programming models, and it is not yet at a level of maturity that is ready for deployment on Ethereum. We do need privacy by default to achieve 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 it today.

Ethereum Wallets Need to Be Data Wallets, Too

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 save “notes” that each represent a deposit of 0.1-100 ETH. More modern privacy protocols sometimes keep encrypted data on-chain, and use a single private key to decrypt it. This is risky, because if the key is compromised, or quantum computers become feasible, the data is all public. The need for off-chain data storage is even more evident with off-chain proofs like EAS and Zupass.

Wallets need to be software that not only stores on-chain access rights, but also your private data. The non-crypto world is also increasingly recognizing this, 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 feeding them false information, such as about market prices

• RPC providers can extract private information about the applications and other accounts that users are interacting with

Ideally, we want to close both of these loopholes. 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. To properly cover all L2s, we need a standard by which a configuration contract representing an L2 (also for chain-specific addresses) can declare a function, perhaps in a similar fashion to ERC-3668, that contains fetching the most recent state roots, and proving 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 both L1 and L2.

For privacy, the only realistic approach today is to run your own full node. However, now that L2s are coming into the picture, 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 holds a copy of all the data and a client that sends encrypted requests to the server. The server performs computations on all the data, returns the data the client needs, encrypted to the client's key, without revealing to the server which piece of data the client accessed.

To keep the servers honest, the individual database items are themselves Merkle branches, so clients can verify them using light clients.

PIR is computationally expensive. There are several approaches to this problem:

• Brute force: Improvements in algorithms or specialized hardware may make PIR run fast enough. These techniques may depend on preprocessing: the server can store encrypted and scrambled data for each client, and the client can query that data. The main challenge in the Ethereum environment is to adapt these techniques to rapidly changing data sets (like countries). This makes real-time computation cheaper, but will likely make total computation and storage more expensive.

• Weakened privacy requirements: For example, there can only be 1 million "mixins" per lookup, so the server will know about a million possible values ​​that the client can access, but not about any finer granularity.

• Multi-server PIR: If you use multiple servers, and the honesty between those servers is assumed to be 1-of-N, then the PIR algorithm will generally be faster.

• Anonymity instead of confidentiality: Requests can be sent over a mixnet, hiding the sender of the request, but not the content of the request. However, doing so effectively will inevitably increase latency, which will worsen the user experience.

Figuring out the right combination of techniques to maximize privacy while maintaining practicality in the context of Ethereum is an open research problem, and I welcome cryptographers to try to do so.

The Ideal Keystore Wallet

Besides transfers and state access, another important workflow that needs to work smoothly across L2 contexts is changing the validation configuration of an account: whether it’s changing its keys (e.g. recovery), or making deeper changes to the entire logic of an account. There are three tiers of solutions here, in order of increasing difficulty:

• Replay Updates:When a user changes their configuration, the message authorizing this change is replayed on every chain where the wallet detects that the user owns assets. Potentially, the message format and validation rules can be chain-independent, so it can be automatically replayed on as many chains as possible.

• Keystore on L1:The configuration information lives on L1, and the wallet on L2 reads it using L1SLOAD or REMOTESTATICCALL. In this way, only the configuration needs to be updated on L1 and the configuration will automatically take effect.

• Keystore on L2:The configuration information exists on L2, and the wallet on L2 uses ZK-SNARK to read it. This is the same as (2), except that the keystore update may be cheaper, but on the other hand it is more expensive to read.

Solution (3) is particularly powerful because it combines well with privacy. In a normal "privacy solution", the user has a secret s, a "leaf value" L published 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 that ensures that future spends of the same leaf fail without revealing L. This relies on the user keeping s secure. A recovery-friendly privacy solution would say: s is a location on-chain (e.g. an address and a storage slot), and the user must prove for a 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 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 can trick the user into performing arbitrary actions. Wallet features like transaction simulation are very helpful in reducing risk, but they are far from perfect.

Ideally, we would move the ecosystem to on-chain content versioning: users would access dapps by their ENS name, which would contain the IPFS hash of the interface. Updating the interface would require an on-chain transaction from a multisig or DAO. Wallets would show users if they are interacting with a more secure on-chain interface or a less secure Web2 interface. Wallets could also show users if they are interacting with a secure chain (e.g. Phase 1+, multi-security audited).

For privacy-conscious users, wallets could 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 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 could 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 be paid to affected users if a dapp was hacked or harmed users in a highly misleading way. Adjudicated by some on-chain DAO. Wallets could display scores to users based on the size of the bond.

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 away 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, both "gentle" approaches like eye tracking and more direct and even invasive techniques (see: first Neuralink patient this year);

• Client-side active defenses: Brave browser proactively 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 more powerful in 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 a more direct brain-computer interface, coupled with your history (perhaps including text messages, as long as all data is processed locally), the "wallet" can have a clear intuitive understanding of what you want to do. The AI ​​can then translate this intuition into a specific "action plan": a series of on-chain and off-chain interactions to accomplish what you want. This can greatly reduce the need for third-party user interfaces. If the user does interact with a third-party application (or other users), the AI ​​should think adversarially on the user's behalf, identifying any threats and proposing an action plan to avoid them. Ideally, there should be an open ecosystem for these AIs, produced by different groups with different biases and incentive structures.

These more radical ideas rely on extremely immature technologies today, so I would not put my assets in a wallet that relies on them today. However, it seems clear that things like this are the trend of the future, so it is worth starting to explore more actively in this direction.