Executing Transactions

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.

Category: Transaction Friction

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.

Category: Transaction Friction

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.

Category: Transaction Friction

ERC-721 Consecutive Transfer Extension

Batch minting/transfer events — efficiently create or move thousands of consecutive tokens in one transaction. Design implications: show batch mint/transfer notifications (e.g., 'Received tokens #1-1000'), handle large collection imports without individual events, efficient indexing of mass distributions. Design decisions: how to display large batch receipts without overwhelming, progress indicators for indexing large transfers, summarizing vs listing individual tokens.

Category: NFT Capabilities

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.

Category: Onboarding & Access

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.

Category: Transaction Friction

Flash Loans

Users (typically developers/arbitrageurs) borrow tokens with zero collateral, use them within a single transaction, then repay with fee — enabling complex DeFi strategies. Design implications: show maxFlashLoan available per token, display flashFee upfront, this is primarily a developer/power-user feature — most retail UIs won't expose it directly, but aggregators might use it under the hood. Design decisions: whether to expose flash loan functionality in consumer UI at all, how to explain the atomic single-transaction constraint, whether to show protocol's flash loan usage in transaction breakdowns.

Category: DeFi Patterns

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

Category: Transaction Friction

Cross-Chain Execution

Users send transactions on one chain that execute on another without switching networks or managing multiple wallets. Design implications: show source/destination chain selectors prominently, display estimated bridge time and execution status, provide clear message delivery tracking with unique IDs, design pending state indicators for cross-chain messages. Design decisions: how to handle failed message execution (retry UI vs auto-refund), whether to show bridge security/trust profiles to users, balancing simplicity vs advanced options for power users who want to select specific bridges.

Category: Cross-Chain

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.

Category: Transaction Friction

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.

Category: Transaction Friction

Cross Chain Intents Standard

Users express what they want (intent) rather than how to execute it — fillers compete to fulfill cross-chain swaps/transfers at best rates. Design implications: show intent parameters clearly (destination, token, amount, deadline), display competing filler quotes or best rate automatically, design gasless flow for signed orders vs on-chain flow, show fill status across origin and destination chains. Design decisions: whether to show filler identity/reputation, how to communicate dutch auction price dynamics, deadline selection UI (time picker vs relative time), handling partial fills or failed settlements gracefully. 🟢 Live with $35B+ lifetime volume via Across. Bridging Pain is Critical — 70% of onboarded users never complete a bridge transaction. Intent-based protocols are replacing manual bridging as the primary cross-chain UX.

Category: Cross-Chain

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.

Category: Transaction Friction

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.

Category: Transaction Friction

Cross-Chain Messaging Gateway

Users interact with a unified cross-chain messaging interface that works across EVM and non-EVM chains without knowing which bridge is being used underneath. Design implications: abstract bridge selection behind the scenes or offer it as advanced option, design address input fields that handle different chain address formats (EVM vs Solana vs others), show message attributes as optional settings, display sender/recipient clearly with chain context. Design decisions: whether to expose bridge choice to users (simpler UX vs transparency tradeoff), how to visualize non-EVM addresses, whether to show post-processing steps (like gas payment) inline or as separate flow.

Category: Cross-Chain

Chain-Specific Address Resolution

Chain-aware addresses route to the correct network automatically — no manual chain switching required when interacting. Design implications: resolve addresses to their target chain context, auto-switch or prompt for network change when interacting with chain-specific addresses, show chain indicator alongside resolved addresses. Design decisions: whether to auto-switch silently or confirm with users, how to display chain context in address fields, fallback behavior when target chain is not supported by wallet. High priority — 'Auto-switch networks on interaction — no manual chain switching.' Resolves the Manual Network Switching pain point.

Category: Cross-Chain

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.

Category: Transaction Friction

Pre-check if a transaction would fail before sending — apps can query spendable balance accounting for the 10 MON reserve. Design implications: show spendable vs total balance, disable send when amount exceeds spendable, pre-validate before wallet popup, explain reserve with clear tooltips. Design decisions: whether MAX subtracts reserve + gas automatically; how to surface pre-check failures without blocking power users.

Category: Transaction Friction

EIP-7702 account abstraction supported with reserve balance constraints — delegated EOAs can't drain below 10 MON. Design implications: show clear warnings when delegating EOA ('10 MON minimum balance required while delegated'), indicate delegation status in account views, warn if attempting to send all funds from delegated account. Design decisions: whether delegation UI should enforce 10 MON check upfront or allow and show clear revert reasons; how to explain the CREATE/CREATE2 restriction for advanced users.

Category: Transaction Friction

Every EOA must maintain a 10 MON reserve for async execution safety. Two-layer enforcement: consensus-time (inflight tx budget) and execution-time (revert if ending balance < reserve). Undelegated accounts get one emptying transaction per ~3 blocks that bypasses the reserve; delegated accounts (EIP-7702) cannot. Design implications: show spendable vs total balance, account for reserve in MAX buttons, detect delegation status for emptying tx eligibility, handle transactions that revert after block inclusion, warn when approaching reserve threshold. Design decisions: whether to surface emptying transaction option for sub-10-MON balances vs. simply prompting to add funds.

Category: Transaction Friction

Transactions execute in parallel but results are identical to serial execution — same guarantees, faster throughput. Design implications: no UI changes needed for parallel execution (it's transparent), can show 10,000 TPS capability in network stats, transaction ordering guarantees remain — display order matches execution order. Design decisions: whether to surface parallel execution as a feature (marketing) or keep invisible (it just works); avoid implying transactions can 'race' each other.

Category: Infrastructure

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