Connection is not authorization
A connected wallet proves only that an account is available to the interface. Separate connection, authentication, message signing, transaction signing, session authorization, and administrative approval in both the product model and interface copy. Users should understand what permission is requested, how long it lasts, and how to revoke it.
Multichain products also need an explicit account model. Define whether identities are linked across chains, how network mismatch is handled, and what happens when a user switches wallet, account, chain, or device during a workflow.
Make transactions understandable before signing
Show the action, assets, amounts, destination, fees, approvals, expected state change, and important failure conditions before opening the wallet. Avoid generic buttons such as Confirm when the operation creates an unlimited approval, delegates authority, upgrades a contract, or moves value to a new address.
Where infrastructure permits, simulate the transaction and display decoded effects. Simulation is advisory: state can change before inclusion, providers can disagree, and some failures appear only during execution. The interface should state those limits rather than promising success.
Design the full transaction state machine
A robust UI distinguishes preparing, awaiting signature, submitted, pending, confirmed, finalized, failed, replaced, expired, and unknown states. Persist transaction identifiers so users can recover after refresh or device change. Do not show success merely because a wallet returned a signature; verify the relevant chain state and product event.
Retries must avoid duplicate actions. Use idempotency keys for backend requests, check existing on-chain state, and make replacement or resubmission behavior chain-specific. Provide explorer links and a support reference that operators can use to trace failures.
Control approvals and delegated sessions
Token approvals, session keys, delegates, and account-abstraction permissions should be scoped by asset, amount, target, function, chain, and expiry whenever possible. Explain revocation and expose current permissions in a user-accessible surface. Administrative wallets should use separate policies from consumer sessions.
Never request seed phrases or private keys. Production signing identities should remain client- or user-controlled, with least-privilege service keys for relayers and automation.
Accept the wallet flow with evidence
Test supported wallets, browsers, devices, networks, account changes, chain changes, rejected signatures, insufficient funds, stale blockhashes or nonces, dropped transactions, replacement transactions, RPC failures, and refresh recovery. Acceptance evidence should include a wallet matrix, transaction receipts, final-state checks, error screenshots, monitoring events, and support runbooks.