Wallet login needs an explicit result for a reused challenge and an explicit result for an account change. Otherwise the interface can display one wallet while the server continues serving data for another. Review challenge verification and application session behavior together.
The Wallet Membership Kit is a product blueprint. The design below connects a one-time sign-in challenge to the application session and its account-change policy. The downloadable cases remain Not run and do not establish supported-wallet compatibility.
Bind the challenge to the intended sign-in
ERC-4361 defines a structured sign-in message containing the domain, address, URI, chain ID, nonce and issuance time, with optional time constraints. The relying party verifies the expected values and signature before establishing the session. The nonce has a minimum format requirement, but a valid format alone cannot prevent reuse. Sign-In with Ethereum.
For the proposed design, the server issues a random challenge and stores its expected context, expiration and unused state. The browser displays that challenge for signing. The verification endpoint loads the saved challenge and checks the received message against it rather than trusting a client-supplied domain or chain selection.
Keep sign-in intent separate from later business actions. A successful login establishes an application identity. It should not approve a transaction, change membership or link a wallet to a different user account without the rules for that action.
Consume the nonce once
After successful message and signature verification, change the challenge from unused to consumed and create the session as one atomic local operation. The proposed requirement is that two concurrent verification attempts can produce at most one successful consumption.
PostgreSQL documents row-level locks that block conflicting changes until the transaction ends. A selected implementation could use an appropriate lock or conditional update to enforce that one-time state change. The database operation still needs a test that sends competing requests; merely storing a consumed flag does not prove that the race is closed. PostgreSQL explicit locking.
| Login event | Proposed server decision | Useful interface response |
|---|---|---|
| Signature cancelled | Create no session | Offer a fresh sign-in attempt |
| Challenge expired | Reject stale challenge | Request a new challenge |
| Same nonce submitted twice | Reject the second consumption | Explain that the request was already used |
| Wrong domain or chain | Reject verification | Show the expected application context |
| Verification service unavailable | Keep the result unresolved | Offer retry without showing signed-in data |
Make account changes visible at both layers
EIP-1193 defines accountsChanged and chainChanged provider events. It also defines user rejection and disconnection errors. These give the interface observable events to handle; they do not revoke the server's existing session automatically. Ethereum provider API.
Choose a policy for the supported workflow. This design clears the active account's protected view on account change, requests server-side session termination and requires a fresh sign-in for the new account. If the termination request fails, the interface should remain signed out and the session policy must explain the outstanding server lifetime.
Test a change in a second tab and a disconnected provider as separate cases. A browser event handler can be missed or bypassed. The server should always associate protected responses with its verified session identity, while the interface must avoid labeling those responses as data for a newly selected wallet.
OWASP requires session termination to invalidate the session server-side and discusses server-enforced expiration. Use those mechanisms when implementing the selected switch policy, then verify what happens if the browser cannot reach the logout endpoint. Session termination guidance.
Declare the contract-wallet boundary
Contract accounts require a verification path appropriate to the account and chain. ERC-1271 defines isValidSignature and a required success value, with verification potentially depending on contract state. If the proposed release supports contract wallets, exercise that path explicitly. If it does not, communicate the supported account boundary before requesting a signature. Contract signature validation.
Download the wallet login failure worksheet to record supported wallets, challenge rules and the observed result of each failure. It includes concurrent nonce use and account-switch cases with blank evidence cells.
Review the Wallet Membership Kit blueprint to scope one EVM network, server-verified sessions and clear recovery interfaces. The blueprint does not include custody, token launches or an audited smart-contract implementation.
