Status & Confirmation

Simple Replay Protection

Transactions include chain ID preventing replay across networks — signing on Ethereum won't accidentally work on Polygon. Design implications: show network badge prominently during signing, warn if signing for unexpected chain, auto-detect chain mismatches between wallet and dApp. Design decisions: whether to block cross-chain mistakes entirely or allow with confirmation — power users want flexibility, novices need protection.

Category: Security & Trust

Transaction Status Code in Receipts

Transaction receipts include explicit success (1) or failure (0) status — no more guessing from gas usage. Design implications: show clear green checkmark/red X for transaction outcomes, display revert reason when available, distinguish between 'transaction included but failed' vs. 'transaction not included'. Design decisions: how to present failed transactions (some users expect failed = not charged, need education); whether to auto-expand failure details or keep UI clean.

Category: Infrastructure

eth_chainId Method

Wallets reliably detect which chain they're connected to — prevents transaction replay attacks across chains. Design implications: display current chain prominently in UI, show chain ID in network selector, validate chain consistency before transactions, alert users to chain mismatches. Design decisions: how to handle unknown chain IDs, whether to auto-switch chains or require manual confirmation, prominence of chain indicator (always visible vs on-demand).

Category: Comprehension & Display

Chain-specific Address Checksum

Addresses have different checksums per chain — prevents sending mainnet funds to a testnet address that happens to be valid. Design implications: validate addresses against current network's chain ID, show chain badge alongside addresses, warn when address checksum doesn't match current network. Design decisions: which chains to support (RSK uses this, Ethereum mainnet doesn't), whether to treat cross-chain checksum mismatch as error or warning, how to handle chains that don't adopt this standard.

Category: Comprehension & Display

ChainID Opcode

Smart contracts can verify which chain they're on, enabling chain-aware logic for bridges and L2s. Design implications: display chain context in multi-chain interfaces, show 'Supported Networks' clearly, indicate when contract behavior varies by chain. Design decisions: whether to expose chain-specific features or abstract them away — transparency vs simplicity tradeoff.

Category: Security & Trust

Fork Identifier

Nodes quickly identify compatible peers — faster sync, no wasted connections to wrong networks (ETH vs ETC). Design implications: mostly invisible to end users but affects sync progress UIs, show network compatibility status in node dashboards, display fork identifier in developer tools. Design decisions: how to surface peer compatibility issues to users running nodes, whether to show 'searching for peers' vs specific incompatibility reasons, handling stale nodes gracefully.

Category: Comprehension & Display

Typed Transaction Envelope

Different transaction types (legacy, EIP-1559, EIP-4844 blobs) coexist seamlessly — users don't need to understand encoding differences. Design implications: abstract transaction type complexity from users, show relevant fields per type (maxFeePerGas vs gasPrice), indicate transaction type in history views for debugging. Design decisions: whether to expose transaction type in UI at all, how to handle wallets that don't support newer types, default type selection logic, backwards compatibility messaging.

Category: Comprehension & Display

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.

Category: Cross-Chain

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.

Category: Cross-Chain

Consensus finalizes before execution completes — transactions are 'in' but state updates follow. Design implications: show transaction stages (Proposed → Voted → Finalized → Verified), display 'Awaiting execution' status after inclusion, indicate state root finality separately from transaction finality. Design decisions: whether to show Finalized (800ms, safe for most) or wait for Verified (1.6s, guaranteed state) for confirmations; how to explain the 3-block execution lag simply.

Category: Infrastructure

Transactions finalize in 800ms (2 blocks), with speculative finality at 400ms — near-instant confirmation UX. Design implications: show confirmation in under 1 second, remove 'waiting for confirmations' multi-block progress bars, enable real-time trading UIs, display 'Finalized' badge quickly. Design decisions: whether to confirm at speculative finality (400ms, extremely rare reverts) or full finality (800ms, guaranteed) — most apps should use speculative for responsiveness.

Category: Infrastructure