Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-5749: Move to Review #5912

Merged
merged 3 commits into from
Nov 13, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 14 additions & 8 deletions EIPS/eip-5749.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ title: The 'window.evmproviders' object
description: Add 'window.evmproviders' and suggest the eventual removal of 'window.ethereum'
author: Kosala Hemachandra (@kvhnuke), Brett Kolodny (@brettkolodny)
discussions-to: https://ethereum-magicians.org/t/eip-5749-deprecate-window-ethereum/11195
status: Draft
status: Review
type: Standards Track
category: Interface
created: 2022-10-04
Expand All @@ -13,15 +13,17 @@ requires: 1193


## Abstract

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, and lowering barriers to user adoption.

## Motivation

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.
- The aforementioned race condition means users are disincentivized to experiment with new wallets. This creates a 'winner-takes-most' wallet market across EVM chains which forces application developers to optimize for a particular wallet experience.
- The 'winner-takes-most' wallet environment that results from the `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.
- Wallets continue to be the most fundamental tool for interacting with blockchains. A homogeneous wallet experience in Ethereum and EVM chains risks stunting UX improvement across the ecosystem and will allow other ecosystems that are more encouraging of competition and innovation to move ahead.
- Wallets continue to be the most fundamental tool for interacting with blockchains. A homogeneous wallet experience in Ethereum and EVM chains risks stunting UX improvement across the ecosystem and will allow other ecosystems that are more encouraging of competition and innovation to move ahead.
- Some wallets that currently use `window.ethereum` as of August, 2022. Currently a user will have inconsistent behavior if they use multiple of these wallets in a single browser.
- Metamask
- Coinbase wallet
Expand All @@ -32,6 +34,7 @@ At present, `window.ethereum` is the prevailing method by which Ethereum-compati
Replacing `window.ethereum` with `window.evmproviders` will allow solutions such as web3modal and web3onboard to only display all injected wallets the user has installed. This will simpify 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.

## Specification

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={}`
Expand Down Expand Up @@ -79,17 +82,19 @@ key is RECOMMENDED to be the name of the extension
By adopting an object for EIP-1193 compliant providers we can have multiple different ethereum/evm compatible wallets coexists in the same browser. This will prevent race conditions and inconsistent behaviors.

## Rationale
By introducing `ProviderInfo` type web onboarding libraries such as

By introducing `ProviderInfo` type web onboarding libraries such as
Web3Modal
Web3React
Web3Onboard
can easily grab the necessary information to populate their popup window to choose the wallet.
can easily grab the necessary information to populate their popup window to choose the wallet.

The name `evmproviders` was chosen in order to be inclusive of other evm-compliant chains.
The name `evmproviders` was chosen in order to be inclusive of other evm-compliant chains.

**data:image/svg+xml;** svg data uri was chosen since it is easier to be modified if the application requires for example different size for the image.
**data:image/svg+xml;** svg data uri was chosen since it is easier to be modified if the application requires for example different size for the image.

## Backwards Compatibility

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.


Expand All @@ -111,9 +116,10 @@ const allproviders = Object.values(window.evmproviders)

## Security Considerations

The security considerations of EIP-1193 apply for this EIP.
The security considerations of EIP-1193 apply for 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 make sure no JS executions can happen.
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 make sure no JS executions can happen.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).