Cowrie Research

eip-1193-primary-sources-2026-05-07

3 min read

EIP-1193 primary sources — 2026-05-07

Project status in this pass

  • No standalone EIP-1193 whitepaper or litepaper surfaced.
  • The clearest current source of truth was the final EIP itself, supplemented by the raw spec text and current MetaMask provider documentation.
  • The sources consistently frame EIP-1193 as the baseline injected-wallet provider interface that many later wallet and account-abstraction standards assume rather than replace.

Primary-source snapshots

1) Canonical EIP page

  • URL: https://eips.ethereum.org/EIPS/eip-1193
  • Key excerpt/signals:
    • The summary calls it “A JavaScript Ethereum Provider API for consistency across clients and applications.”
    • The abstract says wallets historically exposed conflicting provider interfaces and behaviors.
    • It says the API is minimal, event-driven, and agnostic of transport and RPC protocol.
  • Why it mattered:
    • This is the clearest evidence that EIP-1193 belongs in the corpus as baseline wallet-interface infrastructure rather than as a specific product integration.

2) Raw EIP text / core API shape

  • URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-1193.md
  • Key excerpt/signals:
    • The provider MUST implement request(args) as the common RPC wrapper.
    • The provider MUST implement on and removeListener with Node.js EventEmitter semantics.
    • The spec requires standardized lifecycle and state events including connect, disconnect, chainChanged, accountsChanged, and message.
  • Why it mattered:
    • This is the strongest evidence that EIP-1193 compresses many earlier wallet-specific APIs into one common interface surface.

3) Raw EIP text / error and permission boundary

  • URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-1193.md
  • Key excerpt/signals:
    • The provider error table standardizes 4001 (user rejected), 4100 (unauthorized), 4200 (unsupported method), 4900 (disconnected), and 4901 (chain disconnected).
    • The text recommends 4100 for authorization failures.
    • The security section recommends not exposing accounts by default and instead using explicit account-access methods such as eth_requestAccounts and wallet_requestPermissions.
  • Why it mattered:
    • This is the clearest signal that EIP-1193 standardizes the wallet boundary but does not remove wallet discretion over permissions, method support, or user-approval flows.

4) Raw EIP text / window.ethereum is not the standard

  • URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-1193.md
  • Key excerpt/signals:
    • The abstract says providers have historically been made available as window.ethereum, but that convention is not part of the specification.
  • Why it mattered:
    • This matters for mechanism analysis because it separates the provider interface from the legacy single-global injection pattern that later standards like EIP-6963 try to repair.

5) MetaMask provider API docs

  • URL: https://docs.metamask.io/metamask-connect/evm/reference/provider-api/
  • Key excerpt/signals:
    • The docs say the MetaMask Ethereum provider API follows the EIP-1193 standard.
    • They document the same request method and the same major events.
    • They note MetaMask supports EIP-6963 and recommend selecting the provider through the EIP-6963 discovery flow where possible.
  • Why it mattered:
    • This is useful adoption evidence that a major wallet treats EIP-1193 as the common provider substrate while layering newer discovery behavior on top.

Working conclusion

EIP-1193 is best cataloged as Ethereum’s baseline injected-wallet interface standard: it makes provider behavior legible enough for dapps and libraries to target a common API, while leaving practical authority over permissions, connectivity, and feature exposure in the wallet layer above it.

Graph View