Wallet EIPs

Summary

EIP-712 defines a standard for hashing and signing typed structured data, enabling wallets to display human-readable descriptions of what a user is signing rather than a hex string. It introduces a domain separator and per-type schemas so that signatures are both human-inspectable and replay-protected across different contracts and chains.

Why it matters for wallets

Without EIP-712, wallets present users with a raw 32-byte hash to sign, giving them no indication of what they are authorizing. With EIP-712, wallets can decode and display the structured data so users can make an informed decision before signing.

Summary

A JavaScript Ethereum Provider API for consistency across clients and applications.

Why it matters for wallets

EIP-1193 defines a consistent standard for browser-extension-based Ethereum wallets to integrate with web applications. This allows web applications to interact with the wallet and the Ethereum blockchain without needing to implement wallet-specific code.

Notes

EIP-1193 has largely been superseded by EIP-6963, which provides better support for the case where the user has installed multiple Ethereum wallet browser extensions.

Summary

A standard mechanism for JavaScript Ethereum Providers to notify clients about chain state changes when both are able to interface with each other via a shared JavaScript object.

Why it matters for wallets

EIP-2700 defines a consistent standard for web applications to be notified about changes and events to the chain, such as transaction inclusions or failures. This allows web applications to interact with the wallet and Ethereum blockchain without needing to implement wallet-specific code.

Summary

ERC-4337 defines a standard for account abstraction without changes to the Ethereum protocol, relying on a separate transaction mempool that contains operations to be submitted and executed onchain by external actors ("bundlers") on behalf of transacting users.

Smart contract accounts require their own Ethereum address by definition. However, EIP-7702 builds on top of ERC-4337 by allowing non-smart-contract accounts (EOAs) to delegate their authority to smart contract accounts, extending the power of ERC-4337 to all Ethereum users.

Why it matters for wallets

ERC-4337 allows users of Ethereum to use smart contract account features without changes to the protocol. This gives users better UX and more flexibility over how their wallet is secured and recoverable, can be used to avoid needing to keep the wallet topped up with Ether to pay for gas fees, etc. See Account Abstraction for more information.

Summary

Sign-In with Ethereum describes how Ethereum accounts authenticate with off-chain services by signing a standard message format parameterized by scope, session details, and security mechanisms (e.g., a nonce). The goals of this specification are to provide a self-custodied alternative to centralized identity providers, improve interoperability across off-chain services for Ethereum-based authentication, and provide wallet vendors a consistent machine-readable message format to achieve improved user experiences and consent management.

Why it matters for wallets

ERC-4361 provides a standardized way for apps to authenticate users via wallets rather than traditional web2 login systems. Wallets supporting this standard can present a clear sign-in request details to users, improving the UX and security of signing in with a wallet.

Summary

A standard for generating stealth addresses, which allow senders to non-interactively generate private accounts exclusively accessible by their intended recipient.

Why it matters for wallets

Stealth addresses add a layer of privacy on top of otherwise-public Ether and ERC-20 token transfers.

Summary

JSON-RPC methods for sending multiple calls from the user's wallet, and checking their status.

Why it matters for wallets

EIP-5792 defines a standard way for apps to request wallets to bundle multiple operations into a single onchain transaction. This allows for better user experience for many DeFi applications. For example, this allows token approval transactions to be bundled together with the transaction that spends those tokens, all signed and executed as a single operation by the user.

Summary

An alternative discovery mechanism to EIP-1193 which supports discovering multiple injected Wallet Providers in a web page.

Why it matters for wallets

EIP-6963 defines a consistent standard for browser-extension-based Ethereum wallets to integrate with web applications. This allows web applications to interact with the wallet and the Ethereum blockchain without needing to implement wallet-specific code.

Notes

EIP-6963 has largely superseded EIP-1193, as it provides better support for the case where the user has installed multiple Ethereum wallet browser extensions.

Summary

Smart contract accounts require their own Ethereum address by definition. EIP-7702 builds on top of ERC-4337 by allowing non-smart-contract accounts (EOAs) to delegate their authority to smart contract accounts, extending the power of ERC-4337 to all Ethereum users.

EIP-7702 allows wallets to submit a special type of transaction which sets the smart contract code that acts on behalf of the user's account, effectively delegating control of the account to the smart contract without requiring the user's address to change.

Why it matters for wallets

EIP-7702 allows users of Ethereum to use smart contract account features with minimal changes to the protocol. This gives users better UX and more flexibility over how their wallet is secured and recoverable, can be used to avoid needing to keep the wallet topped up with Ether to pay for gas fees, etc. See Account Abstraction for more information.

Summary

ERC-7730 defines a standard JSON descriptor format for structured calldata, enabling wallets to display human-readable descriptions of smart contract calls. Instead of showing raw hex calldata, wallets that implement ERC-7730 can show decoded function names and parameters in plain language. For example, "Approve 100 USDC for Aave" instead of the raw 0x095ea7b3... bytes.

Why it matters for wallets

Without calldata decoding, users must trust that the signing prompt correctly represents the transaction they intended to authorize, a significant attack surface. ERC-7730 allows wallets to independently display what a transaction actually does so users can confirm function names, amounts, and addresses before signing.

Summary

Chain-specific address format that allows specifying both an account and the chain on which that account intends to transact. Chain-specific addresses take the form of user@chain.eth. The target chain is resolved using a registry stored on ENS.

Why it matters for wallets

This address format ensures Ethereum addresses specify the chain of the recipient. This fits well in Ethereum's layer-2 roadmap to reduce user errors such as accidentally sending funds on the wrong chain, and for wallets to automatically bridge funds to the intended destination chain.

Summary

Chain-specific address format that allows specifying both an account and the chain on which that account intends to transact. Chain-specific addresses take the form of user.eth:l2chain. The target chain is resolved using a registry stored on ENS.

Why it matters for wallets

This address format ensures Ethereum addresses specify the chain of the recipient. This fits well in Ethereum's layer-2 roadmap to reduce user errors such as accidentally sending funds on the wrong chain, and for wallets to automatically bridge funds to the intended destination chain.

Summary

ERC-8213 standardizes the terminology and display requirements for cryptographic digests that wallets show to signers. It defines the terms:

• EIP-712 Digest: keccak256("\x19\x01" || domainSeparator || hashStruct(message)) — the value that is ultimately signed.
• Calldata Digest: keccak256(uint256(len(calldata)) || calldata) — a compact, chain-agnostic fingerprint of the transaction payload.

For EIP-712 signing, wallets SHOULD display at least the EIP-712 Digest (or Domain Hash + Message Hash together). For transactions with calldata, wallets SHOULD display the Calldata Digest as a 0x-prefixed hex string.

Why it matters for wallets

Recent high-profile exchange compromises showed that users cannot safely rely on a website's description of what they are signing, if the signing interface is compromised, the description can be spoofed while the actual payload is malicious. ERC-8213 gives signers a way to independently verify the exact bytes they authorize by comparing a short digest against a trusted external source, without needing to parse raw hex character-by-character.