# EIP-1193: Ethereum Provider JavaScript API

Source: https://www.eipsfordesigners.com/standards/EIP-1193
Agent brief: https://www.eipsfordesigners.com/standards/EIP-1193/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-1193
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Onboarding & Access |
| Journey stages | Discovery & Connection |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-1193 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-1193 |

## UX Impact

Users interact with dApps through a standardized wallet JavaScript API — all wallets expose the same request/response pattern. Design implications: build one connection flow that works with any EIP-1193 wallet, handle standard error codes (4001 for user rejection, 4100 for unauthorized, 4900 for disconnected) with consistent error messaging, listen for accountsChanged and chainChanged events to update UI state automatically. Design decisions: decide whether to show explicit 'connecting' vs 'connected' states, handle network switching prompts gracefully, consider how to surface RPC errors in human-readable form without exposing technical details.

## Summary

EIP-1193 is the "Connect Wallet" standard. It defines how websites talk to browser wallet extensions like MetaMask. Every dApp that shows a connect button uses this — it specifies the window.ethereum object, how to request accounts, and how to send transactions. Without this standard, every wallet would need custom integration code.

## For Designers

- You can use one Connect Wallet pattern that works across MetaMask-class extensions.
- You can react to account and network switches with clear reconnect or warning states.
- You can pair EIP-1193 with EIP-6963 so users pick among multiple injected wallets.

## Applicability

### When to Use

- Web apps need a standard Connect Wallet flow with browser extensions.
- You listen for accountsChanged and chainChanged to keep UI in sync.
- You show truncated addresses or ENS names after connection.

### When to Avoid

- Mobile-only flows use WalletConnect with no window.ethereum.
- Embedded wallets hide provider choice entirely.
- You trigger eth_requestAccounts on page load without user action.

## Problems It Solves

### No standard way for dApps to communicate with wallets

Impact: critical

Old way: Each wallet invented their own API, dApps wrote custom code for each

New way: Standard window.ethereum interface works with any wallet

### Users couldn't use their preferred wallet

Impact: high

Old way: dApp only supports MetaMask? Too bad for Coinbase Wallet users

New way: Any EIP-1193 wallet works with any dApp

### Inconsistent connection experience

Impact: high

Old way: Different buttons, flows, and errors for each wallet

New way: Standard "Connect Wallet" flow everywhere

## Anti-Patterns

### Auto-connecting without user action

Severity: critical

Privacy violation, users didn't consent to share address

Instead: Always require explicit "Connect" click first

### Not handling account/chain changes

Severity: high

User switches account in wallet, dApp still shows old one

Instead: Listen to accountsChanged and chainChanged events

### Showing full 42-character addresses

Severity: medium

Unreadable, wastes space, looks intimidating

Instead: Truncate: 0x7a3...f9c2 or show ENS name

## Design Decisions

### When do you call eth_requestAccounts?

Recommendation: Trigger on explicit Connect Wallet click, not on page load.

Rationale: Surprise wallet popups erode trust and increase rejection rates.

### How do you map provider errors?

Recommendation: Map 4001, 4100, 4900, and 4901 to consistent, human-readable messages.

Rationale: Raw error codes are meaningless to designers and users alike.

### What happens on chain change?

Recommendation: Pause actions and prompt reload or auto-refresh contract-dependent state.

Rationale: Stale chain state causes wrong balances and failed transactions.

### How is the connected account shown?

Recommendation: Truncated address, network name, and a clear disconnect control.

Rationale: Users must always know which identity and chain the app is using.

## States to Design

### No provider

Trigger: window.ethereum is missing (no extension).

User need: Install or choose a wallet path.

Design response: Explain install steps; link to WalletConnect or mobile if supported.

### Disconnected

Trigger: User has not approved eth_requestAccounts.

User need: Start the session safely.

Design response: Primary Connect Wallet CTA; no gated content that requires guessing.

### Connected

Trigger: Accounts array non-empty.

User need: See active address and network.

Design response: Account chip with network badge and disconnect.

### User rejected (4001)

Trigger: User closes wallet prompt without approving.

User need: Retry without feeling blocked.

Design response: Neutral copy: "Connection cancelled" with retry button.

### Wrong network

Trigger: chainId does not match app requirement.

User need: Switch network or understand mismatch.

Design response: Block actions; offer Switch network when wallet supports it.

## UI Components

### ConnectWalletButton

Primary CTA for initiating wallet connection
States: idle, connecting, connected, error
Props: onConnect, onDisconnect

### AddressPill

Truncated address with optional ENS
States: address-only, with-ens, loading
Props: address, ensName, onClick

### NetworkBadge

Shows current connected network
States: mainnet, testnet, unknown, wrong-network
Props: chainId, expectedChainId

## On Monad

### Provider Interface

Ethereum: window.ethereum is the standard

Monad: Same interface, different chainId

Design implication: Works identically, just detect Monad chain

## Key Takeaways

- EIP-1193 = the "Connect Wallet" standard
- Never auto-connect without user action
- Listen for account and chain change events
- Truncate addresses or show ENS names
- Handle connection errors gracefully

## UX Patterns

### Connect Wallet Button

The ubiquitous entry point to web3

User flow:

- User sees Connect Wallet button
- Click triggers eth_requestAccounts
- Wallet popup asks for permission
- User approves connection
- dApp receives account address

Mockup registry key: `concept/wallet` (React UI on the live standard page).

### Connected State

Show connected wallet with truncated address

User flow:

- User connected successfully
- Show truncated address
- Display network name
- Provide disconnect option

Mockup registry key: `concept/wallet` (React UI on the live standard page).

## Technical Notes

EIP-1193 defines a Provider interface with request() method for JSON-RPC calls. Standard methods: eth_requestAccounts (connect), eth_accounts (get connected), eth_chainId (get network). Events: accountsChanged, chainChanged, connect, disconnect. The provider is typically injected as window.ethereum.