EIP 6963 & the future of Ethereum Wallets
Consensys developed Metamask, the pioneer in browser wallets, back in 2016. Following that, developers created a series of wallet extensions during the last bull cycle. Few mentionable are Trust, WalletConnect, Zerion, Rainbow, Phantom, Talisman, Brave, Coinbase and more. Each wallet targeted different blockchain communities and use cases. Some of them supported multi-chain operations too.
Why The Need?
If you have been a Crypto Enthusiast and a Blockchain supporter you might have found yourself in a place where you have to use 2 or more wallets in your browser. Maybe to get an Airdrop or any other reason. Here is where EIP-6963 comes into play. EIP-6963 is all about streamlining Ethereum wallet providers. And enhancing the UI experience of Users.
EIP-1193
To understand the impact and importance of EIP-6963 we have to look into its predecessor EIP-1193. It outlines a method to how a DApp and Wallet will connect. Wallets will inject into a function called window.ethereum to load into a DApp. Here comes a race condition issue where the last one to load usually wins.
Check out this article on flashbots!
What’s the Issue?
This race condition hinders the user experience. If you have 2 or more wallets in the browser you would have experienced this issue that you can’t get to load the wallet which you want. Instead of a predictable outcome, the system either selects a random wallet or the wallet that wins the race condition. More often, you disable an extension from the Chrome extension manager, and then your favorite wallet connects with the DApp.
EIP-6963
To tackle this issue, a new EIP came to work. It aims to optimize the interoperability of multiple Wallet Providers. This solution aims to foster fairer competition by reducing the barriers to entry for new Wallet Providers, along with enhancing the user experience on Ethereum networks. Basically the decision to use a specific wallet lies in the user’s hands now. DApps will list the wallets which are present in the browser and user will be able to interact by his choice.
Working
Each Wallet Provider will be announced with the following interface EIP6963ProviderInfo
/**
* Represents the assets needed to display a wallet
*/
interface EIP6963ProviderInfo {
uuid: string;
name: string;
icon: string;
rdns: string;}| Uuid | Unique Identification Id |
| Name | Your Wallet Name |
| Icon | Your awesome Icon in svg 96×96 |
| Rdns | Domain Name System in reverse syntax ordering such as com.example.subdomain |
DApps and the Wallet are expected to emit an event and instantiate an eventListener to discover the various Wallets.
The DApp MUST listen for the EIP6963AnnounceProviderEvent dispatched by the Wallet via a window.addEventListener() method. EIP-6963 is backward compatible and doesn’t hinder if the wallets are still under consideration to upgrade or don’t want to upgrade.
Implementation
Wallet Side
DApp Side
Security Considerations
1. Prototype Pollution of Wallet Provider objects
Prototype pollution is a JavaScript vulnerability that enables an attacker to add arbitrary properties to global object prototypes, which may then be inherited by user-defined objects. Browser extensions, and therefore Wallet extensions, are able to modify the contents of the page and the Provider object by design. Wallets are considered to be a trustful source hence there’s a tradeoff that needs to be made between security and web compatibility that Wallet implementers are expected to consider.
2. Wallet Imitation and Manipulation
Since Wallets can specify the UUID and Svg in the EIP6963ProviderInfo, there is a great possibility of wallet’s imitation and impostring. DApps are expected to look for this behaviour and make sure that in case of UUID duplication proper sanitization steps are followed to not interact with imposter DApps.
3. Prevent SVG Javascript Execution
Since Wallets can pass SVG in EIP6963ProviderInfo, there is a possibility of Cross Site Scripting via SVG images. Javascript executes within the context of the page and can therefore modify the page or the contents of the page. DApps are expected to apply sanitization techniques on prevention of such executions via SVG images.
4. Wallet Fingerprinting
Wallet providers can now consider whether or not they wish to announce themselves to all pages or attempt alternative means in order to reduce the ability for a user to be fingerprinted by the injection of the window.ethereum object. An example, of an alternative flow to consider would be to wait to inject the provider object until the DApp has announced the eip6963:requestProvider. At that point, the wallet can initiate a UI consent flow to ask the user if they would like to share their wallet address. This allows for the Wallet to enable the option of a “private connect” feature.
Final Thoughts
Overall EIP-6963 is going to be a game changer in the user’s experience of interacting with DApps and it will allow new players to come into the wallet space and have a fair chance of competing with other wallets. The security considerations should be kept in mind while racing towards the newer implementation and often security is neglected to be the one to implement the newer things.
