Comprehension & Display

Mixed-case Address Checksum

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.

Stages: Authentication & Identity

Ethereum Name Service (ENS)

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.

Stages: Authentication & Identity, Asset Discovery & Display

ENS .eth Registrar

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.

Stages: Authentication & Identity

ENS Reverse Resolution

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.

Stages: Authentication & Identity, Asset Discovery & Display

eth_chainId Method

Wallets reliably detect which chain they're connected to — prevents transaction replay attacks across chains. Design implications: display current chain prominently in UI, show chain ID in network selector, validate chain consistency before transactions, alert users to chain mismatches. Design decisions: how to handle unknown chain IDs, whether to auto-switch chains or require manual confirmation, prominence of chain indicator (always visible vs on-demand).

Stages: Discovery & Connection, Status & Confirmation

Typed Structured Data Signing

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.

Stages: Authentication & Identity, Reading & Understanding

wallet_watchAsset

DApps prompt users to add tokens with one click — no manual contract address copying. Design implications: show token add prompt with icon/name/symbol preview, verify token against known lists before suggesting, display security warnings for suspicious tokens. Design decisions: permission model (always prompt vs remember preference), how to handle spam token add requests, verification level before showing token (metadata fetch vs trust dapp), blocking malicious token suggestions.

Stages: Asset Discovery & Display

Token Metadata

ERC-20 tokens get rich metadata like NFTs — icons, descriptions, and images without manual token list curation. Design implications: fetch and display token images/icons from tokenURI, show descriptions in token detail views, support interop field to identify token type, handle missing/broken metadata gracefully. Design decisions: trust level for fetched metadata (SSRF risks), caching strategy for metadata, fallback displays when tokenURI fails, whether to prefer on-chain name() or metadata name.

Stages: Asset Discovery & Display

Fork Identifier

Nodes quickly identify compatible peers — faster sync, no wasted connections to wrong networks (ETH vs ETC). Design implications: mostly invisible to end users but affects sync progress UIs, show network compatibility status in node dashboards, display fork identifier in developer tools. Design decisions: how to surface peer compatibility issues to users running nodes, whether to show 'searching for peers' vs specific incompatibility reasons, handling stale nodes gracefully.

Stages: Status & Confirmation

Typed Transaction Envelope

Different transaction types (legacy, EIP-1559, EIP-4844 blobs) coexist seamlessly — users don't need to understand encoding differences. Design implications: abstract transaction type complexity from users, show relevant fields per type (maxFeePerGas vs gasPrice), indicate transaction type in history views for debugging. Design decisions: whether to expose transaction type in UI at all, how to handle wallets that don't support newer types, default type selection logic, backwards compatibility messaging.

Stages: Status & Confirmation

CCIP Read (Offchain Data Retrieval)

Contracts fetch offchain data transparently — ENS names can resolve from L2s or external sources without users knowing. Design implications: show loading states during offchain lookups, indicate data source in advanced views (on-chain vs gateway), handle gateway failures gracefully with retries. Design decisions: which gateways to trust (security/privacy tradeoff), timeout handling for slow gateways, whether to show users that offchain lookup occurred, caching validated responses.

Stages: Asset Discovery & Display, Reading & Understanding

Web3 URL to EVM Call

Access blockchain data via URLs like 'web3://uniswap.eth/swap' — browsers can render on-chain content directly. Design implications: support web3:// URL scheme in address bars, display on-chain HTML/SVG content natively, show ENS-based URLs alongside traditional links, handle cross-chain URLs with chainid syntax. Design decisions: security model for executing on-chain content, how to display web3:// URLs to users unfamiliar with the concept, fallback when content fails to load, gateway vs native resolution.

Stages: Specialized Interactions

Client Script URI (TokenScript)

Tokens can link to official scripts/mini-dapps — wallets auto-discover functionality like 'Mint', 'Stake', or smart-lock controls. Design implications: fetch and display scriptURI-linked functionality, show available token actions dynamically, indicate script authenticity/source, sandbox script execution. Design decisions: trust model for token-linked scripts (massive security surface), user consent before running scripts, how to present discovered functionality vs built-in features, handling script updates/versioning.

Stages: Specialized Interactions

Contract Resource Requests

Smart contracts serve web content directly — fully decentralized frontends without centralized hosting. Design implications: render contract-served HTML/CSS/JS in app frames, show content source (contract address), handle HTTP-like status codes and redirects from contracts. Design decisions: sandboxing/security for contract-served content, performance expectations vs traditional hosting, how to indicate decentralized vs centralized content to users, caching strategies for immutable content.

Stages: Specialized Interactions

Custom Errors for Common Tokens

Token errors become specific and actionable — 'Insufficient balance: have 50, need 100' instead of generic 'transfer failed'. Design implications: parse custom errors to show precise failure reasons, display relevant values (balances, allowances) in error messages, suggest fixes inline (e.g., 'Approve more tokens'). Design decisions: which error details to expose to users vs log internally, how to present technical info accessibly, fallback handling for non-standard errors, translating error codes to user-friendly language. Addresses the Blanket Warnings pain point (Medium severity, Unsolved) — identical warnings for routine and catastrophic actions train users to ignore all alerts. ERC-6093 enables contextual, specific error messages.

Stages: Reading & Understanding

Chain-specific Address Checksum

Addresses have different checksums per chain — prevents sending mainnet funds to a testnet address that happens to be valid. Design implications: validate addresses against current network's chain ID, show chain badge alongside addresses, warn when address checksum doesn't match current network. Design decisions: which chains to support (RSK uses this, Ethereum mainnet doesn't), whether to treat cross-chain checksum mismatch as error or warning, how to handle chains that don't adopt this standard.

Stages: Status & Confirmation

Clear Signing Metadata

Builds on EIP-712 to provide full human-readable transaction summaries — transforms 'sign this hex blob' into 'Send 100 USDC to vitalik.eth.' Design implications: display complete transaction summaries in plain language, show contract interaction details (function name, parameters) in human terms, enable 'Domain verified on-chain' indicators, integrate with transaction simulation for balance change previews. Design decisions: how to handle contracts without clear signing metadata (fallback to raw data vs blocking), trust model for metadata providers, how prominently to warn when clear signing data is unavailable. Critical priority across 5+ pain points (blind signing, blanket warnings, scam prevention). The standard that powers the clear-signing movement (clear-signing.org).

Stages: Reading & Understanding, Approving & Permissioning

Wrapping of Bubbled Up Reverts

Nested contract call failures show full error chain — see exactly which contract in a multi-hop transaction failed and why. Design implications: display error stack traces for complex transactions, show failing contract address and function, preserve original error context through wrapping, visualize call hierarchy. Design decisions: depth of error chain to display (can get verbose), technical vs simplified error presentation, whether to show intermediate contract addresses, integration with block explorers for debugging. Complements ERC-6093 for the same Blanket Warnings problem — preserves error context through nested contract calls so users see 'Swap failed: insufficient liquidity' instead of generic reverts.

Stages: Reading & Understanding