How to Design Transaction Confirmation UX

The transaction confirmation screen is the most critical user interface in any Web3 application. It's the final checkpoint where users review and approve actions that spend their assets or alter their on-chain state. A poorly designed confirmation flow is a primary source of user error, failed transactions, and security incidents. This guide outlines the core principles and components for building confirmation UX that is both secure by default and intuitive for users.

Effective confirmation design must communicate three key pieces of information unambiguously: what the transaction does, who it interacts with, and what it costs. The "what" includes the exact function call (e.g., swap, approve, deposit) and the asset amounts. The "who" means clearly displaying the destination contract address and any third-party protocols involved. The "cost" encompasses the network fee (gas) and any protocol fees, presented in both native token and fiat equivalent values.

Always decode and humanize raw transaction data. Instead of showing a user a hex-encoded data field and a to address of 0x..., display: "Swap 1 ETH for ~3,200 USDC via Uniswap V3." Use verified contract labels from sources like Etherscan and render token amounts with correct decimals. For approvals, explicitly state the spending limit (infinite or a specific amount) and highlight the associated risk. Integrate security plugins like Blockfence or Pocket Universe to simulate transaction outcomes and warn users of malicious patterns.

Implement a consistent, multi-step review process. A robust flow often includes: 1) A summary view with key details, 2) An expandable "Advanced Details" section for developers showing raw calldata, 3) A final explicit action (e.g., "Confirm Swap") that is disabled for a brief moment after the data loads to prevent rushed clicks. Use color and iconography consistently: green for primary actions, red for high-risk operations like approvals, and yellow for warnings. The transaction hash should be prominently displayed after submission with a link to the block explorer.

Design for failure states and edge cases. Clearly explain common errors like insufficient funds for gas, slippage tolerance exceeded, or reverted with plain-language reasons and suggested fixes. For pending transactions, provide realistic time estimates and a clear way to view the pending transaction in the user's wallet. Remember, the goal is to build trust through transparency; users should never feel surprised by the outcome of a transaction they approved.

Designing a user-friendly transaction confirmation flow requires understanding the user's mental model and the technical constraints of blockchain. Unlike traditional web2 payments, blockchain transactions are irreversible, require gas fees, and have variable confirmation times. Your UX must bridge this gap, clearly communicating critical information—like the recipient address, token amount, network fee, and estimated time—before the user commits. A well-designed confirmation screen is the last line of defense against costly user errors, making clarity and prevention its primary goals.

The core components of a confirmation screen are non-negotiable. You must display the transaction summary (action, amount, asset), the recipient address (with truncation and a copy button), the estimated network fee (in both native token and fiat), and the estimated completion time. For complex interactions like token approvals or swaps, you must also show the slippage tolerance and the minimum received amount. Tools like the EIP-681 URI standard for payments and EIP-747 for wallet metadata can help standardize this data presentation.

User testing reveals common failure points you must design against. Fat-finger errors on amounts, address poisoning via similar-looking characters, and unexpected high gas fees are major risks. Mitigation strategies include: using confirmation modals for high-value transfers, implementing address whitelists with labels, providing fee estimation from multiple sources like the Blocknative Gas Platform, and adding a brief delay on the "Confirm" button for critical actions. Always give users a clear path to cancel or revise the transaction before signing.

The post-signature experience is equally critical. Immediately after the user signs, display the transaction hash and a link to a block explorer like Etherscan. Provide real-time status updates: "Pending," "Confirming (2/12 blocks)," and "Confirmed." For long wait times, explain why (e.g., "Network congestion is causing slower confirmations"). Never leave the user in the dark; a pending state without feedback is a primary source of support tickets and user anxiety in Web3 applications.

Advanced patterns can enhance trust and comprehension. For DeFi transactions, simulate the outcome using a transaction preview that shows expected balance changes. For smart contract interactions, use human-readable descriptions (e.g., "You are approving the Router contract to spend up to 1000 USDC") instead of raw calldata. Consider implementing batch transaction flows for multi-step processes, allowing users to review and sign a sequence of actions as a single unit, a pattern seen in wallets like Rabby.

Finally, your design must be network-agnostic. Users interact with Ethereum, Layer 2s like Arbitrum and Optimism, and alternative chains like Solana, each with different confirmation characteristics. Dynamically adjust your UI's messaging and timing expectations based on the connected chain. The principles of clarity, prevention, and feedback remain constant, but their implementation must adapt to the underlying protocol's behavior to maintain a seamless and trustworthy user experience.

The primary function of a confirmation screen is to present a complete, unambiguous summary of the pending transaction. This includes the core action (e.g., 'Swap', 'Approve', 'Send'), the involved assets with precise amounts, the destination address, and the total cost in network fees (gas). For complex interactions like swaps or liquidity provisions, showing the expected output amount and a breakdown of fees (protocol + network) is essential. Tools like Etherscan's Gas Tracker can help provide context for current network conditions.

Context and risk communication is critical. The screen must highlight security-critical elements: Is the user interacting with a verified contract? Are they signing a potentially dangerous permit or increaseAllowance? Warnings should be explicit, using color and iconography (like lucide:alert-triangle) for high-risk actions. For transfers, a checksummed address should be displayed, with an option to copy or verify it via a block explorer link. This layer transforms a simple data display into a trust and safety mechanism.

The action buttons must enforce a deliberate user intent. The primary action (e.g., 'Confirm', 'Sign') should be clearly distinct, often using a prominent color. A cancel or reject button must always be present and equally accessible. Implementing a brief, non-blocking delay (1-2 seconds) on the confirm button can prevent accidental taps. For advanced users, consider a 'Advanced Details' toggle to reveal raw calldata or the specific function signature being called, such as transfer(address,uint256).

State management and feedback loops define the post-confirmation experience. Upon signing, the UI should immediately indicate processing (e.g., 'Transaction Submitted') and provide a transaction hash link. For wallet interactions, listen for the transactionHash and receipt events from providers like Ethers.js or Viem. Error states must be handled gracefully—if a user rejects the signature in their wallet, the dapp interface should revert to the ready state without crashing, clearly communicating the cancellation.

To implement this, structure your React component or view to separate the static summary data, dynamic state (loading, success, error), and action handlers. Use libraries like Viem's simulateContract to pre-validate transactions and estimate gas before the user even sees the confirmation screen, catching revert reasons early. Always design for the worst-case network scenario—high gas prices and slow confirmations should not break the user's flow or understanding of what they have just signed.

Transaction simulation is the process of executing a transaction in a controlled, read-only environment—typically a forked version of the blockchain—to predict its outcome before the user signs and broadcasts it. This is essential for UX because it transforms a blind commitment into an informed decision. A well-designed simulation flow should clearly show the user: the expected state changes (e.g., token balances before/after), the total cost (gas fees + value transferred), and any potential risks like slippage or failed conditions. Tools like Tenderly, OpenZeppelin Defender, and Blocknative provide APIs to integrate this functionality.

The core technical implementation involves sending the unsigned transaction to a simulation endpoint. For EVM chains, you can use the eth_call RPC method or a specialized service. The key is to simulate with the exact state of the user's address at the current block. Here's a simplified conceptual flow:

1. User initiates a transaction in your dApp interface.
2. Your frontend constructs the transaction object (to, data, value).
3. This object is sent to your backend or directly to a simulation service.
4. The service executes the call against a node and returns a result object detailing gas used, potential revert reasons, and state diffs.
5. Your UI parses this result into a human-readable preview.

Designing the confirmation modal is where UX meets simulation data. Avoid simply dumping raw JSON. Instead, create a clear, scannable summary. Key components include: Asset Changes (e.g., -1.5 ETH, +4500 USDC), Network Fees (Estimated gas in USD and native token), and Contract Interactions (list of protocols involved). For complex DeFi transactions, like a swap on Uniswap, highlight the minimum received amount and price impact percentage. Always surface simulation failures—like an INSUFFICIENT_OUTPUT_AMOUNT revert—as clear warnings, not debug errors.

Advanced implementations use simulation for proactive security. You can check for malicious interactions, such as unexpected token approvals to unknown contracts, and warn the user. Furthermore, simulating a transaction's effect on a user's overall portfolio health (e.g., impact on collateralization ratio in a lending protocol) provides deeper insight. The WalletConnect eth_sendTransaction upgrade and EIP-712 for typed structured data signing are complementary standards that make transaction data itself more readable, which pairs perfectly with simulation results.

To implement this effectively, start by integrating a reliable simulation provider. Handle edge cases: simulation can fail due to state dependencies, so implement fallback logic. Cache simulation results for identical transactions to reduce latency and API costs. Finally, always remember that simulation is a prediction, not a guarantee—minor state changes between simulation and broadcast can cause discrepancies. Your UI should manage expectations by noting that "estimated outcomes are based on current network conditions."

The wallet confirmation pop-up is a security boundary controlled by the user's wallet extension (like MetaMask) or mobile app, not your dApp. This creates a context switch where users must shift focus from your interface to an external window. Poor design around this moment leads to transaction abandonment. Your goal is to prepare the user, provide clear context, and manage their expectations before the pop-up appears. Always assume the user will be confused if the pop-up's details don't match what you just displayed.

Provide a Clear Pre-Transaction Summary

Never trigger a wallet pop-up without first showing the user exactly what they are about to sign. Your interface should display a summary including the action (e.g., 'Approve USDC spending'), the amount (in both token and USD value), the recipient address (with a label if possible), the estimated network fee, and the destination chain for cross-chain actions. Use this moment to explain why the transaction is necessary, especially for two-step processes like token approvals.

Handle the Pop-up Lifecycle

Wallet interactions are asynchronous. Your UI must reflect different states: Awaiting Signature, Transaction Pending, Transaction Confirmed, or Transaction Failed. Use clear, non-technical status messages. If a pop-up is blocked or doesn't appear, guide the user to click their wallet extension icon. For failed transactions, parse the error (e.g., user rejected request, insufficient funds) and show a helpful recovery message instead of just the raw RPC error code.

Code Example: Preparing the User

Here's a pattern using ethers.js to structure the call and update the UI:

javascriptCopy
async function executeSwap() {
  // 1. Update UI: Show 'Preparing Transaction...'
  setStatus('Preparing...');

  // 2. Build the transaction parameters
  const txRequest = await router.populateTransaction.swapExactTokensForTokens(
    amountIn, amountOutMin, path, userAddress, deadline
  );

  // 3. Show final summary to user with txRequest details
  showTransactionSummary(txRequest);

  // 4. Only after user clicks 'Confirm' in YOUR UI, request signature
  setStatus('Awaiting Wallet Confirmation...');
  const tx = await signer.sendTransaction(txRequest);

  // 5. Switch to pending state
  setStatus('Transaction Submitted...');
  const receipt = await tx.wait();
  // Handle success/failure
}

This pattern ensures the user is never surprised by the wallet's request.

Design for Common Pitfalls

• Gas Fees: Always estimate and display gas before the pop-up. Use libraries like eth-gas-reporter or Wallet APIs to get real-time estimates. Consider implementing gasless transactions via meta-transactions or sponsoring with services like Biconomy for a smoother onboarding experience.
• Token Approvals: The first approve() transaction is a major point of confusion. Explain that it's a one-time permission for a specific contract. Use the permit() signature standard (EIP-2612) where possible to avoid this pop-up entirely.
• Mobile & Deep Links: On mobile browsers, the action opens the wallet app. Ensure your dApp state is preserved when the user returns. Use WalletConnect modal UX best practices to maintain session continuity.

The best transaction UX feels inevitable and informed. By designing the journey around the wallet pop-up—providing context, managing states, and anticipating errors—you significantly increase completion rates and build user trust. Test your flows on multiple wallets (MetaMask, Coinbase Wallet, Phantom) as their pop-up designs and behaviors differ.

Effective transaction confirmation design balances security, clarity, and user control. Key principles include presenting a clear summary of the action (e.g., "Swap 1 ETH for 3200 USDC"), exposing critical risks like slippage or contract approvals, and providing a clear path to cancel or reject. The goal is to prevent user error and ensure informed consent before any on-chain action is finalized. Tools like EIP-712 for typed structured data signing are essential for making signatures human-readable.

For next steps, implement the patterns discussed: use a multi-stage modal with a review step showing all parameters, a signing step with wallet interaction, and a pending/confirmation step with a link to the block explorer. Integrate real-time data like gas estimates and network status. Consider advanced features for power users, such as the ability to edit gas parameters directly or set transaction speed preferences. Always test your flows with both novice and experienced users to identify friction points.

To deepen your understanding, explore the following resources: study wallet provider documentation (e.g., MetaMask SDK) for integration best practices. Analyze confirmation designs from leading dApps like Uniswap and Aave. For technical implementation, review libraries like Web3Modal or Wagmi that abstract wallet interactions. Finally, stay updated on new standards like ERC-4337 for account abstraction, which will fundamentally change how users approve transactions.