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.ethereumshould 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.