Getting users into web3 without friction
Stable specification; check network and product support
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.
Stages: Discovery & Connection
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.
Stages: Discovery & Connection, Approving & Permissioning
ERC-2771 defines a contract-level protocol for recipients that accept meta-transactions through trusted forwarders. A gas relay may submit a signed request and pay gas, but gasless interaction requires a recipient integration, trusted-forwarder verification, an available relay, and any sponsor policy the product chooses.
Stages: Executing Transactions, Gas & Fees
ERC-4361 defines a Sign-In with Ethereum (SIWE) message that a relying party can ask a wallet to sign. The signature proves control of the address for that message at signing time. The server still validates the domain, URI, chain ID, nonce, time bounds, and session policy before authenticating the user.
Stages: Authentication & Identity
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.
ERC-6492 defines a signature wrapper that lets a verifier validate a counterfactual smart-account signature by simulating its factory deployment when the account is not yet deployed. A compatible wallet, factory, verifier, and account implementation are still required; the wrapper does not create a universal wallet or authentication flow.
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.
EIP-7951 defines native P-256 (secp256r1) signature verification. That primitive can support passkey-compatible smart-account designs when an account and wallet implement WebAuthn, authenticator, and recovery flows. It does not itself provide a universal wallet, biometric onboarding, synced recovery, or never-extractable platform key. Monad lists native P256VERIFY support under MONAD_FOUR; verify account and provider support separately.
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.
Stages: Discovery & Connection, Executing Transactions
