A connected wallet does not, by itself, establish an authenticated application session. The interface should make the difference visible: connecting selects an account; signing proves control for a specific sign-in request; server verification decides whether to create a session.
Separate the three steps
- Connect. Let the visitor choose a wallet and account.
- Sign in. Explain why a signature is requested and what access follows.
- Verify. Create the application session only after server-side validation.
For Ethereum-based sign-in, ERC-4361 defines a standard message containing the requesting domain, address, URI, chain ID, nonce and issuance time. Validate the signature and expected message values, including a server-issued nonce with replay protection. Apply the expected time constraints. Contract accounts need the appropriate verification path on the specified chain. Use a maintained implementation of the standard rather than an improvised message format.
Give each failure a useful recovery
| Situation | What the person needs | Review check |
|---|---|---|
| Signing cancelled | A calm retry option | No session is created. |
| Challenge expired | A fresh sign-in request | The stale request is rejected. |
| Verification unavailable | A retry message without claiming success | The interface stays signed out. |
| Account changed | A clear indication of the active identity | Old account data is not shown as new account data. |
| Wallet unavailable | Supported connection choices | The page remains usable. |
Decide session behavior deliberately
Document what disconnecting the wallet means for the application’s session, what account changes should trigger, and when a fresh signature is required. Make the visible account and active application identity unambiguous. Sensitive actions should have their own permission checks; signing in is not blanket approval for transactions.
A helpful product review is to walk through the flow on a phone with a wallet app, then on a desktop with multiple accounts. Observe the return from the wallet, the cancellation path and the recovery after a network interruption. Record behavior against your own supported-wallet list rather than promising compatibility with every wallet.
Keep the consent request understandable
Explain that the person is signing a login message, show the relevant identity after success, and keep transaction approvals separate. Avoid a generic spinner that hides whether the app is waiting for a wallet, a signature or the server.
Technical reference: ERC-4361: Sign-In with Ethereum. This guide describes review questions and interface states; it is not a wallet security audit.
Planning an integration? Explore Web3 development or bring your current flow to a project conversation.
