Today is a big day for the wallet ecosystem: EIP-6963 is now final! After an extensive review process, this Ethereum Improvement Proposal has now received the green light to become a community-wide standard.

We’re celebrating here at WalletConnect, not only because we were heavily involved in EIP-6963 but because it addresses one of our core goals — the continuous improvement of web3 UX. Let’s explore the problem that it solves and its implications for the future crypto experience.

EIP-6963: What is it and what problem does it solve?

If you’re like me and have multiple browser extension wallets installed, you already know — today’s browser extension wallet user experience is extremely poor. Getting the one you want to open can often require fiddling around with your browser wallet installations, with plenty of confusing connection behavior along the way.

This is because while there was a standard — EIP-1193: Ethereum Provider JavaScript API — for connecting different wallets (browser, mobile, hardware, and so forth) from different providers, there was no standard for discovering when a browser wallet was installed. Previously, it was common practice to inject the browser wallet into a singular JavaScript object, window.ethereum. However, this made it so that it was impossible to inject multiple providers into the same JavaScript object.

With just a single channel, a winner-takes-all race condition is created in the event that there are two or more browser extension wallets installed. When this is the case, the user exercises zero control over which wallet provider is selected under the window.ethereum object when attempting to connect to an app. It used to be that if you only used one extension-based Ethereum wallet, you might not have this problem; but as many other wallets are starting to enable “EVM-mode,” they are increasingly clashing and overwriting this prized real estate in each user’s browser. If you’re interested in reading more about the browser extension wallet wars, take a look at this explanation from WalletConnect Devrel Glitch.

The consequences of this unpredictable connection experience are numerous. Even if users want multiple wallets for privacy, security, or use-case-specific reasons, unpredictable UX might scare them off installing additional wallets. This stagnates innovation, which is critically important given that we are still so early and need to significantly improve web3 UX if mainstream adoption is a shared goal.

What EIP-6963: Multi Injected Provider Discovery does is propose an alternative discovery mechanism to window.ethereum that enables the discovery of multiple injected wallet providers. In essence, it creates a new channel of communication between apps and browser extension wallets that allows for multiple browser extension wallets to coexist. Over this more secure and expressive channel, multiple installed wallets can make themselves available to dapps and even other web-based apps.

This eliminates the previous conflicts, while also enabling wallets to inject more information, such as the wallet name, logo, UUID, and RDNS. This new, additional information then allows apps to automatically display the wallet’s name and logo in their UI, bringing not just user choice but stability, clarity, and predictability across contexts.

Who supports EIP-6963 — and how can you?

Along the way to EIP-6963 achieving final status today, 16 wallets and libraries (like wagmi!) have already tested it, with many quietly releasing support in advance of approval and others soon to follow.

This is because EIP-6963 is a true community effort, with co-authors from wallets and the ecosystem at large heavily involved in its creation and refinement. In fact, just one month after the first draft was written, Enkrypt and Zerion hit production with their support, while Brave and MetaMask had staging apps testing their implementations.

If you’re a browser extension wallet, adopting EIP-6963 is extremely easy. All you have to do is follow the specifications from the EIP-6963 proposal.

As of today, the wallets that already support and are on track to support EIP-6963 are:

• Enkrypt
• Zerion
• Brave
• Phantom
• xDEFI
• OKX
• TokenPocket
• Bitski
• Rainbow
• Frontier
• Spot
• Talisman
• Trust
• MetaMask: October 12
• Coinbase Wallet: October 16

EIP-6963: What’s next?

While today’s massive milestone concludes the journey of getting this EIP approved, it also marks a new era — the end of browser extension wallet wars! To experience what EIP-6963 brings to the table, play around on eip6963.org, which was built by WalletConnect Developer Relations Engineer Boidu.

Getting EIP-6963 off the ground was a true community effort. I’d like to thank my fellow co-authors Kosala Hemachandra, Richard Moore, Gregory Markou, Kyle Den Hartog, Glitch, Jake Moxey, Pierre Bertet, Darryl Yeo, and Yaroslav Sergievsky, as well as @bumblefudge and Boidu for their contributions to moving this proposal forward to success. Thanks to the EIP-6963 team, we can finally move forward in building better UX.