Web3 · 1 min read
Web3 UX: Make Transaction Intent Clear Before Signing
Design transaction previews, pending states and failure recovery so users understand what a wallet request will do.
Explain the action before the wallet opens
Connecting a wallet and approving an action are different moments. Before asking for a signature, show what the user is doing in plain language. Where relevant, show the asset, amount, destination and network. Distinguish a transaction from a message signature or token approval. The application’s summary should support the wallet review, not ask people to ignore it.
Make approvals understandable
A permission request can have consequences beyond the next visible action. Explain what access is being requested and avoid presenting a broad approval as a routine confirmation. Keep identifiers available for inspection without making a long address the only explanation. Clear wording helps comprehension, but it does not prove that a contract is safe.
Design pending as a real state
After submission, show that the transaction is waiting and offer an explorer link when one is available. Do not replace a pending operation with a success message because the wallet dialog closed. Keep the relevant action and transaction reference visible. If confirmation takes longer than expected, explain what is known without inventing a completion time.
Separate rejected, failed and completed
A user rejecting the wallet request is not the same as a transaction failing on-chain. Give these situations different messages and recovery actions. Avoid automatic retries that could create another transaction without consent. On completion, show what changed and how to inspect it. Keep the result readable even if the user leaves and returns to the screen.
Treat clear signing as context, not a guarantee
Human-readable signing information can help users understand structured requests. ERC-7730 describes a format for supplying this context, but support varies by tool and wallet. Do not assume every visitor will see the same preview. An understandable request can still be risky, and a clear interface does not make an irreversible transaction reversible.
Review with unfamiliar users
Ask someone to explain the request before approving it. If they cannot describe the action, network and expected result, improve the preview. Test rejected requests, the wrong network and long confirmation times as seriously as the happy path. The goal is informed action, not a faster click at any cost.
