The Vision of an Ideal Ethereum Wallet: A Comprehensive Upgrade from Cross-Chain Experience to Privacy Protection

The wallet layer in the Ethereum infrastructure is crucial but is often underestimated by core L1 researchers and developers. The wallet is the window through which users interact with the Ethereum world, and only when the wallet itself possesses the corresponding features can users truly benefit from the decentralization, censorship resistance, security, and privacy offered by Ethereum and its applications.

Recently, Ethereum wallets have made significant progress in improving user experience, security, and functionality. This article aims to outline some features that an ideal Ethereum wallet should possess. This is not an exhaustive list, but rather reflects the author's cypherpunk tendencies, focusing on security and privacy, which may fall short in terms of user experience. However, compared to simply deploying and iterating based on feedback, wish lists may be less effective in optimizing user experience, so focusing on security and privacy attributes may be more valuable.

User Experience of Cross-L2 Transactions

The roadmap for improving the cross-L2 user experience has become increasingly clear, including short-term and long-term components. This article will discuss short-term implementable ideas.

The core idea is: ( the built-in cross-chain sending function, ) specific addresses and payment requests for the chain. The wallet should be able to provide users with an address that conforms to a specific ERC draft style.

When users receive an address in this format, they can paste it into the "Recipient" field of the Wallet and click "Send". The Wallet should automatically handle the sending process:

• If there are already enough required tokens on the target chain, send directly.
• If the required tokens are on other chains, use a cross-chain DEX protocol similar to ERC-7683 to send.
• If there are different types of tokens on the same chain or other chains, use DEX to convert to the correct type and send, requiring explicit permission from the user.

This applies to the scenario of "copy-pasting address for payment". In cases where a dapp requests a deposit, the ideal approach is to extend the web3 API, allowing the dapp to issue chain-specific payment requests. The Wallet can flexibly meet this request. To achieve a good user experience, it is also necessary to standardize the getAvailableBalance request. The Wallet needs to carefully consider on which chains the user's assets are stored by default to balance security and transfer convenience.

Specific payment requests on the chain can also be placed in a QR code for mobile wallets to scan. In face-to-face or online consumption payment scenarios, the receiver can issue a QR code or web3 API call indicating "I need Y units of token Z on chain X, reference ID W"; the wallet can flexibly meet this request. Another option is the claim link protocol, where the user's wallet generates a QR code or URL containing the claim authorization, and the receiver is responsible for transferring the funds to their own wallet.

Another related topic is gas payment. If a user receives assets on an L2 without ETH and needs to send a transaction, the Wallet should automatically use the protocol ( like RIP-7755) to pay gas from other chains that have ETH. If the Wallet expects the user to conduct more transactions on that L2 in the future, it can also use a DEX to send enough ETH to cover hundreds of gas payments, so that future transactions can pay gas directly on L2 ( because it is cheaper ).

Account Security

A good conceptual way to think about account security is that an excellent Wallet should serve two purposes: ( protect users from hacks or malicious actions by Wallet developers, and ) protect users from the impact of their own mistakes.

The preferred solution is a social recovery and multi-signature Wallet with hierarchical access control. User accounts have two layers of keys: a master key and N guardians ( where N=5). The master key can perform low-value and non-financial operations. A majority of guardians are required to execute: (1) high-value operations, such as sending all funds from the account, (2) changing the master key or any guardian. If necessary, the master key can be allowed to execute high-value operations through a time lock.

This is the basic design and can be extended. Session keys and permission mechanisms like ERC-7715 can help balance convenience and security across different applications. More complex guardian architectures, such as multiple time locks under different thresholds, can maximize the chances of successfully recovering legitimate accounts while minimizing the risk of theft.

( Guardian selection

For experienced users in the crypto community, they can choose the keys of friends and family as guardians. If everyone is required to provide a new address, they do not even need to know each other's identities. However, this does not apply to most new users.

The second option is institutional custodians: a service that only signs transactions upon receiving additional confirmation information such as a confirmation code or a video call with a high-value user when requested by the user ). Although there have been attempts to establish such services for a long time, they have not been very successful so far.

The third option is multiple personal devices ( such as smartphones, desktops, and hardware Wallets ). This is feasible but can be difficult for novice users to set up and manage. There is also the risk of devices being lost or stolen at the same time, especially when they are located in the same place.

Recently, we are beginning to see more solutions based on universal keys. The keys can either be backed up on the device, becoming a personal device solution, or backed up in the cloud, with security relying on complex hybrid cryptographic security, institutional and trusted hardware assumptions. While they provide valuable security gains for ordinary users, they are still not enough to protect users' life savings on their own.

Fortunately, with ZK-SNARK, we have a fourth option: ZK wrapped centralized IDs. This type includes zk-email, Anon Aadhaar, Myna Wallet, etc. Essentially, various forms of centralized IDs from companies or governments can be taken and converted into Ethereum addresses, and users can only send transactions by generating a ZK-SNARK proof that possesses the centralized ID.

The centralized ID packaged with ZK has a unique "newbie friendliness". To achieve this, a simplified and integrated UI is required: users only need to specify the desired "example@gmail.com" as the guardian, and it should automatically generate the corresponding zk-email Ethereum address in the background. Advanced users should be able to input their email ### and any privacy salt values they may have stored ( into open-source third-party applications and confirm that the generated address is correct. This should also apply to any other supported guardian types.

It should be noted that a practical challenge currently faced by zk-email is its reliance on DKIM signatures, which use keys that are rotated every few months, and these keys themselves are not signed by any other authority. This means that today's zk-email, to some extent, requires trust in the provider itself; if zk-email uses TLSNotary within a trusted hardware to verify the updated keys, it can mitigate this situation, but it is not ideal. It is hoped that email providers will start directly signing their DKIM keys. Currently, it is recommended to use one zk-email as a guardian, but it is not advisable for most guardians: do not store funds in a zk-email as damage means a setup where funds cannot be used.

![Vitalik's New Article: The Vision of an Ideal Wallet, a Comprehensive Upgrade from Cross-Chain Experience to Privacy Protection])https://img-cdn.gateio.im/webp-social/moments-6e92b6b051653e68d5f93ed0d91891eb.webp(

) New users and in-app Wallet

New users actually do not want to enter a large number of guardians during the initial registration. Therefore, the wallet should offer them a very simple option. A natural way is to use zk-email on their email address, with a key stored locally on the user's device, which could be the master key (, along with a backup key held by the provider, for a 2-of-3 selection. As users accumulate more experience or assets, they should be prompted at some point to add more guardians.

Integrating wallets into applications is inevitable because applications that seek to attract non-crypto users do not want users to download two new applications at the same time: ) the application itself plus the Ethereum Wallet ( creates a confusing user experience. However, many in-app wallet users should be able to link all wallets together, so that they only need to focus on one "access control issue." The simplest way is to adopt a hierarchical scheme, allowing users to set the main wallet as the guardian of all in-app wallets through a quick "linking" process.

![Vitalik's new article: The vision of an ideal Wallet, a comprehensive upgrade from cross-chain experience to privacy protection])https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(

) 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, and strive to protect users. At the same time, many countermeasures are still quite primitive: for example, requiring a click to send Ether or other tokens to any new address, regardless of the amount being sent. There is no single magic bullet here, but rather a series of ongoing improvements aimed at different categories of threats. Continuing to improve in this area is very valuable.

![Vitalik's New Article: The Vision of the Ideal Wallet, Comprehensive Upgrades from Cross-Chain Experience to Privacy Protection]###https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp(

Privacy

It's time to take Ethereum's privacy more seriously. ZK-SNARK technology has become very advanced, and privacy technologies that do not rely on backdoors to reduce regulatory risks, such as privacy pools ), are becoming increasingly mature. Secondary infrastructures like Waku and ERC-4337 mempools are also gradually becoming more stable. However, currently, making private transfers on Ethereum requires users to explicitly download and use a "Wallet". This greatly increases inconvenience and reduces the number of people willing to make private transfers. The solution is to integrate private transfers directly into the wallet.

A simple implementation is as follows. The wallet can store a portion of the user's assets as a "private balance" in the 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 hidden address.

In addition, the Wallet can automatically generate a new address for each application the user participates in, such as the defi protocol (. Deposits will come from the privacy pool, and withdrawals will go directly into the privacy pool. This allows users' activities in any one application to be unlinkable from their activities in other applications.

This technology is not only a natural way to protect the transfer of privacy assets but also a natural way to protect privacy identities. Identities have occurred on-chain: any application using identity proof gating ) such as Gitcoin Grants (, any token-gated chat, Ethereum-compliant protocols, etc., are all on-chain identities. We hope this ecosystem can also protect privacy. This means that users' on-chain activities 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 proofs simultaneously. A native ecosystem where each user has multiple accounts helps achieve this goal, and off-chain proof protocols like EAS and Zupass do as well.

This represents a pragmatic vision for Ethereum privacy in the medium term. While some features can be introduced at L1 and L2 to make privacy-preserving transactions more efficient and reliable, it can be achieved now. Some privacy advocates believe that the only acceptable thing is complete privacy for everything: encrypting the entire EVM. This may be the ideal long-term outcome, but it requires a more fundamental rethinking of the programming model.