Onboarding & Access

URL Format for Transaction Requests

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.

Stages: Discovery & Connection

Ethereum Provider JavaScript API

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.

Stages: Discovery & Connection

WalletConnect URI Format

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.

Stages: Discovery & Connection

Wallet Permissions System

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'.

Stages: Discovery & Connection

Secure Meta Transactions

Users submit transactions without holding ETH — a relayer pays gas fees on their behalf (meta-transactions/gasless). Design implications: remove 'insufficient funds for gas' errors entirely, hide gas price selection for sponsored transactions, show clear indication when transactions are gasless vs user-paid, design relayer selection if multiple are available. Design decisions: decide who sponsors gas (dApp, protocol, user via different token), design fallback when relayer is unavailable or congested, consider showing original signer address vs relayer address in transaction history, handle trust model — users must understand their transaction goes through a forwarder.

Stages: Executing Transactions

Sign-In with Ethereum (SIWE)

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.

Stages: Authentication & Identity

window.evmproviders Object

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.

Stages: Discovery & Connection

Signature Validation for Predeploy Contracts

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.

Stages: Authentication & Identity

Multi Injected Provider Discovery

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).

Stages: Discovery & Connection

Precompile for secp256r1 (Passkeys)

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.

Stages: Authentication & Identity