What should crypto wallet UX explain before a transaction approval?
Published
Crypto wallet UX should explain the scope of a request before asking someone to approve it. Connecting a wallet, signing a message, granting a spending allowance, and submitting a transaction are different interactions. A single generic confirmation screen makes those differences too easy to miss.
The checklist below is a proposed design review method for wallet and crypto product teams. It is not investment advice, a security audit, or a promise that an approved transaction will be safe.
What exactly is the user being asked to approve?
Give the request a specific name and a plain-language consequence. MetaMask’s approval management guidance distinguishes connecting to an app from allowing a contract to move tokens. It also explains that disconnecting and revoking an allowance are separate actions.
Use that distinction as a starting point for a request inventory. For each supported interaction, ask engineering to document what the request authorizes, what persists afterward, and which facts the interface can verify.
- Connection: Explain which account and network the app wants to use and what information or interaction the connection permits.
- Signature: Explain the message’s purpose and any authority it grants. Do not assume that a request without a network fee is harmless.
- Spending approval: Identify the token, requesting contract, and allowance. Make a broad or unlimited allowance conspicuous.
- Transaction: Explain the intended action, relevant destination, asset changes, and estimated network cost before submission.
These categories are a review checklist, not a claim that every wallet or protocol presents requests separately. Where a flow combines actions, the interface should still explain the combined permission and consequence.
What belongs in a readable transaction preview?
Start with the action the person expects to perform. Then show the account, network, recipient or contract, assets affected, and estimated fees. Make addresses inspectable instead of relying entirely on a friendly label. Explain which amounts are estimates and which come directly from the request.
Tenderly’s transaction preview documentation describes simulations that can expose predicted balance changes, gas usage, and execution errors before submission. That is a useful source of preview information, not a guarantee about the eventual transaction or the trustworthiness of a contract.
For a proposed usability exercise, show a participant a preview with an unfamiliar contract and a spending limit larger than the intended purchase. Ask them to describe the permission in their own words. If they can only repeat the button label, the review screen has not explained enough.
What should happen when a preview is missing or stale?
Design this state before the successful preview. A missing simulation should appear as missing information, not an empty list of risks or a reassuring check mark. Explain whether the preview failed to load, the request cannot be interpreted, or the data needs refreshing.
Ask the product and security owners to define when approval must be blocked and when proceeding with an explicit warning is permitted. That decision belongs in the product’s risk policy, not in a designer’s improvised error message.
If the request, network, or relevant parameters change while the screen is open, make that change visible and refresh the review information. The final confirmation should concern the request the user is actually about to approve.
How should rejection and failure differ?
A user declining a request is a valid outcome. Preserve the surrounding task where possible and explain that the requested action was not approved. Avoid turning a deliberate rejection into a red technical error or repeatedly reopening the wallet prompt.
A submission failure needs a different message. Separate an unsigned request from a submitted transaction whose outcome is still being checked. Provide the available reference and status route rather than encouraging an immediate repeat action when the first outcome is unknown.
Test interruptions as well: the wallet closes, the account changes, or the person returns to the app after a delay. For each case, specify which request the app is showing and whether another approval is needed.
Can a failed transaction still cost money?
On Ethereum, executed computation costs gas even when a transaction fails. A wallet should not use a broad “Nothing happened” message if the asset operation failed but a network fee was incurred. A rejected signature that was never submitted is a different state.
Ethereum’s approval-revocation guide also describes revocation as a new transaction that requires a network fee. Removing an allowance changes future spending permission; it does not reimburse an earlier transfer.
- Illustrative review: compare an unsigned request, a submitted transaction that reverted, and a completed allowance revocation.
- For the reverted transaction, show the confirmed outcome and fee information the wallet can establish.
- For revocation, identify the token, contract, network, and permission being removed before approval.
- Keep fee estimates distinct from confirmed fees. Ask the engineering and security owners to validate the wording for each supported network.
Sources: Ethereum gas and fees · Ethereum token-access revocation
What does revoking permission actually change?
A permission-management view should explain the allowance being removed, the affected contract, and any supported next step. Avoid an “Undo” label for revocation: removing permission is not a promise to reverse an action that has already happened.
Include disconnection, allowance removal, and transaction history as distinct concepts in the design review. Ask security and engineering to check the wording against the supported networks and authorization mechanisms before release.
Teams preparing a crypto product UX brief should include their request inventory, unavailable-preview states, and recovery rules. When choosing a fintech or crypto design agency, ask candidates to walk through one ambiguous approval with the engineering team. Their questions about authority and uncertainty are more useful than another polished wallet mockup.
