Interpreting what you're being asked to do
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
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.
Category: Comprehension & Display
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.
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.
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).
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.
No global mempool — transactions go directly to upcoming block leaders, reducing MEV and improving inclusion times. Design implications: remove 'pending in mempool' states (transactions either included or not), no sandwich attack warnings needed, use lower default slippage (0.5% vs 1-3%), show confident price quotes without 'may change due to MEV' caveats. Design decisions: remove MEV protection toggles entirely (cleaner) vs. keep for cross-chain consistency; how to explain faster inclusion without complex mempool concepts.
Category: Security & Trust
