Wallet UX review checklist ========================== Review the prompts, permissions, states, and support boundaries of a wallet-connected application. 1. Inventory every wallet prompt For every button that opens a wallet, record the requesting application, operation, authority, and expected outcome. Connection, message signing, spending approval, and transaction submission should not be disguised behind the same unexplained action label. Verify that the prompt matches what the preceding screen promised. 2. Show the relevant identity Keep the network, asset reference, and destination visible during review. Make full identifiers available even when a compact display truncates them. Distinguish test activity from production activity clearly enough that a screenshot or copied description still communicates the environment. 3. Explain the requested authority Describe what the user is granting, including the spender and requested amount where supported. An ongoing allowance should not be presented as a harmless one-time identity check. An undecodable operation should remain visibly unresolved rather than receiving a confident but incomplete summary. 4. Separate each completion milestone Define the evidence for signed, submitted, observed, and unresolved states in your application. Closing a wallet dialog does not prove the final action happened. Preserve a stable request identifier so an interrupted flow can be checked before another attempt is encouraged. 5. Make decline an ordinary choice Return a user who declines to a stable review screen. Do not automatically request another signature or frame cancellation as a failure of the user. Preserve non-sensitive context while leaving a clear path to stop, change details, or investigate the request further. 6. Label fees and uncertainty Keep the transfer quantity distinct from network fees and application charges. Explain which amounts are estimated, where conversion values came from, and when they were observed. Missing cost information should not become a reassuring zero. Avoid implying that a simulation guarantees execution. 7. Review keyboard and reading behavior Check the screen using a keyboard and at increased text size. Keep focus visible, maintain a logical order, and explain status in text rather than color alone. Avoid motion or countdowns that pressure users to act before they have reviewed the request. 8. Test support and recovery Use safe request references and public transaction identifiers where appropriate. Never ask for recovery phrases, private keys, or authentication tokens. Test wallet closure, browser reload, and connection loss after signing. Confirm that the application reconciles uncertain actions before recommending another irreversible attempt. Reference design checklist, not certification. Read the full guide: https://digitalassetapi.com/blog/wallet-signing-ux/