Proving who you are and logging in
Stable specification; check network and product support
Open for peer review; implementation support varies
ERC-55 encodes a checksum in the capitalization of an EVM address. A client that validates the checksum can catch many accidental edits, although checksum-valid text is not proof that the recipient is correct and all-lowercase or all-uppercase input needs separate handling.
Category: Comprehension & Display
ERC-137 defines the ENS registry and resolver model for looking up records such as an address for a registered name. A compatible client can resolve a name like alice.eth and show the resulting address, but registration, ownership, resolver support, network scope, and client display remain separate checks. A name does not make typos obvious or prove identity by itself.
ERC-181 provides reverse ENS records that suggest a name for an address. Before showing that name as identity, forward-resolve it and require it to match the original address on the intended network. If the lookup is missing, fails or mismatches, display the address instead.
ERC-191 defines an envelope for signed data with a version byte and version-specific payload. It prevents a signed message from being parsed as a legacy transaction, but replay resistance and authorization safety still require domain/intent binding and application checks.
Category: Security & Trust
EIP-712 standardizes hashing and signing for typed structured data. A supporting wallet can render fields such as an amount, deadline, and verifying contract more readably than an opaque digest, but the EIP does not require every wallet to display fields or provide replay protection. The app and verifier must bind the message and enforce its own safety rules.
ERC-1271 lets a contract account validate a signature through isValidSignature. It broadens signature verification for protocols that explicitly accept contract signatures; it does not change an ERC-2612 token's required ECDSA permit path or guarantee that every marketplace accepts contract accounts.
ERC-3643 provides identity and compliance checks for ordinary token transfers; mint and forcedTransfer use distinct privileged paths and burn has its own rules. Read the deployed identity and compliance modules instead of assuming every operation uses the same gate.
Category: Identity & Privacy
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.
Category: Onboarding & Access
ERC-5375 adds an authorInfo metadata field for NFT author names, addresses, and optional author-consent proofs. A consent proof shows that a signer agreed to be named as an author; the specification explicitly says that consent is not proof that the signer created the NFT. The metadata is normally off-chain and the signed field subset must be shown.
ERC-5564 standardizes one-time stealth-address generation and announcements that compatible recipients scan to discover payments. It can reduce public links to a recipient's main wallet, but funding, onward transfers, and other disclosed metadata can reveal those links.
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.
ERC-6538 defines a registry that maps a registrant address and schemeId to stealth meta-address bytes. It helps an ERC-5564 client discover a private-receive key; it does not define name resolution, profile verification, unregister/privacy erasure, or payment settlement.
ERC-7231 binds a custom set of Web2/Web3 identity records to an NFT through an identitiesRoot and verifier-specific proof. Its required interface exposes setIdentitiesRoot, getIdentitiesRoot, and verifyIdentitiesBinding; it does not define add/remove identity methods or guarantee that the bound accounts belong to one real human.
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.
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
ERC-7930 defines a versioned, length-prefixed binary envelope for chain-specific account identifiers. Pair it with a human-readable companion such as ERC-7828 or a CAIP-350 display profile when showing chain context to users; the ERC-7930 wire format is not itself a user-facing prefix string.
ERC-8019 defines an optional wallet-managed policy for auto-signing matching SIWE requests. A wallet may auto-sign when domain, URI prefix, chain, resources, and expiry constraints match; the app must still validate the SIWE message and manage its own session.
Category: Transaction Friction
