Frontend, web3 libraries, and wallet developers have been pushed to constantly maintain and update their code, applying overly intricate workarounds due to a flaw in the Ethereum protocol for wallet-dapp communication.
Where does it start?
Wallet extensions communicate with frontend applications by injecting a javascript object, called “Provider”, into web pages. EIP-1193 is a standard protocol that defines the structure of said provider, which simplifies the communication between websites and wallets, allowing decentralized applications to easily interact with the blockchain regardless of the wallet that the user is using.
However, there is one part of the communication process that this EIP does not specify: Where should wallets inject their providers?
Where are wallets injecting their providers?
At present, the prevailing method used for wallets to inject their providers is window.ethereum, but this unwritten standard has brought some problems to the ethereum ecosystem.window.ethereum only permits to inject one provider at a time. This limitation causes inconsistent and unpredictable connection behaviors when having and using multiple wallet extensions simultaneously. Thus, wallets try to fight for their place in this communication channel, leaving the users without any control, and being the winner the last wallet to load its injection.
With this current convention, most dapps expect wallets to inject their provider into the window.ethereum method. This makes it impossible for new wallets to choose their own namespaces, making it significantly difficult for them to gain widespread adoption.
…it’s not the library, it’s not the dapp, it’s not the wallet, it’s the protocol.
How do we solve this?
One of the first attempts to solve this was the creation of EIP-5749, which would propose to replace window.ethereum with window.evmproviders to allow for the interoperability of multiple browser wallets at the same time.
Unfortunately, this EIP wasn’t widely adopted due to a lack of agreements.
A new solution arrived later, EIP-6963, which proposes a discovery mechanism for providers using Javascript’s window events. A promise to improve the UX and remove race conditions in case multiple wallet extensions are installed. So wallets would announce themselves by emitting an event and sending their providers through it, this way no wallet would be left behind.
There is still a lot of room for improvement in terms of protocols, EIP-6963 represents a significant step forward for it and the end of the wallets war!
EIP-6963 Dapp Example by WalletConnect (WIP):
https://github.com/WalletConnect/EIP6963
source:
https://eips.ethereum.org/EIPS/eip-1193
https://eips.ethereum.org/EIPS/eip-5749
https://eips.ethereum.org/EIPS/eip-6963
