Finding and connecting wallet to dApp
Stable specification; check network and product support
Open for peer review; implementation support varies
Inactive proposal development; check implementation support separately
ERC-681 defines a URI grammar for transaction requests that a compatible wallet may parse into editable payment or contract-call fields. It can carry a recipient, optional chain_id, amount, and function parameters, but the format does not require wallets to scan, deep-link, or support every parameter.
Category: Onboarding & Access
EIP-695 defines the eth_chainId RPC method, which lets a provider report the chain ID used by the connected endpoint. A client can compare that value with its target network, while wallet support, endpoint trust, network names, and switching remain separate concerns.
Category: Comprehension & Display
EIP-1193 defines a transport-agnostic Provider API for dApps: request methods, provider events, and standard error shapes. It gives applications a common wallet communication surface, but it does not require window.ethereum, make every RPC method available, or guarantee that every wallet supports every dApp feature.
ERC-1328 defines how WalletConnect connection data is encoded in a wc: URI that can be shown as a QR code or link. The URI carries versioned connection parameters such as keys, relay data, methods, and optional expiry. A compatible app and wallet still need to support the selected protocol version, transport, session flow, and fallback behavior.
EIP-2255 standardizes wallet_getPermissions and wallet_requestPermissions so a wallet can expose a permission model and caveats for a dApp. It supports progressive consent when the selected wallet implements the requested permission methods; it does not require a revocation RPC, expiry field, or common management UI.
EIP-5749 defines a window.evmproviders object containing injected EIP-1193 providers plus display metadata for enumeration. A client may build a wallet picker from the object, but wallet support is uneven and the announced name, icon, and key are metadata rather than proof of identity or capability.
EIP-6963 lets multiple injected wallets announce an EIP-1193 provider without competing for one selected connection. A dApp can show a wallet picker using the announced info.name and info.icon fields; rdns is a self-attested identifier, not proof of wallet identity or feature support.
ERC-7828 defines a human-readable chain-aware name format and ENS chain resolution. Applications can use the resolved chain context to prompt a user to switch networks, while routing and wallet switching remain application behavior with explicit user consent.
Category: Cross-Chain
EIP-3085 defines wallet_addEthereumChain, a request for a wallet to validate and add an EVM chain. The Stagnant specification requires chain-ID and RPC-URL validation and recommends explicit user consent. Wallets control additional metadata requirements and post-add selection; current implementations such as MetaMask Connect document their own confirmation and error behavior.
EIP-3326 defines wallet_switchEthereumChain, a request for a wallet with an active-chain concept to switch to a known chain. The specification is Stagnant and recommends explicit confirmation and cancellation of chain-specific pending work; implementation details, supported chains, and error handling remain wallet-specific.
Category: Transaction Friction
