Proving who you are and logging in
Adopted standard, safe to implement
Final review period before adoption
Widely deployed but not yet Final
Early stage proposal, may change
Live on Monad mainnet
Under consideration for Monad
Mixed-case addresses (0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed) catch typos before funds are lost — ~0.02% chance a random typo passes checksum. Design implications: always display checksummed addresses, validate checksum on paste/input with instant feedback, show clear error states for invalid checksums, consider case-preserving copy functionality. Design decisions: whether to auto-correct lowercase addresses or require exact match, how prominently to warn on checksum failure, whether to block or just warn on invalid checksums. Safety & Security Checklist rates verifying addresses with ERC-55 checksum as High priority — detects typos before sending.
Category: Comprehension & Display
Users can send to 'vitalik.eth' instead of '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045' — memorable names replace error-prone addresses. Design implications: always show ENS names where available, provide autocomplete for .eth names, display both name AND resolved address for verification, show avatar/profile data from ENS records, handle subdomains gracefully. Design decisions: when to show address vs name (trust tradeoff), how to handle unregistered/expired names, whether to require re-resolution before transactions, loading states for async resolution. 910K+ active domains. ENS is a primary solution to Sending to Wrong Address (Critical severity). Showing ENS names alongside addresses is High priority for safety UX.
Users acquire ENS names through blind auctions — bid privately, highest bidder wins, pays second-highest price. Design implications: guide users through 3-day bid reveal process with timeline UI, show deposit/refund status clearly, explain Vickrey auction mechanics simply, countdown timers for auction phases. Design decisions: how much auction complexity to expose vs abstract away, whether to show competitor activity, handling the 72hr bidding + 48hr reveal lifecycle, surfacing name availability timing.
Any wallet address can display a human name — '0xabc...' shows as 'alice.eth' in transaction histories and dashboards. Design implications: fetch reverse records for all displayed addresses, show names in activity feeds/transaction lists, display name in connected wallet UI, cache resolved names for performance. Design decisions: fallback display when no reverse record exists (truncated address vs full), handling mismatches between forward/reverse resolution (possible impersonation), refresh frequency for cached names.
Users sign off-chain messages to authorize actions without gas — login, approve listings, multisig confirmations. Design implications: show clear 'Sign Message' vs 'Approve Transaction' distinction, display human-readable message content before signing, indicate which dApp/contract will validate the signature. Design decisions: balance security warnings (phishing risk) against friction — too many warnings cause blindness, too few enable exploits.
Category: Security & Trust
Users see human-readable signing requests instead of confusing hex strings — they can verify 'Send 100 USDC to vitalik.eth' rather than raw bytes. Design implications: display typed data fields clearly in a structured table/card format, show domain name prominently to prevent phishing, group related fields logically, highlight high-risk fields (amounts, recipients) with visual emphasis. Design decisions: balance between showing all fields (completeness) vs. summarizing (readability), decide how to handle nested structs and arrays, consider progressive disclosure for complex messages.
Smart contract wallets (Safe, Argent) can sign messages like EOAs — unlocks gasless listings, off-chain voting for multisigs. Design implications: don't assume signer = EOA, show 'Wallet Type: Smart Contract' indicator, support signature verification loading states. Design decisions: how to handle async signature verification vs instant EOA checks — may need pending/confirming states in UI.
Users sign in to websites using their Ethereum wallet instead of email/password — self-custodied identity with no centralized IdP. Design implications: display human-readable SIWE message showing domain, statement, URI, chain ID, nonce, and expiration; design clear 'Sign-In with Ethereum' buttons distinct from transaction signing; show ENS names and avatars when available; implement session management with expiration handling. Design decisions: decide session duration and refresh strategy, choose between auto-login for returning users vs explicit sign-in, design account switching when user changes wallet address, handle signature rejection gracefully without breaking auth flow, consider showing resources array for granular permission requests.
Category: Onboarding & Access
NFT metadata includes verified author consent signatures — proves creator agreed to be credited, prevents fake attributions. Design implications: show 'Verified Author' badge with proof link, display multiple co-authors, indicate consent verification status. Design decisions: how to handle unverified vs verified authors — warning indicators, whether to allow display of unverified claims.
Senders generate one-time stealth addresses for recipients — receive funds privately without revealing main wallet. Design implications: show 'Send Privately' option, explain stealth address concept simply, add stealth transaction scanner for recipients. Design decisions: how to onboard users to stealth — complexity vs privacy benefit, whether to default to private or make it opt-in, scanning UX for finding received funds. 77K addresses deployed via Umbra. Part of the On-Chain Activity Is Public by Default pain point (High severity, Research status). Users often don't realize their complete financial history is visible — stealth addresses are one of four leading privacy solutions.
Category: Identity & Privacy
Smart contract wallets can sign messages before deployment — users don't need an initial transaction to start using their account. Design implications: enable 'Sign-In with Ethereum' and message signing for freshly created accounts with zero transactions, remove 'deploy wallet first' friction from onboarding, show account address even before deployment. Design decisions: decide whether to surface deployment status to users or abstract it away, design consistent verification flows that work for both deployed and counterfactual contracts, handle edge cases where signature was created pre-deployment but verified post-deployment, consider showing 'account not yet deployed' status in explorers.
Users register stealth meta-addresses in central registry — senders look up recipient's stealth keys to send privately. Design implications: add 'Register for Private Payments' onboarding, show registration status, enable ENS-like stealth address lookup. Design decisions: registry discoverability vs privacy — registered users are known to want privacy, balance convenience with metadata exposure.
NFTs aggregate multiple verified identities (Twitter, Discord, wallet addresses) into single on-chain profile — portable reputation. Design implications: show connected identities with verification status, add 'Link Identity' flow, display identity proofs. Design decisions: privacy controls for which identities visible — selective disclosure UI, granular sharing permissions, balance transparency with privacy.
Chain-aware addresses route to the correct network automatically — no manual chain switching required when interacting. Design implications: resolve addresses to their target chain context, auto-switch or prompt for network change when interacting with chain-specific addresses, show chain indicator alongside resolved addresses. Design decisions: whether to auto-switch silently or confirm with users, how to display chain context in address fields, fallback behavior when target chain is not supported by wallet. High priority — 'Auto-switch networks on interaction — no manual chain switching.' Resolves the Manual Network Switching pain point.
Category: Cross-Chain
Address format that makes the target chain explicit to users — prevents wrong-chain sends by encoding chain context directly in the address. Design implications: display chain-specific addresses with visible chain identifiers, validate address format against target chain before sending, show clear warnings when address chain doesn't match current network. Design decisions: how to display the chain prefix (icon, name, or code), whether to auto-convert between formats, handling addresses that exist on multiple chains. High priority — 'Prevents wrong-chain sends.' Complements EIP-1191 (chain-specific checksum) — while 1191 encodes chain ID in the checksum, 7930 provides a full address format standard that makes the chain explicit.
Users authenticate with passkeys (Face ID, Touch ID, Windows Hello, hardware security keys) instead of seed phrases — familiar biometric login for blockchain. Design implications: design passkey registration flows using device-native prompts, show biometric authentication UI for transaction signing, remove seed phrase backup requirements for passkey-only accounts, support multiple passkeys per account for device redundancy. Design decisions: decide whether passkeys supplement or replace traditional keys, design recovery flows when passkey device is lost, handle cross-device passkey sync (iCloud Keychain, Google Password Manager), consider showing security level differences between platform vs roaming authenticators. Final on Ethereum; Monad has native secp256r1 support — design passkey-first onboarding on both chains.
Persistent wallet authentication across sessions — eliminates repeated login signatures when returning to dApps. Design implications: implement automatic session restoration on return visits, show 'remembered' connection status, design opt-in/opt-out for persistent auth, handle session expiration gracefully. Design decisions: security tradeoffs of persistent auth (convenience vs risk on shared devices), whether to require re-authentication for sensitive actions, how to handle multiple wallets with persistent sessions. Draft standard, Ambire implementing. Listed as a solution to Signing Fatigue — competes with/complements ERC-4361 (SIWE) for the auth flow.
Category: Transaction Friction
