window.ethereum and the Standards That Built Web3.

How EIP-1193, EIP-6963, EIP-4337, EIP-7702, and x402 all connect

If you’ve ever clicked “Connect Wallet” on a website, you’ve already used window.ethereum — even if you didn’t know it. That one line of JavaScript is the entry point to everything in the Ethereum browser ecosystem: connecting wallets, sending transactions, signing messages, and increasingly, powering AI agents that pay for APIs without any human in the loop.

But window.ethereum doesn’t work in isolation. A stack of Ethereum Improvement Proposals (EIPs) defines how it behaves, what it can do, and where it’s going. This article walks through all of them — not as isolated specs, but as a connected story of how the web3 stack evolved and where it’s heading.

1. What is window.ethereum?

When you install MetaMask (or Coinbase Wallet, Rabby, or any other browser wallet), the extension quietly injects a JavaScript object into every page you visit. That object lives at window.ethereum — a global variable your web app can read and use.

Think of it as a bridge. On one side is your web app — plain HTML and JavaScript. On the other side is the Ethereum network. window.ethereum connects them without your app ever needing to handle private keys, run a node, or deal with low-level blockchain internals.

A simple check to see if one is available:

if (typeof window.ethereum !== 'undefined') {
console.log('A wallet is installed!');
} else {
console.log('No wallet found. Ask user to install one.');
}

That’s literally all it takes to detect a wallet. Everything else — connecting accounts, sending transactions, signing data — flows through this single object. The question is: what rules govern how it works? That’s where the EIPs come in.

2. EIP-1193 — the rulebook for window.ethereum

Before EIP-1193, every wallet had its own API. MetaMask used one pattern, other wallets used different ones, and developers had to write messy compatibility code just to connect a wallet. EIP-1193 fixed this by defining a single, clean interface that every provider must follow.

The core rule is simple: window.ethereum must expose a request() method that takes a JSON-RPC call and returns a Promise. That’s the whole foundation.

Connecting a wallet

const accounts = await window.ethereum.request({
method: 'eth_requestAccounts'
});
console.log('Connected:', accounts[0]);
// 0xYourWalletAddress

Calling eth_requestAccounts triggers the wallet popup asking the user to approve the connection. Once approved, you get their address. Simple.

Listening for changes

EIP-1193 also defines events. When the user switches accounts or changes their network, your app can react immediately:

window.ethereum.on('accountsChanged', (accounts) => {
if (accounts.length === 0) {
console.log('Wallet disconnected');
} else {
updateUI(accounts[0]);
}
});
window.ethereum.on('chainChanged', (chainId) => {
console.log('Network changed to:', chainId);
window.location.reload(); // common practice
});

In plain terms: EIP-1193 is the contract that makes window.ethereum predictable. Any wallet that follows it will work with any dApp that follows it — no compatibility shims needed.

3. EIP-6963 — what happens when two wallets are installed?

EIP-1193 standardised the interface, but it left one practical problem unsolved: what if a user has both MetaMask and Coinbase Wallet installed? Both extensions try to inject into window.ethereum, and they overwrite each other. The last one to load wins — which is random and unreliable.

EIP-6963 fixes this with a different approach. Instead of fighting over window.ethereum, each wallet broadcasts itself through a custom browser event:

const wallets = [];
// Listen for wallet announcements
window.addEventListener('eip6963:announceProvider', (event) => {
wallets.push(event.detail);
console.log('Found wallet:', event.detail.info.name);
// e.g. 'MetaMask', 'Coinbase Wallet'
});
// Ask all installed wallets to announce themselves
window.dispatchEvent(new Event('eip6963:requestProvider'));

Now your dApp receives all available wallets and can show the user a picker — a much better experience than silently picking one at random.

How it relates to window.ethereum: EIP-6963 doesn’t replace window.ethereum — it adds a discovery layer on top of it. Once the user picks a wallet, you still use window.ethereum (or the chosen provider’s equivalent) to make calls.

4. EIP-4337 — what if the wallet itself was a smart contract?

The first three entries (window.ethereum, EIP-1193, and EIP-6963) are all about the browser-to-wallet interface. EIP-4337 goes deeper — it rethinks what a wallet fundamentally is.

The old model: externally owned accounts (EOAs)

A standard Ethereum wallet is what’s called an Externally Owned Account (EOA). It’s essentially a public/private key pair. It works, but it has hard limitations:

• Every transaction must be directly signed by the private key
• Gas fees must always be paid in ETH
• No custom logic — no spending limits, no 2-of-3 multi-sig, no automatic approvals
• Lose the key? The account is gone forever

EIP-4337: smart contract accounts

EIP-4337 introduces Account Abstraction — the ability to use a smart contract as your wallet. Instead of a raw private key, your account is a contract with custom logic you define.

The mechanism works through a new object called a UserOperation — a bundle of intent that describes what you want to do:

// A UserOperation (simplified) looks like this:
{
sender: '0xYourSmartWalletAddress',
callData: '0x…', // what you want to execute
paymasterAndData: '0x…', // who pays the gas (optional)
signature: '0x…' // your authorisation
}

UserOperations are collected by special actors called Bundlers, who package them into real transactions and submit them on-chain. The key innovation: your dApp doesn’t need to change. It still calls window.ethereum — the smart wallet’s provider handles the UserOperation layer transparently.

What this unlocks

• Gas sponsorship — a third party (called a Paymaster) covers the gas so users pay nothing
• Pay gas in ERC-20 tokens like USDC instead of ETH
• Batch multiple actions into a single transaction
• Session keys — grant a dApp limited, time-boxed permissions without a pop-up every time
• Social recovery — recover your wallet using trusted contacts instead of a seed phrase

Real example: A gaming dApp sponsors gas for new players — they play for free, no ETH required. The dApp uses a Paymaster via EIP-4337, and the player’s wallet is a smart contract account. From the player’s perspective, they just clicked ‘Play’.

5. EIP-7702 — upgrading your existing wallet, not replacing it

EIP-4337 is powerful, but it has friction: to use a smart contract wallet, you’d traditionally need to deploy a new contract, migrate your assets to a new address, and explain all this to your users. EIP-7702 solves that.

Introduced as part of Ethereum’s Pectra upgrade, EIP-7702 lets an ordinary EOA wallet temporarily delegate its behaviour to a smart contract — without changing address.

How it works

With EIP-7702, a regular MetaMask wallet can sign a special transaction (type 0x04) that says: “For this operation, behave like this smart contract.” The delegation is transaction-scoped — it doesn’t permanently change the wallet.

// EIP-7702 delegation (conceptual)
// The EOA signs an authorisation to delegate to a smart contract
{
type: '0x04',
authorizationList: [{
address: '0xSmartContractLogicAddress', // the contract to delegate to
nonce: 1,
chainId: 1,
// signed by the EOA's private key
}]
}

Why this matters

The result is that an ordinary user’s existing wallet — same address, same assets — can suddenly do smart wallet things: batch transactions, pay gas in USDC, use session keys. No migration required.

The difference from EIP-4337: EIP-4337 deploys a new smart contract account. EIP-7702 upgrades your existing EOA in place. They’re complementary — 7702 is often described as the on-ramp that lets existing users access 4337’s capabilities without friction.

6. x402 — payments at the HTTP layer

This is where things get genuinely exciting — and where the entire stack below it becomes critical infrastructure.

The original HTTP 402

When the web was being designed in the early 1990s, HTTP reserved a status code for payments: 402 Payment Required. It was intended to enable paid content on the internet. It was never implemented. Servers mostly used it as a placeholder. For thirty years, 402 sat unused, waiting.

x402 brings it to life

x402, launched by Coinbase in May 2025, finally implements 402. The protocol is elegantly simple:

• Your client (browser app, AI agent, script) makes a normal HTTP request to a resource
• The server responds with 402 Payment Required plus details of what payment is needed
• The client signs a payment authorisation using its wallet (following EIP-712)
• The client resends the request with a X-PAYMENT header containing the signed payload
• The server verifies the payment on-chain and returns the resource

// Simplified x402 client flow
let response = await fetch('https://api.example.com/data');
if (response.status === 402) {
const paymentDetails = await response.json();
// Sign the payment using the wallet
const payment = await signPayment(paymentDetails); // uses window.ethereum
// Retry with payment header
response = await fetch('https://api.example.com/data', {
headers: { 'X-PAYMENT': payment }
});
}
const data = await response.json();

Why x402 is a big deal

x402 enables a new category of internet interactions. Specifically, it makes micropayments native to HTTP — no subscription, no login, no payment form. Just a signed header and a resource.

This is especially important for AI agents. An autonomous agent browsing the internet can now pay for API access, buy data, or unlock content — programmatically, without a human approving each transaction. The agent just needs a wallet.

Connection to the full stack: x402 signs payments using EIP-712. In a browser, that signing goes through window.ethereum. For agents, it uses embedded or server-side wallets. EIP-4337 and EIP-7702 make those wallets programmable — agents can batch payments, have gas sponsored, or operate with session-scoped keys.

7. How they all fit together

Here’s the full picture as a layered stack — each standard builds on the one below it:

Let’s trace a real interaction through the whole stack to make it concrete.

Scenario: A user visits a DeFi app. They have MetaMask and Coinbase Wallet installed. They want to swap USDC for ETH, with gas paid in USDC. The dApp also fetches price data from a paid API using x402.

• EIP-6963 detects both wallets and shows a picker. The user chooses MetaMask.
• EIP-1193 defines how the app calls eth_requestAccounts to connect and get the address.
• EIP-7702 lets the MetaMask EOA temporarily behave as a smart contract for this transaction.
• EIP-4337 allows the swap to be batched with a USDC approval in one click, with gas paid in USDC via a Paymaster.
• x402 lets the app’s backend fetch live price data from a paid API by signing a micropayment — the cost is fractions of a cent, invisible to the user.

The user sees one transaction, one click, no ETH for gas. Every layer of the stack did its job invisibly.

8. Quick reference

window.ethereum The JavaScript object injected by wallet extensions.The entry point for all browser-to-blockchain calls.

EIP-1193 Defines the window.ethereum interface: a request() method and an event emitter. The universal contract between wallets and dApps. EIP-6963 Fixes multi-wallet conflicts by letting wallets announce themselves via events instead of overwriting window.ethereum.

EIP-4337 Account Abstraction. Lets users have smart contract wallets with programmable logic: sponsored gas, batched transactions, session keys, social recovery.

EIP-7702 Gives existing EOA wallets smart contract capabilities without migration. Part of Ethereum’s Pectra upgrade.

x402 Implements HTTP 402 for crypto micropayments. Enables any HTTP client (browser, AI agent, script) to pay for resources with a signed header.

Closing thought

window.ethereum started as a narrow slot in the browser — a way to reach a wallet. What’s remarkable is how much of web3’s current momentum runs through that one object, or the standards layered around it.

EIP-1193 made it reliable. EIP-6963 made it work with multiple wallets. EIP-4337 and EIP-7702 made the wallets themselves programmable. And x402 is now using all of it as a payment rail for the open web — including autonomous AI agents that can pay for APIs the same way a browser loads an image.

The next time you click ‘Connect Wallet’, you’re touching the bottom of a stack that’s being actively built upward. It’s still early — but the foundation is solid.

References

1. EIP-1193: Ethereum Provider JavaScript API
2. EIP-6963: Multi Injected Provider Discovery
3. EIP-4337: Account Abstraction via Entry Point Contract
4. EIP-7702: Set EOA account code
5. x402 Protocol — Coinbase
6. EIP-712: Typed structured data hashing and signing — Pectra Upgrade Overview (ethereum.org)