Finding and connecting wallet to dApp
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
Payment requests encoded as ethereum: URLs work like bitcoin: links — scannable QR codes or clickable links trigger wallet payment flows. Design implications: generate QR codes for payment requests with pre-filled recipient, amount, and token type; support ENS names alongside hex addresses; use scientific notation (2.014e18) for human-readable amounts; design chain_id switching prompts when payment targets different network. Design decisions: decide whether to make gas parameters user-editable or hidden, handle token transfers (ERC-20 function calls) vs native ETH differently in UI, design validation for malformed URLs, consider showing fiat equivalents alongside crypto amounts.
Category: Onboarding & Access
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).
Category: Comprehension & Display
Users interact with dApps through a standardized wallet JavaScript API — all wallets expose the same request/response pattern. Design implications: build one connection flow that works with any EIP-1193 wallet, handle standard error codes (4001 for user rejection, 4100 for unauthorized, 4900 for disconnected) with consistent error messaging, listen for accountsChanged and chainChanged events to update UI state automatically. Design decisions: decide whether to show explicit 'connecting' vs 'connected' states, handle network switching prompts gracefully, consider how to surface RPC errors in human-readable form without exposing technical details.
QR codes and deep links connect mobile wallets to desktop dApps via standardized URI format. Design implications: generate scannable QR codes from wc: URIs, design mobile-friendly deep link buttons that open wallet apps directly, show connection status with pairing expiration timers, handle both WalletConnect v1 (bridge-based) and v2 (relay-based) protocols. Design decisions: choose QR code size and error correction level for reliable scanning, decide whether to show raw URI for manual copy, design timeout and retry flows when relay connection fails, consider showing which relay/bridge is being used for transparency.
Users grant permissions once upfront instead of approving every action individually — OAuth-style consent for Web3. Design implications: design permission request screens showing all requested capabilities (eth_accounts, signing methods) in human-readable form, allow users to selectively reject individual permissions, show current granted permissions in settings, design permission expiration and revocation flows. Design decisions: balance between requesting minimal permissions (more prompts) vs bundled permissions (fewer prompts, more trust required), decide when to request additional permissions mid-session, consider showing permission-specific UI caveats like 'requires signTypedData_v3 support'.
Alternative to EIP-6963 using window.evmproviders object — wallets register themselves by name for easy enumeration. Design implications: iterate Object.values(window.evmproviders) to build wallet selection UI, display wallet name, description, and base64 SVG icon for each provider, use snake_case keys as stable identifiers. Design decisions: choose between EIP-5749 vs EIP-6963 (6963 has more adoption), design fallback for wallets only supporting window.ethereum, handle scenario where both standards coexist during transition period.
Users with multiple wallet extensions see all installed wallets in a selection modal — no more random 'last wallet wins' behavior. Design implications: replace single 'Connect Wallet' button with wallet picker showing icons, names, and rdns identifiers; render wallet icons as 96x96px minimum using <img> tags (SVGs must not execute scripts); design empty states for when no wallets are detected. Design decisions: choose between showing all wallets immediately vs progressive disclosure, decide wallet list ordering (alphabetical, most-used, last-connected), consider whether to remember user's preferred wallet across sessions, handle edge cases where wallets may impersonate others via rdns. 🟢 Live on 37+ wallets (Critical priority for wallet connection UX). Important limitation: solves desktop wallet conflicts but does NOT apply to mobile — mobile connection remains a known pain point (Connection Failures, Medium severity).
