Transaction Friction

Token with Transaction Handling

Tokens notify receiving contracts and revert if handler missing — prevents tokens being permanently lost to incompatible contracts. Design implications: show 'safe transfer' indicators, remove 'tokens may be lost' warnings for 223 tokens, simplify deposit flows since callback handles everything. Design decisions: low adoption limits usefulness — must handle mixed token standards gracefully, decide whether to surface the safety difference to users or abstract it away, consider that 223 transfers to EOAs work normally. Addresses Sending to Wrong Address pain point (Critical severity) — users sending tokens to contracts that can't handle them is a permanent-loss scenario. ERC-223 addresses the contract-send case specifically (tokens bounce back), complementing ENS/address-book solutions which address the human-error case.

Stages: Executing Transactions

Token Standard

Tokens with hooks notify contracts on send/receive — enables single-transaction deposits but introduces reentrancy risks that have caused major exploits. Design implications: show security warnings for 777 tokens, indicate operator permissions clearly, warn when interacting with contracts that may be vulnerable to 777 reentrancy. Design decisions: largely superseded standard — decide whether to support at all, if supporting must prominently warn users about elevated risk, consider blocking 777 interactions in high-security contexts.

Stages: Executing Transactions

Payable Token

Tokens can trigger contract actions on receipt — transfer+action in one transaction instead of approve+transferFrom pattern. Design implications: show single-step payment flows ('Pay 100 USDC' vs 'Approve then Pay'), indicate when tokens support payable callbacks, simplify subscription/purchase UIs. Design decisions: less widely adopted than permit — decide whether to feature-detect and adapt UI, balance simplicity gains against explaining why some tokens have different flows. Directly addresses the Redundant Token Approvals pain point (High severity) — ERC-20's separate approve+call is where most first-time DeFi users abandon. ERC-1363 eliminates that two-step flow at the token standard level.

Stages: Executing Transactions, Gas & Fees

Permit Extension for ERC-20

Token approvals via signature instead of transaction — users sign a message, relayer submits on-chain, no ETH needed for approval step. Design implications: replace 'Approve' transaction with signature request, show 'gasless approval' badge, display permit expiry/deadline clearly, warn about permit phishing (malicious sites requesting signatures). Design decisions: tradeoff between convenience (longer deadlines) and security (shorter expiry), must educate users that signatures can be dangerous, consider revoking stale permits in UI. Live for USDC, DAI, UNI, and aTokens but not universal. Addresses Redundant Token Approvals pain point (High severity) — separate approval is where most first-time DeFi users abandon.

Stages: Approving & Permissioning

Wallet Call API

Apps can request multiple calls executed atomically — approve+swap+stake in one wallet popup instead of three. Design implications: design multi-action confirmation screens showing all operations, indicate atomicity guarantees ('all or nothing'), show capability badges for wallet features, build paymaster URL configuration. Design decisions: how to present batched operations (list vs grouped), handle partial wallet support gracefully, balance information density in confirmation dialogs — too little is risky, too much causes fatigue. Referenced across 4 pain points — Signing Fatigue (High), Missing Signing Context (Medium), Redundant Token Approvals (High), and Token Approval Management (High). Batching via wallet_sendCalls is High priority.

Stages: Executing Transactions

Set Code for EOAs

EOAs gain smart contract capabilities without migrating to new wallets — users keep existing addresses. Design implications: enable transaction batching UI (approve+swap in one click), show sponsored transaction options where dApps pay gas, add session key management for limited permissions (e.g., 'allow spending up to $100/day'). Design decisions: balance power vs complexity — advanced features need progressive disclosure, must clearly distinguish temporary delegations from permanent changes, consider how to surface 'who's paying for this' when sponsors are involved. 🟢 LIVE on mainnet — 9 wallets, 12.9M accounts, 117M authorizations. Bridges from EOAs to smart accounts while native AA (EIP-8141) is in draft. Addresses Gas Hurdle (Critical), Key Management (High), and Protocol Design sections.

Stages: Executing Transactions

Account Abstraction Using Alt Mempool

Users interact with smart accounts instead of EOAs. No seed phrases required, social recovery possible, gas payable in any token. Design implications: design onboarding without 'write down 12 words', show gas payment token selector, build recovery flows (guardian management UI), display bundled operations as single actions. Design decisions: tradeoff between custodial simplicity and self-custody complexity, must handle paymaster failures gracefully, decide whether to abstract UserOperations completely or expose for power users. 54M+ smart accounts, 1B+ UserOps. Smart wallets retain 70% of users vs 60% for seed-phrase wallets . Primary solution to Gas Hurdle (Critical), Key Management Burden (High), and Forced Backup Friction (Medium). Widely deployed (Safe, Biconomy, ZeroDev).

Stages: Executing Transactions, Gas & Fees

ERC-721 Nonce Extension

NFTs have nonces that change on transfer — prevents reactivation attacks where old marketplace listings become valid again. Design implications: show listing validity warnings ('This listing may be stale'), auto-cancel orders when nonce changes detected, indicate when an NFT was recently transferred. Design decisions: tradeoff between surfacing technical details (nonces) vs abstracting them, must decide how prominently to warn about potentially dangerous legacy listings on non-5008 NFTs.

Stages: Approving & Permissioning

ERC-1155 Allowance Extension

ERC-1155 tokens get granular approvals by ID and amount — no more 'approve all' for semi-fungible tokens. Design implications: design per-token-ID approval selectors, show approved quantities remaining, enable approval management dashboards for 1155 holdings. Design decisions: more control means more UI complexity — decide granularity of approval controls (per-ID, per-amount, or simplified presets), balance security benefits against approval fatigue for users with many token types.

Stages: Approving & Permissioning

Endorsement (Generalized Permit)

Generalized permit system — any function can accept off-chain signatures for authorization, enabling multi-sig and threshold signing in one transaction. Design implications: design multi-party approval collection UI, show endorsement status ('2 of 3 signed'), enable off-chain voting/approval workflows. Design decisions: complex signature coordination UX — must make gathering multiple signatures intuitive, handle partial endorsement states, decide how to display endorser identities and validity windows.

Stages: Approving & Permissioning

AUTH and AUTHCALL Opcodes

Predecessor to EIP-7702: introduced AUTH and AUTHCALL opcodes letting users sign an authorization so an 'invoker' contract could act on their behalf — enabling sponsored transactions, batching, and delegation without deploying a smart wallet. Superseded by EIP-7702 before mainnet deployment, so this guidance is historical: build new flows on EIP-7702, but the invoker/authorization mental model and its sponsored-transaction UX patterns informed 7702's design.

Stages: Executing Transactions

Paymaster Gas Sponsorship

Defines the standard interface for paymasters that let dApps cover gas fees — users experience 'no gas needed' onboarding. Design implications: detect empty wallets and offer gas sponsorship automatically, show clear indication when a transaction is sponsored vs user-paid, design paymaster selection if multiple are available, handle paymaster failures gracefully with fallback to user-paid. Design decisions: whether to show the sponsorship source (dApp, protocol), how to communicate the gas sponsorship model to users, fallback UX when paymaster rejects a transaction. Critical priority for gas UX — 'Detect empty wallets, offer gas sponsorship — new users transact immediately.' Modern replacement for ERC-2771 meta-transaction patterns.

Stages: Executing Transactions, Gas & Fees

Session Keys

Users pre-authorize a scope of actions so they don't sign every interaction — 'approve once, interact freely' for gaming, trading, and social apps. Design implications: design session key creation flows with clear scope display (which actions, spending limits, duration), show active session indicators, add session revocation UI, display remaining session budget/time. Design decisions: balance between permissiveness (fewer prompts) and security (tighter scopes), how to visualize session boundaries to users, whether to auto-expire sessions or require manual revocation. Primary solution to Signing Fatigue (High severity). MetaMask Delegation Toolkit and Viem implementing.

Stages: Approving & Permissioning, Executing Transactions

Auto-Login

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.

Stages: Authentication & Identity

Native Account Abstraction (Frame Txs)

Native protocol-level account abstraction — every Ethereum account becomes a smart account by default, no opt-in required. Design implications: design for a world where all accounts have smart wallet capabilities, remove EOA vs smart account distinction from UX, build universal recovery and key rotation flows. Design decisions: long-term architectural consideration — plan for native AA while building on ERC-4337/EIP-7702 today, consider migration paths for existing EOA users. Active draft. Long-term fix for the EOA vs smart account split — 'Native AA lets every user benefit without opting in.' High severity in Protocol Design section.

Stages: Executing Transactions, Gas & Fees