EIP-5749: The 'window.evmproviders' object

Hey @kvhnuke, I’m from the Coinbase Wallet team. What’s the status on this EIP? We’re very supportive of this idea and would be happy to support.

hey @jmcho
thank you for the support!
we are getting it merged to Last Call! https://github.com/ethereum/EIPs/pull/6018

First, off I want to thank the author for taking the time to try and address this concern. I believe this is a legitimate problem so it’s good that we’re taking the time to find a solution. However, I don’t think the way in which this is being done right now by shoving an EIP through the process is a good solution that will lead to actually solving the problem personally. In fact, I think it stands to cause additional harm and it’s only through coordination between a large number of wallet providers (beyond just the Ethereum ecosystem too) that will lead to solving this problem.

I’ll note 7 concerns I have with this current EIP:

  • This proposal as it stands pollutes the global namespace further
  • It doesn’t assign a specified date that window.ethereum should be expected to be deprecated
  • This is highly EVM specific when numerous wallets are moving to a multichain approach.
  • It only recommends a method for assigning keys in order to distinguish different chains.
    • What’s to stop another wallet from intentionally prototype polluting other keys in order to stop other wallets from being used?
    • How will a web3modal style library know that the key is associated with the appropriate wallet?
  • It doesn’t address fingerprinting concerns that would arise from websites being able to uniquely identify users based on the unique assortment of wallets they support.
  • It doesn’t comment in the security considerations section about how prototype pollution attacks are expected to be prevented here if a malicious wallet wanted to modify a transaction before it got sent to the wallet in order to
  • It doesn’t address compatibility concerns with other related EIPs such as EIP-5593 or CASA’s approach with CAIP-25

For these reasons Brave does not intend to support this at this point. From my understanding some other large wallets are also hesitant to support this too and will chime in here shortly. As it stands this proposal has not gathered appropriate consensus, has been rushed through the entire EIP status in under 2 months, and will create a greater fracture in wallet compatibility for the web3 ecosystem that will limit their ability to interoperably work with multiple wallets. By this I mean dApps will now have to question whether they should support window.evmprovider along with window.ethereum, window.solana, window.web3 if they’re a multichain dApp like Opensea.

At this point, I’d hardly consider this a “standard” as there’s not been appropriate discussion to confirm interopability, make sure time has been given for wallets to review this and provide feedback, and address legitimate concerns with this approach. At best, it’s a documentation of a direction “a few major wallets and major web3 onboarding libraries” have decided to go without appropriately gathering consensus. Looking at this thread so far it’s basically just been a discussion between the Author (@kvhnuke) and @MicahZoltu with one other wallet (coinbase - @jmcho) expressing support for it.

If this is the minimum bar that EIP editors feel is necessary in order to upgrade this EIP to the “final call” status that impacts interoperablity for the entire Ethereum and web3 ecosystem and delegitimizes the entire organisational process of EIPs and shows that EIPs are not intended to be for “gathering consensus and shipping code”. Is that really what we’re looking to achieve here?

Let’s slow down, properly alert other wallets to this EIP, get them to provide feedback, address concerns to gain consensus on an approach together and find a solution to this problem.

1 Like

Speaking for MetaMask, I second the reservations put forth by @kdenhartog / Brave, and we also have no intention of implementing this standard as written. While the problems noted by the EIP authors are real, we believe that injected providers are fundamentally flawed, and we should seek to abandon that practice and window.ethereum entirely. We encourage all wallets to invest our collective resources in provider standards that support non-EVM chains and do not rely on injection, such as CAIP-25 and its related standards (WIP).

In addition to @kdenhartog’s points, we oppose this EIP in its current form because:

  • Extensions must possess extremely broad powers over every webpage in the user’s browser in order to inject a script tag. The Google Chrome team recently fixed a bug such that it is now possible for an extension to receive messages from any webpage using chrome.runtime.connect and/or .sendMessage. This makes it relatively straightforward to abandon injection entirely, which is what MetaMask intends to do.
    • See the externally_connectable permission in the Chrome extensions documentation for more details. Valid matches patterns now includes http://*/* and https://*/*.
  • The EIP does not specify who will maintain the namespace for wallets, or in what manner they will do so.

Solving the problem of injection race conditions is fundamentally a social coordination problem for wallets. While this standard could help facilitate that coordination, we don’t believe that laying claim to another global name is the solution. We should instead invest our energies in provider standards that avoid injection entirely.

All of the above said, in the process of writing my objection, it does strike me that this EIP could be more palatable with some modifications. Rather than adding a property to window, we could define a property of window.ethereum that serves the same purpose as window.evmproviders, perhaps simply window.ethereum.providers. This would be pretty ugly, but so is window.ethereum itself, and this ought to be completely non-disruptive for both dapps and wallets. I’m curious what to hear what the authors, @kdenhartog, and others have to say about this idea.