EIP-6963 Explained: How Dapps Discover Multiple Browser Wallets

You click Connect Wallet, but the dapp opens the wrong browser extension—or shows only one of several wallets you installed. That awkward result is often a provider-discovery problem, not a problem with your keys. EIP-6963 wallet discovery gives compatible dapps a standard way to find multiple injected wallets and let you choose among them. It belongs in your crypto wallet security toolkit because choosing the intended provider is the first checkpoint before any account request or signature.

Educational only, not financial advice (NFA). EIP-6963 improves wallet discovery; it does not verify a wallet, dapp, transaction, or token. Check the site and extension yourself, read every request, use only funds you can afford to lose, and do your own research (DYOR).

What EIP-6963 Solves

Browser wallets expose a provider: a JavaScript interface through which a dapp can request accounts, read chain state, or ask for a signature. EIP-1193 defines the common Ethereum provider API. Historically, injected extensions competed for one shared doorway, window.ethereum.

Think of an office building with several delivery companies but only one unlabeled service bell. The company that wires itself to the bell last may receive every call. A visitor cannot reliably choose the courier they intended. With multiple wallet extensions loading in an unpredictable order, the same kind of race can leave a dapp talking to an unexpected provider.

EIP-6963 is a Final, Standards Track Interface that adds a discovery mechanism based on browser window events. Each compatible wallet can announce itself separately. The dapp can collect those announcements and present a wallet chooser rather than treating one mutable global object as the only answer.

The standard does not replace EIP-1193. It discovers EIP-1193 providers. Nor does it require legacy window.ethereum support to disappear immediately; the specification recommends keeping a fallback for compatibility.

How the Request-and-Announce Flow Works

The design uses two event names:

1. The dapp registers a listener for eip6963:announceProvider.
2. The dapp dispatches eip6963:requestProvider after that listener is ready.
3. Every compatible wallet hears the request and dispatches its own announcement.
4. The dapp stores the distinct provider details and shows the available choices.
5. When you select one, the dapp uses that wallet's EIP-1193 provider for later requests.

Wallets also announce themselves when their injected code loads. They keep listening for later request events and announce again when asked. This two-way loop handles either load order: the dapp might initialize first, or a wallet extension might initialize first.

It resembles a roll call. The organizer first opens the attendance sheet, then asks everyone present to identify themselves. Anyone who arrived earlier answers again, so the organizer does not depend on hearing an announcement made before the sheet existed.

Discovery is not connection. Receiving a provider announcement should not reveal your accounts, authorize a dapp, or sign anything. A later account-access request and every later signature remain separate wallet decisions.

What a Wallet Announces

An EIP-6963 announcement contains the EIP-1193 provider plus an info object with four required fields.

Field	Purpose	Important limit
uuid	Distinguishes provider sessions during the page lifetime	It is a session identifier, not a wallet's security certificate
name	Supplies a human-readable wallet name	Display text can be imitated
icon	Supplies a data-URI image for the chooser	Untrusted SVG content needs safe rendering through an image element
rdns	Supplies a reverse-domain-style wallet identifier	It is self-attested and must not be treated as proof of identity

The UUID must follow UUIDv4 so two announcements can be distinguished even when other properties match. The reverse-DNS value is intended to stay stable across sessions, while the UUID identifies a particular provider session. They solve different problems.

The official specification explicitly warns that rdns, names, and icons can be invalid or imitated. A polished wallet row in a connection modal is therefore a label, not an authenticity guarantee.

What Changes for Wallet Users

On a compatible site, the practical improvement is simple: installing several injected wallets should no longer force them into a winner-takes-all contest for the connection button. You can be shown the available providers and select the intended one.

That choice is useful, but verify it in layers:

1. Check the dapp origin. Open the official domain from a trusted bookmark or independently verified source.
2. Check the extension. Confirm that the installed wallet came from its official publisher and browser-store listing.
3. Choose deliberately. Match the wallet name and icon to the extension you intended, but do not rely on those labels alone.
4. Check the active account and network. After choosing a provider, confirm the address and chain shown in both the dapp and wallet.
5. Read the next prompt. Discovery does not make an account request, login message, approval, or transaction safe.

If a dapp still opens the wrong extension, it may be using the legacy path, one extension may not support the standard, or stale site permissions may be affecting the flow. Do not disable wallet protections just to force a connection. Close the request, verify the site, review connected-site permissions, and use the wallet's official troubleshooting documentation.

Security and Privacy Limits

Wallet imitation is still possible

EIP-6963 organizes announcements; it does not create an authenticated registry of wallet brands. A malicious extension can attempt to imitate another provider's name, icon, or reverse-DNS value. Dapps should detect suspicious duplicate data and handle malformed announcements defensively. Users should treat browser-extension installation as a separate trust decision.

Provider objects live in an untrusted page

EIP-1193 tells implementers to treat provider objects as if they are exposed to an adversarial environment. EIP-6963 recommends freezing discovery details to reduce unexpected mutation, but notes a compatibility trade-off for pages or tools that patch provider objects. A standard interface is not a sandbox.

Icons are untrusted input

The icon arrives as a data URI. Because SVG can contain JavaScript, the specification requires dapps to render SVG wallet icons through an <img> element rather than injecting the SVG markup into the page. Developers must still validate and display provider metadata carefully.

Discovery can contribute to fingerprinting

A page that learns which wallet extensions are installed gains another signal about your browser setup. The specification discusses wallets waiting for an explicit provider request and potentially asking for consent before announcing as one privacy-oriented approach. Support and behavior can vary, so do not assume discovery is invisible.

Correct discovery does not mean safe signing

After selecting the right wallet, a malicious dapp can still ask for a dangerous approval or deceptive signature. Use clear-signing checks, verify contracts and spenders, and reject any outcome you cannot explain.

EIP-6963 vs Wallet Connection and Login

These steps are easy to blur together, but they answer different questions.

Step	Question answered	What it does not prove
Provider discovery	Which compatible wallet providers are available?	That any provider or site is trustworthy
Account connection	Which address may the dapp access?	Ownership for an authenticated server session
SIWE login	Does this address approve this login challenge?	Permission to spend tokens
Transaction or message signing	Does the account authorize this specific payload?	That the requested outcome is beneficial or safe

Keeping those boundaries clear prevents a common mental shortcut: “I chose the correct wallet, so the next prompt must be fine.” Each prompt needs its own review.

Frequently Asked Questions

Is EIP-6963 final?

Yes. The official EIP repository lists EIP-6963 as Final and classifies it as a Standards Track Interface. That describes the specification's status; it does not mean every wallet or dapp implements it.

Does EIP-6963 replace window.ethereum?

No. It provides an alternative discovery method for EIP-1193 providers. The specification recommends EIP-6963 for multi-wallet discovery while retaining legacy behavior as a fallback during the compatibility transition.

Does wallet discovery expose my address?

The provider announcement carries provider metadata and an interface, not your account list. Account access is a separate request. The installed-wallet set itself can still be a fingerprinting signal.

Can I trust the wallet name and icon in a chooser?

Not as proof. The metadata is supplied by the provider and can be imitated. Verify the extension's source, the dapp domain, the selected account, and every subsequent request.

Is EIP-6963 only for MetaMask?

No. It is an Ethereum interface standard for multiple injected providers. MetaMask's developer documentation identifies EIP-6963 and EIP-1193 as browser-extension discovery standards, but the interface is not brand-specific.

The Practical Takeaway

EIP-6963 replaces an ambiguous single bell with a roll call: compatible wallets announce distinct providers, and a dapp can let you choose. That is a meaningful interoperability improvement and a cleaner first step in the connection flow.

It is still only the first step. Verify the site and extension, confirm the account and network, and inspect every login, approval, message, and transaction independently. This guide is educational, not financial advice. Crypto and self-custody can involve total loss; use only funds you can afford to lose and DYOR.

Sources

• EIP-6963: Multi Injected Provider Discovery
• EIP-1193: Ethereum Provider JavaScript API
• MetaMask Connect developer documentation