A brief analysis of EIP-6963, a solution to multi-wallet conflicts

Written by: Mundus Security
Compiled by: TechFlow
Recently proposed EIP-6963 aims to address conflicts that arise when users attempt to use multiple wallet providers in a single web browser. In this case, these conflicts can lead to a degraded user experience, hindering users’ control over their Ethereum interface and complicating the process of interacting with dApps.
Problem Introduction
Currently, wallet providers that offer browser extensions must inject their Ethereum provider (per the EIP-1193 standard) into the browser's window.ethereum object. This mechanism creates a problem for users who have multiple browser extensions installed. Browser extensions are loaded into web pages in an unpredictable and unstable order, resulting in users being unable to independently select the Ethereum wallet in the window.ethereum object. Typically, the last wallet loaded is the one that pops up the control page.
EIP-6963: Proposed Solution
To address this issue, EIP-6963 proposes an alternative to the existing EIP-1193 provider for window.ethereum. The proposal introduces a set of window events that enable a two-way communication protocol between the Ethereum library and the injected scripts provided by the browser extension. This solution optimizes interoperability between multiple wallet providers, lowers the entry barrier for new wallet providers, and improves the user experience on the Ethereum network.
The proposal outlines a standardized provider information interface (EIP6963ProviderInfo), which is essential for populating the wallet selection popup. It also emphasizes the importance of declaring the provider interface (EIP6963ProviderDetail), which keeps the EIP-1193 provider interface unchanged for backward compatibility.
Key properties in the provider information interface include:
walletId: A globally unique identifier for the wallet provider (e.g., io.dopewallet.extension or awesomewallet). uuid: A locally unique identifier for the wallet provider that complies with UUID v4.0. name: A human-readable name for the wallet provider (e.g., DopeWalletExtension or Awesome). icon: A URI pointing to an image, which should be a square with a minimum resolution of 96x96px. It is recommended to use PNG and WebP or vector image formats like SVG. The proposal team strongly discourages the use of lossy formats like JPG/JPEG.
In terms of triggering events, both the Ethereum library and the wallet provider use the window.dispatchEvent function to emit events and use window.addEventListener to observe events. When the Ethereum library is initialized, it emits the "eip6963:requestProvider" event, while the wallet provider emits the "eip6963:announceProvider" event, providing details of its provider interface and information.
Impact of EIP-6963
According to optimistic estimates, the acceptance and implementation of EIP-6963 may take about three to six months. This development may bring about a new wallet story by the end of the year, potentially breaking the hegemony of leading wallet providers like Metamask and creating a more competitive environment among providers.
Wallets such as Coin98, Coinbase Wallet, Trust Wallet, Phantom, Taho, Rabby, Frame, XDEFI, Rainbow, Zerion, Spot, Frontier, MEW, Dawn Wallet, Blockwallet, Bitski, SafePal, BitKeep, and MathWallet are expected to benefit from this development.
 pros and cons:
EIP-6963 raises some security issues that need to be considered.
advantage:
No single point of failure: By allowing multiple wallet providers, we eliminate the problem of single points of failure. This is beneficial in terms of security because it means that if one wallet provider suffers an attack or technical failure, users have alternative options available. Reduced reliance on a single provider: Currently, the Ethereum community relies heavily on one provider, MetaMask. This poses a potential risk because if MetaMask is hacked, a large portion of Ethereum users will be affected. By supporting multiple wallets, EIP-6963 spreads the risk. Increased user control: The ability to choose multiple wallet providers gives users greater control over their security. Users can choose a wallet provider that aligns with their personal security preferences and trust level.
shortcoming:
Increased Attack Surface: Implementing EIP-6963 increases the attack surface. This is due to the increase in the number of wallet providers that can be attacked by malicious actors. Each wallet provider should adhere to high security standards to minimize this risk. Potential Risk of SVG Image Exploitation: EIP-6963 proposes to use SVG images as icons for wallet providers. However, SVG images may contain JavaScript code, which may pose a cross-site scripting (XSS) risk. While the EIP does specify that SVG images should be rendered using the tag to prevent JavaScript execution, this recommendation can only be verified by a 3rd party or auditor of each implementation. Impact of Replacing window.ethereum: While the EIP does not directly break existing applications by replacing window.ethereum, it recommends doing so after the user has selected a wallet. This recommendation can only be verified by a 3rd party or auditor in each implementation.
 
 in conclusion
EIP-6963 aims to enhance interoperability between multiple wallet providers, lower the entry barrier for new providers, and improve the user experience on the Ethereum network. At the same time, the impact on security is complex.
Users, wallet providers, and Ethereum library developers must adhere to best practices to ensure that the Ethereum ecosystem remains secure.
By implementing this proposal, the Ethereum ecosystem can move towards a more user-friendly and competitive environment, benefiting both wallet providers and their users.