The Origin of EIP-6963

In the blockchain ecosystem, browser extension wallets are wallet applications that exist in the form of browser plugins. They allow users to conveniently interact with blockchain accounts directly within dApps, such as sending transactions, signing messages, or interacting with smart contracts. The most typical example is MetaMask, which has almost become a standard tool for using Ethereum ecosystem dApps. Unlike traditional applications, browser extension wallets are embedded in the browser environment. This method simplifies the user interaction process with the blockchain and eliminates the technical barriers of complex node operations or private key management. Users only need to install the extension to quickly start using the blockchain network.

In this context, a “service provider” refers to the underlying technology or interface that supports these wallet functions. For example, wallets communicate with blockchain nodes through the Ethereum JSON-RPC protocol, while the service provider offers the corresponding RPC interface to allow the wallet to securely handle on-chain interactions.

Imagine you want to use a decentralized exchange (DEX) or an NFT marketplace. You open the dApp’s website, excited to start interacting. However, a problem arises — your browser has multiple wallet extensions installed, such as MetaMask, Coinbase Wallet, and Brave Wallet, but the dApp fails to correctly identify which wallet you are currently using and even throws an error message: “No wallet detected, please install a wallet extension.” You try refreshing the page and restarting the browser, but the issue persists. This common scenario highlights a practical problem: the identification and interaction mechanisms of browser extension wallets are inadequate. As more wallet extensions and service providers emerge, the user experience becomes more complicated and confusing.

To address the interaction issues between wallets and dApps, the community introduced EIP-1193 (Ethereum JavaScript Provider API), a universal standard that defines how dApps can communicate with wallets via the browser environment. The core idea of EIP-1193 is to handle the blockchain functions provided by the wallet through a standardized interface. For example, a dApp communicates with the wallet via the window.ethereum object, sending requests or receiving blockchain events.

Although EIP-1193 partially addresses compatibility issues between wallets and dApps, it still has some obvious limitations:

1. Multi-wallet Conflict: When users have multiple browser extension wallets installed, EIP-1193 by default binds window.ethereum to the first wallet that is loaded. As a result, other wallets may not be correctly recognized, and in some cases, the dApp might not work at all.
2. Lack of Multi-service Support: Many dApps want to support multiple wallets, but EIP-1193 does not provide a clear mechanism to distinguish or choose between different service providers. This forces dApp developers to design complex logic to handle wallet adaptation.
3. Unintuitive User Experience: For regular users, it is difficult to understand the technical reasons behind error messages like “No wallet detected” or “Not connected properly,” which increases the usage threshold and leads to frustration.

To solve this problem, the community proposed EIP-6963 (Browser Extension Wallet Discovery Standard), an improvement plan for browser extension wallets aimed at optimizing wallet discovery and interaction mechanisms. The solution aims to lower the entry barrier for new wallet providers, promote fairer competition, and enhance the user experience on the Ethereum network. Specifically, it introduces a set of window events and provides a bidirectional communication protocol, allowing Ethereum libraries and scripts injected by browser extensions to interact. This will enable users to select their preferred wallet based on their needs, improving the overall experience.

Code Analysis

Reverse DNS (RDNS)

Reverse DNS (RDNS) ensures the stability of wallet provider identifiers while preventing namespace conflicts. EIP-6963 emphasizes the rules RDNS conventions should follow, such as valid domain formats and domain parts controlled by the provider. It also stresses that dApps should not rely on the RDNS value for feature detection to avoid the possibility of forged or malicious incentives. The EIP-6963 ProviderDetail interface provides dApps with wallet provider metadata, assisting in wallet interaction.

EIP6963ProviderDetail

The EIP6963ProviderDetail is an interface used to declare and describe wallet provider information. By including properties such as info (wallet metadata) and provider (wallet provider interface), it enables dApps to obtain detailed information about wallets and interact with them via standardized interfaces. This interface serves as the foundation for achieving compatibility and interoperability between decentralized applications and various wallets.

Event Mechanism

The event mechanism ensures that dApps and wallets can discover and interact with each other without being dependent on a fixed execution order. This allows the discovery and interaction between dApps and wallets to be unaffected by execution order, thus avoiding conflicts and errors.

Event Types

EIP6963AnnounceProviderEvent: This event is used by wallets to announce their presence. It contains information about the wallet (EIP6963ProviderDetail) and the wallet interface (EIP1193Provider). The detail property of this event holds the wallet’s frozen metadata (using Object.freeze()) to ensure immutability.

EIP6963RequestProviderEvent:This event is used by dApps to request a wallet provider. The dApp uses this event to notify the wallet that it is ready and requests interaction.

Event Concurrency

Due to the indeterminate execution order of dApp and wallet code, race conditions may arise. The event mechanism is specifically designed to ensure that dApps and wallets can correctly handle events when they discover each other. A wallet may emit the announcement event first, while the dApp might not be ready to listen to it until later. To prevent errors, the wallet will re-trigger the announcement event after the initial one, ensuring that the dApp receives it in a timely manner.

dApp’s Event Handling

dApps must listen for the EIP6963AnnounceProviderEvent and must not remove the event listener during the page load. This ensures that the dApp can continuously listen and respond to the wallet’s announcement event during its lifecycle. After handling the announcement event, the dApp must trigger the EIP6963RequestProviderEvent to request further interaction with the wallet.

Wallet Discovery and Switching

dApps can store multiple EIP6963ProviderDetail objects for various wallets, allowing users to choose between different wallets for interaction within the dApp. This provides greater flexibility for users, allowing them to switch wallets without reloading the page.

This design achieves seamless discovery and interaction between dApps and wallets through the EIP6963AnnounceProviderEvent and EIP6963RequestProviderEvent. By using event listeners and event triggers, dApps and wallets can coordinate their actions despite indeterminate execution order, avoid race conditions, and ensure stable behavior. Furthermore, dApps can switch wallets based on user preferences, enhancing user experience and wallet interoperability.

Backward Compatibility

This EIP does not require replacing window.ethereum, meaning it will not directly break existing applications that cannot be updated to use this wallet discovery method. However, it is strongly recommended that dApps implement this EIP to ensure they can discover multiple wallet providers, and that they disable the use of window.ethereum, unless it is used as a fallback method when discovery fails. Similarly, wallet providers should maintain compatibility with window.ethereum to ensure backward compatibility with dApps that do not implement this EIP. To avoid previous namespace conflict issues, it is recommended that wallets inject their provider object into a specific wallet namespace and then proxy the object to the window.ethereum namespace.

Security Design

Prototype Pollution of Wallet Provider Object

Browser extensions, especially wallet extensions, have the capability to modify page content and provider objects, which is a core feature of their design. The provider objects of various wallets are considered highly trusted interfaces for transmitting transaction data. To prevent unintended modifications of the interaction between the dApp and wallet by the page or other extensions, the best practice is to freeze the EIP1193Provider object using Object.freeze() before the wallet dispatches the eip6963:announceProvider event. This ensures that the object cannot be modified. However, in some cases, web compatibility may require modification of this object. In such cases, wallet implementers need to strike a balance between security and web compatibility.

Wallet Forgery and Tampering

dApps should actively detect if the properties or functions of the wallet provider object have been tampered with to prevent the forgery or alteration of other wallets. One way to detect forgery is by checking if the uuid property in the two EIP6963ProviderInfo objects is consistent. dApps and their discovery libraries should consider other potential tampering methods and take additional protective measures to prevent such behavior, ensuring user security.

Preventing JavaScript Execution in SVGs

Using SVG images can lead to cross-site scripting (XSS) attacks, as SVGs can contain JavaScript code. This code executes within the page context and could potentially modify page content or affect other wallets. Therefore, when rendering icons, dApps need to consider how to handle such security risks to prevent malicious images from being used as obfuscation techniques, thereby hiding malicious modifications to the page or wallet.

Preventing Wallet Fingerprinting

One advantage of the concurrent event loop mechanism used in this design is that both the dApp and the wallet can initiate the process to announce the provider. Therefore, wallet implementers can choose whether to announce themselves to all pages or take other measures to reduce the likelihood of users being fingerprinted via the injected window.ethereum object. One possible alternative is for the wallet to delay injecting the provider object until the dApp announces the eip6963:requestProvider event. At this point, the wallet can initiate a UI consent flow, asking the user whether they are willing to share their wallet address. This approach allows the wallet to enable a “private connection” feature. However, when taking this approach, the wallet also needs to consider how to ensure backward compatibility with dApps that do not support this EIP.

Features of EIP-6963 Improvements

Simplification of Wallet Discovery Process

EIP-6963, proposed in May 2023 as a new Ethereum standard and passed in October of the same year, aims to address the lack of clearly defined standards like window.ethereum. The standard introduces a multi-injection provider discovery mechanism, allowing dApps to reliably discover and connect to all wallets installed on a user’s browser. This overcomes the limitations and conflicts presented by traditional methods. Compared to the traditional window.ethereum approach, EIP-6963 simplifies the wallet discovery process, supporting the coexistence of multiple wallet extensions in the same browser. This innovation greatly enhances the interoperability of the Ethereum ecosystem and improves the user experience.

Clear Definition and Improved User Experience

EIP-6963 is not just a functional improvement; it also enhances the recognizability of wallets and user experience by allowing wallets to inject information such as name, logo, UUID, and reverse DNS (RDNS). dApps can display this information, allowing users to clearly understand which wallet they are interacting with, thereby avoiding confusion and misoperations. This results in a clearer, more reliable, and user-friendly interface. In this way, EIP-6963 provides users with a smoother experience, reducing potential disputes and unnecessary operational difficulties, while positively contributing to the overall Ethereum ecosystem.

Potential Security Risks

The design of EIP-6963 introduces potential security vulnerabilities. By providing a list of all registered wallets, it facilitates interaction between dApps and users, but could also be misused by malicious applications. Malicious dApps might read the list of wallets installed by users, inferring their blockchain activities or asset distributions. If the service registration mechanism lacks stringent verification, malicious wallets could masquerade as legitimate service providers, tricking users into granting access and stealing assets. Therefore, additional security measures (such as user consent and registration validation) are necessary.

Complexity in User Experience

In terms of user experience, the multi-wallet support of EIP-6963, while a significant improvement, may also increase complexity. For example, after a user installs multiple wallets, the dApp may present too many options, confusing the user about which wallet to choose. Additionally, some wallets may have names or logos that are not intuitive, increasing the difficulty of identification. For users who need to switch wallets frequently, this flexibility might become a burden rather than a benefit.

Summary

EIP-6963 introduces an event-driven approach to address issues such as multi-wallet coexistence, namespace conflicts, and user privacy protection in Web3 applications, significantly improving the user experience. This standardized mechanism allows dApps to automatically discover and connect multiple wallets without manual switching, while avoiding competition and conflicts between wallets, enhancing the smoothness and stability of connections. EIP-6963 also strengthens security by freezing wallet provider objects to prevent tampering, reducing potential security risks. In terms of privacy, users can choose whether to share their wallet address, preventing identity leaks and fingerprinting. EIP-6963 maintains backward compatibility with older interfaces, ensuring a smooth transition for existing systems, while simplifying the work for dApp developers and enhancing cross-platform and multi-device support. Overall, EIP-6963 improves interoperability, security, and privacy protection in Web3 and provides developers with more efficient tools, fostering the further development of the Web3 ecosystem.