Cowrie Research

eip-6963

3 min read

EIP-6963

  • Name: EIP-6963 (Multi Injected Provider Discovery)
  • URL: https://eips.ethereum.org/EIPS/eip-6963
  • Category: Ethereum wallet-discovery standard / multi-injected-provider coordination layer / anti-lock-in interface infrastructure
  • Tags: ethereum-ecosystem
  • Summary: EIP-6963 is best understood as wallet discovery coordination infrastructure rather than as a wallet feature checklist. Its core move is to replace the old window.ethereum winner-take-all discovery pattern with an event-based protocol that lets multiple injected EIP-1193 providers announce themselves on the same page. The mechanism significance is that EIP-6963 tries to shift wallet choice away from extension load-order races and toward explicit dapp-side wallet selection, reducing one form of wallet-vendor lock-in while creating a new soft-power layer around provider metadata, wallet-selection UIs, and discovery libraries.
  • What it does:
    • Defines an event-based discovery flow for multiple injected EIP-1193 wallet providers on one page
    • Adds eip6963:announceProvider and eip6963:requestProvider window events so wallets and dapps can discover each other regardless of load order
    • Standardizes provider metadata through uuid, name, icon, and reverse-DNS (rdns) fields
    • Lets dapps persist multiple discovered providers and present explicit wallet-choice interfaces instead of relying on a single overwritten global provider
    • Keeps compatibility with legacy window.ethereum usage while recommending EIP-6963-first discovery where available
    • Warns that provider metadata is partly self-attested and should not be used as a trusted capability-detection mechanism
  • Key claims:
    • The final EIP says its purpose is to support discovering multiple injected wallet providers using window events, which is the clearest reason to treat it as wallet-discovery coordination infrastructure rather than a vendor-specific UX tweak
    • The motivation section says browser extension load order is unpredictable and the last wallet to write window.ethereum usually wins, identifying the exact anti-competitive race condition the standard is trying to neutralize
    • The spec requires wallet providers to announce themselves and re-announce when a dapp dispatches a request event, which turns discovery into a bidirectional handshake rather than a fragile singleton namespace grab
    • The EIP6963ProviderInfo object standardizes uuid, name, icon, and rdns, which gives dapps enough metadata to build wallet selectors while still leaving branding and identity claims partially self-attested
    • The RDNS section explicitly says dapps should not use rdns for feature detection because it is prone to impersonation or bad incentives, which matters because EIP-6963 improves choice without fully solving wallet verification trust
    • The security section discusses provider-object freezing, wallet imitation, SVG execution risk, and fingerprinting, showing that discovery portability creates a new security surface rather than removing trust problems outright
    • The backwards-compatibility section recommends using EIP-6963 discovery first and treating window.ethereum as fallback, which means the standard aims to re-order wallet power at the integration layer without breaking older dapps overnight
    • MetaMask’s current provider docs explicitly recommend using EIP-6963 to connect to MetaMask and describe it as the preferred multi-wallet discovery mechanism, which is a strong adoption signal that the standard is becoming the default discovery path for major browser-wallet integrations
  • Whitepaper: No standalone EIP-6963 whitepaper or litepaper surfaced in this pass. The clearest current sources were the final EIP, the raw spec text, and current MetaMask provider documentation collected in ../../whitepapers/eip-6963-primary-sources-2026-05-07.md.
  • Sources:

Internal linkages

  • Best direct comparison points: eip-1193 and wallet-standard.

  • Keep the note on event-based provider discovery and selector power. It is not a session rail, not a custody surface, and not a generic wallet index.

  • Last reviewed: 2026-06-02 UTC

Graph View

Backlinks