Product design / Practical notes
How to Design Transaction Review Screens for Crypto Apps
Before someone authorizes a transaction, help them understand what will change. Afterward, describe the result the system can actually establish.
Lead with the proposed change
A useful review puts the proposed action into plain language and keeps its destination, asset, amount and relevant cost available to inspect. If a value is an estimate, say so.
Give someone a way to go back and correct the intent before authorization. The label on the next action should also explain which boundary they are about to cross.
Keep selection and authorization distinct
Yarsha’s token and NFT screens help someone choose the object. The result-detail example later in this article answers a different question about an operation after the fact.
Neither should be relabeled as the wallet-authorization screen. Keeping the stages distinct helps the team decide what information must carry into the actual review.
Keep the result model more precise than a spinner
| Moment | Question the interface should answer |
|---|---|
| Before authorization | What change am I being asked to approve? |
| Wallet handoff | What is the product waiting for? |
| Submitted | What evidence of submission is available? |
| Pending or unresolved | What is known, and should I wait or investigate? |
| Rejected or failed | Did I decline, or did the operation fail? |
| Resolved | What result is established and where can I inspect it? |
Do not generalize technical outcomes across networks
The actual transaction model belongs to the chosen network and integration. For example, Solana's documentation describes transactions as instructions processed together, with state changes reverted if an instruction fails. That is technical context, not a reason for the UI to promise that every failure has no cost or no consequence.
Have engineering define the evidence available at each stage. A design should not announce a confirmed result merely because the wallet window closed.
Test uncertainty before writing reassurance
Exercise a declined request, delayed confirmation, interrupted return and unknown outcome. Decide what can safely be retried and when the person should inspect the original operation first. Preserve the original intent so recovery does not depend on memory.
This is interface design guidance, not financial or security assurance. The review needs technical verification and appropriate domain input before it can be described as a reliable transaction flow.
Inspect a result panel without calling it authorization
The Yarsha detail panel separates spent and received assets from destination and fee. The complete frame in the Yarsha case retains the original dummy values and address. It is a result-detail design, not the screen where a person approves a wallet request.
The source explorer wording also needs chain-specific review. Check the supported network, link destination and result evidence before using that action to reassure someone that an operation is confirmed.
