Cross-Chain

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.

Stages: Executing Transactions

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.

Stages: Executing Transactions

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.

Stages: Executing Transactions

Unified Cross-Chain Balances

Users see their true net worth across all chains in a single view — no more manually switching networks to check balances. Design implications: aggregate balances across chains into a unified portfolio display, show per-chain breakdown on expand, handle loading states for multi-chain queries, display total value in fiat. Design decisions: whether to show chain badges on individual assets or group by chain, how to handle stale data from slow chains, real-time vs periodic refresh strategy, whether to show 'available on chain X' indicators for cross-chain actions. Multi-Chain Checklist rates this Critical priority — 'True net worth in one view.' Draft status, no implementations yet, but addresses the Single-Chain Balance Display pain point.

Stages: Asset Discovery & Display

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.

Stages: Authentication & Identity, Executing Transactions

Chain-Specific Address Format

Address format that makes the target chain explicit to users — prevents wrong-chain sends by encoding chain context directly in the address. Design implications: display chain-specific addresses with visible chain identifiers, validate address format against target chain before sending, show clear warnings when address chain doesn't match current network. Design decisions: how to display the chain prefix (icon, name, or code), whether to auto-convert between formats, handling addresses that exist on multiple chains. High priority — 'Prevents wrong-chain sends.' Complements EIP-1191 (chain-specific checksum) — while 1191 encodes chain ID in the checksum, 7930 provides a full address format standard that makes the chain explicit.

Stages: Authentication & Identity, Status & Confirmation

Chain ID with Tx Hash

Users can share or receive transaction references as a single portable string that includes chain context — no more 'which chain was this on?' confusion. Design implications: generate shareable tx links in format '1:0xabc123...:tx', auto-detect chain ID when pasting tx references, show chain icon/name when displaying decoded references. Design decisions: whether to auto-redirect to appropriate block explorer, how to handle unrecognized chain IDs, displaying the chain-prefixed format vs hiding complexity behind copy button.

Stages: Status & Confirmation