A Javascript Ethereum Provider interface injection that will allow for the interoperability of multiple browser wallets at the same time. Replacing window.ethereum with window.evmproviders is a simple solution that will provide multiple benefits including: improving user experience, encouraging innovation in the space, removing race conditions and a 'winner-takes-most' environment as well as lowering barriers for user adoption.
At present, window.ethereum is the prevailing method by which Ethereum-compatible applications interact with injected wallets. This originated with Mist Wallet in 2015 to interact with other applications. With the proliferation of both applications and wallets, window.ethereum has unintended negative consequences:
window.ethereum only permits one wallet to be injected at a time, resulting in a race condition between two or more wallets. This creates an inconsistent connection behavior that makes having and using more than one browser wallet unpredictable and impractical. The current solution is for wallets to inject their own namespaces, but this is not feasible as every application would need to be made aware of any wallet that might be used.window.ethereum standard hinders innovation because it creates a barrier to adoption. New entrants into the space have difficulty gaining traction against legacy players because users can have no more than one injected wallet. With new entrants crowded out, legacy wallet providers are put under little pressure to innovate.window.ethereum as of August, 2022. Currently a user will have inconsistent behavior if they use multiple of these wallets in a single browser.
Replacing window.ethereum with window.evmproviders will allow solutions such as web3modal and web3onboard to display all injected wallets the user has installed. This will simplify the UX and remove race conditions between wallet providers in case multiple wallets are installed. Over time, as window.evmproviders supplants the current standard and removes barriers to choice, we can hope to see a wallet landscape more reflective of user preference.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
window.evmproviders={}Type EIP1193Provider is documented at EIP-1193
Standardizing a ProviderInfo type allows determining the necessary information to populate a wallet selection popup. This is particularly useful for web3 onboarding libraries such as Web3Modal, Web3React, and Web3Onboard.
The name evmproviders was chosen to include other EVM-compliant chains.
The SVG image format was chosen for its flexibility, lightweight nature, and dynamic resizing capabilities.
This EIP doesn't require supplanting window.ethereum, so it doesn't directly break existing applications. However, the recommended behavior of eventually supplanting window.ethereum would break existing applications that rely on it.
The security considerations of EIP-1193 apply to this EIP.
The use of SVG images introduces a cross-site scripting risk as they can include JavaScript code. Applications and libraries must render SVG images using the <img> tag to ensure no JS executions can happen.
Copyright and related rights waived via CC0.