EIP-6963: Multi Injected Provider Discovery

EIPs EIPs interfaces
21

I am curious, why are we not using window.evmproviders , coupled with a great frontend library, EIP5749 can be a better solution

Adding to what Pedro said, the initial idea of using events was to make sure no wallet was left behind since there might be a delay until the injection happens. This is currently managed by individual wallet events or a setTimeout (which isn’t ideal).

I also agree that evmproviders seems more fragile and easier to break. Regarding the iframe security concern, I think we could add an advise on the security considerations section about sandboxing any iframe used in the website. At least on the dapp side the issue will persist whether we use events, window.ethereum, postMessage or anything that’s attached to the window object.

If I’m not mistaken, sandboxing the iframe, as long as the allow-same-origin flag is not there, will prevent the iframe from overwriting the window object.

22

Hey everyone, me and Boidushya from WalletConnect collaborated on an example dapp that supports EIP-6963

It will detect any EIP-6963 compatible browser wallet and display them. Plus you can connect multiple in parallel and it will display the chain and the accounts

But since there aren’t any in production, we added a button to “emulate” window.ethereum as EIP-6963 provider by wrapping it into an announceProvider event

App available at https://eip6963.org/

Source code available here: GitHub - WalletConnect/EIP6963: A web application showcasing the implementation and usage of EIP-6963 for Multi Injected Provider Discovery

2 Likes
23

Why not using a standardised window postMessage call, which any extension can answer if it wants:

1 Like
24

Also the word “wallet” should not be used in the standard. the assumption that every crypto browser extension is wrong. blockchain based account systems can be anything but a wallet. See UniversalProfiles for example. Yes it can be a wallet, but it’s a lot more than that.

Maybe extensionId is better:

interface EIP6963ProviderInfo {
  extensionId: string;
  uuid: string;
  name: string;
  icon: string;
}

Or even appId

1 Like
25

The use of window.postMessage was already considered but it would completely break EIP-1193 with little benefit.

But I would definitely consider renaming the walletId param to something more generic… maybe providerId?

1 Like
26

Enkrypt chrome,opera and safari are live with 6963 if anyone wants to give it a shot

Make sure you goto https://eip6963.org it should automatically detect it

2 Likes
27

Enkrypt and Zerion extensions connecting simultaneously with EIP-6963 :rocket:

https://twitter.com/pedrouid/status/1666767785991577606

28

Hey Authors of EIP-6963, congrats on a successful twitter space advocating more adoptions.

We are starting a recurring virtual meetup for ERC authors and dApp builders to meet and talk to each other, advocate for adoption and / or give tech feedback. And we would like to invite you to come over to give a sharing on allercdevs. The event occurs bi-weekly and rotates between two timezone friendly slots, for information go to GitHub - ercref/AllERCDevs: Meeting Repository for AllERCDevs

Next sessions are 3rd session (Tuesday 2023-06-13 UTC2300) and 4th session (Thursday 2023-06-29 UTC1500)

29

We just merged one last PR that improves the wording for EIP-6963 regarding image requirements for the Wallet icon to be squared

The adoption is also growing nicely every day on the Wallet side… counting already with 12 wallets supporting it in production

Screenshot 2023-10-05 at 16.08.01
Screenshot 2023-10-05 at 16.08.011328×1916 135 KB

I’ve prepared the PR on Github to move EIP-6963 from “Last Call” to “Final” status on Tuesday 10 Oct 2023

Great progress all around :raised_hands:

30

I’d like to propose one last name change:

“Event-Driven Discovery of Wallet Providers”

I’d also like to tighten up the terminology being used. EIP-6963 is all about the relationship between “Dapps” and “Wallet Providers”. I want to make sure this is reflected clearly throughout the spec.

Check out my proposed changes here: