Cowrie Research

eip-1193

3 min read

EIP-1193

  • Name: EIP-1193 (Ethereum Provider JavaScript API)
  • URL: https://eips.ethereum.org/EIPS/eip-1193
  • Category: Ethereum wallet-provider baseline standard / injected-wallet interface / permission-and-error-surface infrastructure
  • Tags: ethereum-ecosystem
  • Summary: EIP-1193 is best understood as the baseline compatibility layer for Ethereum browser wallets rather than as a wallet product or a generic RPC spec. Its core move is to standardize the JavaScript provider object that wallets expose to web apps: one request(...) method, a small event model, and a shared error vocabulary. The mechanism significance is that EIP-1193 makes wallets portable enough for dapps and libraries to target a common interface, while still leaving real control over account exposure, method support, chain connectivity, and permission prompts in the wallet layer.
  • What it does:
    • Standardizes a minimal JavaScript provider interface for Ethereum wallets and dapps
    • Defines a transport-agnostic request({ method, params }) call for RPC access instead of wallet-specific method surfaces
    • Defines common provider lifecycle and state events including connect, disconnect, chainChanged, accountsChanged, and message
    • Establishes a shared provider error vocabulary including user rejection, unauthorized access, unsupported methods, and chain-disconnect cases
    • Explicitly treats window.ethereum as a historical convention rather than the standard itself
    • Leaves higher-level permissioning and capability surfaces to other methods and standards such as eth_requestAccounts and wallet_requestPermissions
  • Key claims:
    • The final EIP says it formalizes an Ethereum Provider API because wallet implementations had conflicting interfaces and behaviors, which is the clearest reason to treat it as baseline interoperability infrastructure rather than a single-wallet integration guide
    • The abstract says the API is minimal, event-driven, and agnostic of transport and RPC protocol, showing that EIP-1193 is intentionally a narrow compatibility layer rather than a full wallet framework
    • The spec requires a single request(...) method and says returned promises must resolve with method-specific results instead of protocol-specific wrapper objects, which compresses many older wallet quirks into one stable integration shape
    • The provider error table standardizes codes like 4001, 4100, 4200, 4900, and 4901, which matters because wallets still control the permission boundary but now expose denial and connectivity outcomes in a comparable way
    • The event model requires chainChanged and accountsChanged, making wallet state changes first-class application inputs rather than ad hoc wallet-specific callbacks
    • The EIP explicitly says window.ethereum is not part of the specification, which is important because the standard is about interface portability, not about blessing one global singleton namespace forever
    • The security section says the provider should be treated as though it is controlled by an adversary and recommends explicit account-access requests, which makes clear that the provider is an exposed wallet boundary in an untrusted environment, not a neutral browser primitive
    • MetaMask’s current provider docs say their provider follows EIP-1193 and expose the same request-and-events model, which is a useful signal that the standard became the common implementation substrate for major wallet integrations
  • Whitepaper: No standalone EIP-1193 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-1193-primary-sources-2026-05-07.md.
  • Sources:

Internal linkages

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

  • Keep the note on the provider boundary itself: one request method, a shared event model, and a common error surface after discovery. It is not the discovery spec and not the session rail.

  • Last reviewed: 2026-06-02 UTC

Graph View

Backlinks