Recently proposed EIP-6963 aims to provide a solution to the issue of conflicts that arise when users attempt to use multiple wallet providers within a single web browser. In such cases, these conflicting wallets can lead to degraded user experience, impede user control over their Ethereum interface, and complicate the process of interacting with dApps. The original docs can be found here: https://eips.ethereum.org/EIPS/eip-6963
Introduction to the Problem
Currently, wallet providers offering browser extensions must inject their Ethereum providers (as per EIP-1193 standards) into the window.ethereum object of the browser. This mechanism presents a challenge for users who have installed multiple browser extensions. Browser extensions are loaded onto a webpage in an unpredictable and unstable order, leading to a race condition where the user lacks control over the choice of the wallet provider that controls the Ethereum interface under the window.ethereum object. The wallet provider that loads last is usually the one that controls the interface.
EIP-6963: A Proposed Solution
To address this issue, EIP-6963 proposes an alternative discovery mechanism to window.ethereum for EIP-1193 providers. The proposal introduces a set of window events that enable a two-way communication protocol between Ethereum libraries and injected scripts provided by browser extensions. This solution optimizes the interoperability of multiple wallet providers, reducing barriers to entry for new wallet providers and improving the user experience on Ethereum networks.
The proposal outlines a standardized provider info interface (EIP6963ProviderInfo), which is crucial for populating a wallet selection pop-up. It also emphasizes the importance of the announced provider interface (EIP6963ProviderDetail), which leaves the EIP-1193 provider interface untouched for backwards compatibility.
The key attributes in the provider info interface are:
- walletId: A globally unique identifier of the wallet provider (e.g., io.dopewallet.extension or awesomewallet).
- uuid: Locally unique identifier of the wallet provider, compliant with UUID v4.0.
- name: A human-readable name of the wallet provider (e.g., DopeWalletExtension or AwesomeWallet).
- icon: A URI pointing to an image, which should be square with a minimum resolution of 96x96px. PNG and WebP or alternatively vectorial like SVG are recommended. The proposal team strongly discourages lossy formats like JPG/JPEG.
In terms of events, both Ethereum libraries and wallet providers use the window.dispatchEvent function to emit events and window.addEventListener to observe events. When the Ethereum library initializes, it emits the "eip6963:requestProvider" event, while the wallet provider emits the "eip6963:announceProvider" event, along with details of its provider interface and info.
Impact of EIP-6963
The acceptance and implementation of EIP-6963, according to optimistic estimates, should take approximately three to six months. This development could bring about a new wave of wallet narratives towards the end of the year, potentially disrupting the hegemony of leading wallet providers like Metamask and fostering a more competitive environment among providers. Wallets like Coin98, Coinbase Wallet, Trust Wallet, Phantom, Taho, Rabby, Frame, XDEFI, Rainbow, Zerion, Spot, Frontier, MEW, Dawn Wallet, Blockwallet, Bitski, SafePal, BitKeep, and MathWallet stand to gain from this development.
Read more: EIP 6551
Read more: EIP 6551
Pros and cons:
EIP-6963 presents several security implications that should be considered.
Pros of EIP 6963
- No single point of failure: By allowing for multiple wallet providers, we eliminate the issue of a single point of failure. This is beneficial in terms of security as it means that if one wallet provider suffers from an attack or technical failure, there are alternatives available to users.
- Reduced reliance on a single provider: Currently, the Ethereum community is heavily reliant on a single provider, MetaMask. This creates a potential risk because if MetaMask were ever compromised, a large portion of Ethereum users would be affected. By supporting multiple wallets, EIP-6963 decentralizes the risk.
- Enhanced user control: The ability to choose between multiple wallet providers allows users to have greater control over their own security. Users can select a wallet provider that aligns with their individual security preferences and trust levels.
Cons of EIP 6963
- Increased attack surface: With the implementation of EIP-6963, there is an increased attack surface. This is due to the greater number of wallet providers that can potentially be targeted by malicious actors. It's important that each wallet provider adheres to high-security standards to minimize this risk.
- Potential for SVG Image exploitation: The EIP-6963 proposes the use of SVG images as icons for the wallet providers. However, SVG images can potentially contain JavaScript code which may pose a cross-site scripting (XSS) risk. Although the EIP does specify that SVG images should be rendered using the <img> tag to prevent JavaScript execution, but this recommendation could only be verified by 3rd party or auditor in each implementation.
- Implications of supplanting window.ethereum: Although the EIP doesn't directly break existing applications by supplanting window.ethereum, it recommends doing so once the user has selected a wallet. This recommendation could only be verified by 3rd party or auditor in each implementation.
Conclusion
EIP-6963 aims to enhance the interoperability of multiple wallet providers, reduce the barriers to entry for new providers, and improve the user experience on Ethereum networks. Also, the implications for security are mixed. It’s imperative that users, wallet providers, and Ethereum library developers adhere to best practices to ensure the Ethereum ecosystem remains secure. By implementing this proposal, the Ethereum ecosystem could move towards a more user-friendly and competitive environment for both wallet providers and their users. Feel free to reach out to us for smart contract audit consulting.