Wallet connect flows: the states a UI forgets
Connecting a wallet is not one button. It is a handful of states that a demo never hits and real users hit constantly.
Hammad Iqbal
Software Engineer
A demo wallet flow has one path: click Connect, approve, done. In real use people have no wallet installed, reject the request, switch networks halfway through, lock their wallet, or disconnect in another tab. If the UI does not name each of those states, users see a spinner that never ends.
- List the wallet states before drawing the screens.
- The wrong network is a normal state, not an error.
- A signed message and a sent transaction are different user commitments.
The states worth naming
Writing these down first turns a vague connect button into a small state machine you can actually test.
- No wallet found, with a clear install or alternative path
- Connection request pending, rejected, or cancelled
- Connected on the wrong network, with a one-tap switch
- Wallet locked or account changed while the page is open
Listen for changes
Wallets emit events when the account or chain changes. The page has to react to them, otherwise it keeps showing a balance or an address that no longer belongs to the active account, which is a quiet and confusing bug.
Transactions need their own feedback
Sending a transaction has several steps: waiting for approval, submitted, pending on the network, confirmed, or failed. Show each one, because confirmation can take a while and a frozen button looks like the app is broken.
Treat wallet connection as a state machine and give every state, including the awkward ones, a visible screen.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.